[jira] [Updated] (TS-2513) Missing SOCKS documentation
[ https://issues.apache.org/jira/browse/TS-2513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2513: -- Fix Version/s: Docs Assignee: Igor Galić > Missing SOCKS documentation > --- > > Key: TS-2513 > URL: https://issues.apache.org/jira/browse/TS-2513 > Project: Traffic Server > Issue Type: Bug > Components: Core, Documentation >Reporter: Leif Hedstrom >Assignee: Igor Galić > Fix For: Docs > > > There's a set of SOCKS related configurations and features, neither of which > are currently documented in our admin guides, or reference. However, the old > PDF Admin Guide has a number of pages related to SOCKS, which should be > converted to Sphinx. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (TS-2513) Missing SOCKS documentation
Leif Hedstrom created TS-2513: - Summary: Missing SOCKS documentation Key: TS-2513 URL: https://issues.apache.org/jira/browse/TS-2513 Project: Traffic Server Issue Type: Bug Components: Core, Documentation Reporter: Leif Hedstrom There's a set of SOCKS related configurations and features, neither of which are currently documented in our admin guides, or reference. However, the old PDF Admin Guide has a number of pages related to SOCKS, which should be converted to Sphinx. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (TS-2305) trafficserver restarts with !t_state.host_db_info.reverse_dns assert
[
https://issues.apache.org/jira/browse/TS-2305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13876000#comment-13876000
]
Sjaak Westdijk commented on TS-2305:
Hi,
On november 1 2013 i posted this on the dev forum:
Running ATS 4.0.1 (and 4.0.2) I got the next errors in de diag.log:
[Oct 31 07:35:26.150] Server {0x1} WARNING: unable to set file
'/opt/ts/var/trafficserver/host.db' size to 25935872: 22, Invalid argument
[Oct 31 07:35:26.150] Server {0x1} WARNING: header missing/corrupt:
[hostdb.config] : reinitializing database
[Oct 31 07:35:26.151] Server {0x1} NOTE: reconfiguring host database
[Oct 31 07:35:26.151] Server {0x1} WARNING: unable to set file
'/opt/ts/var/trafficserver/host.db' size to 25935872: 22, Invalid argument
After searching in de code which lead to ink_file.cc where the posix_fallocate
function is used. Omnios which is a distro of illumios is using zfs as default
file system. Searching on the internet gives some hints about problems with the
posix_fallocate function. So I changed the code in ink_file.cc a bit (line
344):
#if HAVE_POSIX_FALLOCATE && !defined(solaris)
return posix_fallocate(fd, 0, size);
#else
This resolves the issue (for now) but gives the next error:
[Nov 1 21:27:47.134] Server {0x1} WARNING: bad hardware sector size 131072,
resetting to 8192
Zfs is using a default recordsize of 128K so changing it to 8K resolves this
issue to.
This is resolving the issues on the empty host.db.
Sjaak
> trafficserver restarts with !t_state.host_db_info.reverse_dns assert
>
>
> Key: TS-2305
> URL: https://issues.apache.org/jira/browse/TS-2305
> Project: Traffic Server
> Issue Type: Bug
> Components: DNS
>Reporter: Sjaak Westdijk
> Labels: crash
> Fix For: sometime
>
>
> Running ATS 4.0.1 on OmniOS we observing a couple trafffic_server restarts on
> busy moments. At that time cpu load peakes and the system client throughput
> peakes to 1000Mbits. The messages in the system log are:
> FATAL: HttpSM.cc:2048: failed assert `!t_state.host_db_info.reverse_dns`
> and
> FATAL: HttpSM.cc:2049: failed assert`ats_is_ip(t_state.host_db_info.ip())`
> On the restart this in the diag.log
> {noformat}
> [Oct 29 12:03:21.892] Server {0x1} NOTE: cache clustering disabled
> [Oct 29 12:03:21.954] Server {0x1} NOTE: ip_allow.config updated, reloading
> [Oct 29 12:03:21.980] Server {0x1} WARNING: unable to set file
> '/opt/ts/var/trafficserver/host.db' size to 25935872: 22, Invalid argument
> [Oct 29 12:03:21.980] Server {0x1} WARNING: header missing/corrupt:
> [hostdb.config] : reinitializing database
> [Oct 29 12:03:21.980] Server {0x1} NOTE: reconfiguring host database
> [Oct 29 12:03:21.981] Server {0x1} WARNING: unable to set file
> '/opt/ts/var/trafficserver/host.db' size to 25935872: 22, Invalid argument
> [Oct 29 12:03:22.019] Server {0x1} NOTE: cache clustering disabled
> [Oct 29 12:03:22.021] Server {0x1} NOTE: logging initialized[15],
> logging_mode = 3
> [Oct 29 12:05:10.011] Server {0x1} NOTE: traffic server running
> [Oct 29 12:05:26.915] Server {0x6} NOTE: cache enabled
> {noformat}
> This in the manager.log
> {noformat}
> [Oct 29 12:03:19.711] Manager {0x1} ERROR:
> [LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig 6:
> Abort
> [Oct 29 12:03:19.718] Manager {0x1} ERROR: (last system error 2: No such
> file or directory)
> [Oct 29 12:03:19.718] Manager {0x1} ERROR: [Alarms::signalAlarm] Server
> Process was reset
> [Oct 29 12:03:19.718] Manager {0x1} ERROR: (last system error 2: No such
> file or directory)
> [Oct 29 12:03:20.724] Manager {0x1} NOTE: [LocalManager::startProxy]
> Launching ts process
> [Oct 29 12:03:20.745] Manager {0x1} NOTE:
> [LocalManager::pollMgmtProcessServer] New process connecting fd '12'
> [Oct 29 12:03:20.745] Manager {0x1} NOTE: [Alarms::signalAlarm] Server
> Process born
> {noformat}
> This is the dns config in records.config
> {noformat}
> CONFIG proxy.config.dns.search_default_domains INT 0
> CONFIG proxy.config.dns.splitDNS.enabled INT 0
> CONFIG proxy.config.dns.max_dns_in_flight INT 2048
># Additional URL expansions for http DNS lookup
> CONFIG proxy.config.dns.url_expansions STRING NULL
> CONFIG proxy.config.dns.round_robin_nameservers INT 0
> CONFIG proxy.config.dns.nameservers STRING 127.0.0.1
> CONFIG proxy.config.dns.resolv_conf STRING /etc/resolv.conf
># This provides additional resilience against DNS forgery, particularly in
># forward or transparent proxies, but requires that the resolver populates
># the queries section of the response properly.
> CONFIG proxy.config.dns.validate_query_name INT 0
> {noformat}
> We are running a local dns server which is actually a forwarding server with
> a blockingzone for botnet sites.
[jira] [Commented] (TS-2510) Create a hook for Lua Plugins to attach themselves into the Configuration
[ https://issues.apache.org/jira/browse/TS-2510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13875996#comment-13875996 ] James Peach commented on TS-2510: - I don't understand what this means. Can you elaborate? > Create a hook for Lua Plugins to attach themselves into the Configuration > - > > Key: TS-2510 > URL: https://issues.apache.org/jira/browse/TS-2510 > Project: Traffic Server > Issue Type: Sub-task > Components: Configuration >Reporter: Igor Galić > Fix For: 5.0.0 > > > We need a way for plugins to get into the Lua Config. > (Because as we have it designed now, there's no way for the Lua Config to run > at *run* time. We need a easy middle-ground between configuration and plugin > in Lua) -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (TS-1712) Double Free Issue with Basic Auth Type Plugin
[
https://issues.apache.org/jira/browse/TS-1712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13875983#comment-13875983
]
Valerie Thompson commented on TS-1712:
--
It was a consistent and debilitating issue at that time with that build,
version and plugin. We had to since move on from ATS due to the bug as we
really needed the plugin.
> Double Free Issue with Basic Auth Type Plugin
> -
>
> Key: TS-1712
> URL: https://issues.apache.org/jira/browse/TS-1712
> Project: Traffic Server
> Issue Type: Bug
> Components: Plugins
>Reporter: Valerie Thompson
> Labels: Crash
> Fix For: sometime
>
>
> I am creating a new plugin based off of basic-auth.c example from 3.0.5
> version of ATS. When I load the plugin and start running traffic through it I
> am getting memory issues and eventually crashes.
> I plan on having a username and password for my plugin, and as I add more
> features, the more unstable everything becomes. Today I stripped everything
> down to the bare minimum and ran it as and here is an example of memory
> issues, below. Let me know if you need further information.
> uname info for the type of box I'm running on:
> 2.6.32-279.5.1.el6.x86_64 #1 SMP Tue Aug 14 16:11:42 CDT 2012 x86_64 x86_64
> x86_64 GNU/Linux
> {quote}
> *** glibc detected *** /usr/bin/traffic_server: double free or corruption
> (!prev): 0x030c4ab0 ***
> === Backtrace: =
> /lib64/libc.so.6[0x3197275916]
> /lib64/libc.so.6[0x3197278443]
> /usr/lib64/trafficserver/plugins/ena-auth.so(+0x16a0)[0x2b051fc026a0]
> /usr/bin/traffic_server(_ZN6HttpSM17state_api_calloutEiPv+0x525)[0x52d3e5]
> /usr/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x1ea)[0x536e7a]
> /usr/bin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x9f)[0x5209df]
> /usr/bin/traffic_server(_ZN6HttpSM16do_hostdb_lookupEv+0x35a)[0x5222fa]
> /usr/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0xac3)[0x537753]
> /usr/bin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x9f)[0x5209df]
> /usr/bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x32a)[0x53828a]
> /usr/bin/traffic_server(_ZN6HttpSM17state_api_calloutEiPv+0x278)[0x52d138]
> /usr/bin/traffic_server(_ZN6HttpSM21state_cache_open_readEiPv+0x280)[0x52e760]
> /usr/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0xe8)[0x5309a8]
> /usr/bin/traffic_server(_ZN11HttpCacheSM21state_cache_open_readEiPv+0x202)[0x510d22]
> /usr/bin/traffic_server(_ZN5Cache9open_readEP12ContinuationP7INK_MD5P7HTTPHdrP21CacheLookupHttpConfig13CacheFragTypePci+0x4be)[0x65a41e]
> /usr/bin/traffic_server(_ZN14CacheProcessor9open_readEP12ContinuationP3URLP7HTTPHdrP21CacheLookupHttpConfigl13CacheFragType+0x170)[0x638910]
> /usr/bin/traffic_server(_ZN11HttpCacheSM9open_readEP3URLP7HTTPHdrP21CacheLookupHttpConfigl+0x84)[0x510674]
> /usr/bin/traffic_server(_ZN6HttpSM24do_cache_lookup_and_readEv+0x151)[0x521ab1]
> /usr/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x6f3)[0x537383]
> /usr/bin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x9f)[0x5209df]
> /usr/bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x32a)[0x53828a]
> /usr/bin/traffic_server(_ZN6HttpSM17state_api_calloutEiPv+0x278)[0x52d138]
> /usr/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x1ea)[0x536e7a]
> /usr/bin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x9f)[0x5209df]
> /usr/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x7fd)[0x53748d]
> /usr/bin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x9f)[0x5209df]
> /usr/bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x32a)[0x53828a]
> /usr/bin/traffic_server(_ZN6HttpSM17state_api_calloutEiPv+0x278)[0x52d138]
> /usr/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x1ea)[0x536e7a]
> /usr/bin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x9f)[0x5209df]
> /usr/bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x32a)[0x53828a]
> /usr/bin/traffic_server(_ZN6HttpSM17state_api_calloutEiPv+0x278)[0x52d138]
> /usr/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x1ea)[0x536e7a]
> /usr/bin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x9f)[0x5209df]
> /usr/bin/traffic_server(_ZN6HttpSM32state_read_client_request_headerEiPv+0x5ab)[0x52c06b]
> /usr/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0xe8)[0x5309a8]
> /usr/bin/traffic_server[0x68314b]
> /usr/bin/traffic_server[0x685c71]
> /usr/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x2e2)[0x67e782]
> /usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0xb4)[0x6aaff4]
> /usr/bin/traffic_server(_ZN7EThread7executeEv+0x4c3)[0x6a
[jira] [Updated] (TS-2503) dynamic TLS record size tuning
[
https://issues.apache.org/jira/browse/TS-2503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2503:
--
Fix Version/s: (was: sometime)
5.2.0
> dynamic TLS record size tuning
> --
>
> Key: TS-2503
> URL: https://issues.apache.org/jira/browse/TS-2503
> Project: Traffic Server
> Issue Type: Improvement
> Components: Performance, SSL
>Reporter: James Peach
> Fix For: 5.2.0
>
>
> From [~igrigorik] in TS-2365:
> {quote}
> FWIW, I think you may be interested in this discussion:
> - http://mailman.nginx.org/pipermail/nginx-devel/2013-December/004703.html
> - http://mailman.nginx.org/pipermail/nginx-devel/2014-January/004748.html
> In a nutshell, static record size introduces an inherent tradeoff between
> latency and throughput -- smaller records are good for latency, but hurt
> server throughput by adding bytes and CPU overhead. It would be great if we
> could implement a smarter strategy in ATS. The extra benefit is that it's one
> less knob to tune: the out-of-the-box experience would be better optimized
> for all ATS users, regardless of mix/type of traffic being proxies.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (TS-2485) move C++ API to an api/ directory
[
https://issues.apache.org/jira/browse/TS-2485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13875980#comment-13875980
]
Leif Hedstrom commented on TS-2485:
---
If we're gonna do this, please do it before 5.0.0 IMO. If not, close it.
> move C++ API to an api/ directory
> -
>
> Key: TS-2485
> URL: https://issues.apache.org/jira/browse/TS-2485
> Project: Traffic Server
> Issue Type: Improvement
> Components: Core, TS API
>Reporter: James Peach
>Assignee: Brian Geffon
> Fix For: 4.2.0
>
>
> The C++ API is currently in {{lib/atscppapi/}}. The {{lib/}} directory is
> used for internal project library code, so it's a weird place to put API
> libraries. The C API is in {{proxy/api}}, so that could make sense. It might
> also make sense for there to be a top-level {{api/}} directory for both
> public APIs.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (TS-2427) xdebug: Trigger should be configurable
[
https://issues.apache.org/jira/browse/TS-2427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2427:
--
Assignee: Igor Galić
> xdebug: Trigger should be configurable
> --
>
> Key: TS-2427
> URL: https://issues.apache.org/jira/browse/TS-2427
> Project: Traffic Server
> Issue Type: Bug
> Components: Plugins
>Reporter: Igor Galić
>Assignee: Igor Galić
> Fix For: 4.2.0
>
>
> {code}
> // The name of the debug request header. This should probably be configurable.
> #define X_DEBUG_HEADER "X-Debug"
> {code}
> I agree!
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Closed] (TS-2404) Please add request IP address to slow log
[ https://issues.apache.org/jira/browse/TS-2404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call closed TS-2404. -- Resolution: Duplicate > Please add request IP address to slow log > - > > Key: TS-2404 > URL: https://issues.apache.org/jira/browse/TS-2404 > Project: Traffic Server > Issue Type: Improvement > Components: Logging >Reporter: David Carlin > Fix For: sometime > > > Can the IP address of the request be added to the slow log? Thanks! -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TS-2427) xdebug: Trigger should be configurable
[
https://issues.apache.org/jira/browse/TS-2427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2427:
--
Fix Version/s: (was: sometime)
4.2.0
> xdebug: Trigger should be configurable
> --
>
> Key: TS-2427
> URL: https://issues.apache.org/jira/browse/TS-2427
> Project: Traffic Server
> Issue Type: Bug
> Components: Plugins
>Reporter: Igor Galić
>Assignee: Igor Galić
> Fix For: 4.2.0
>
>
> {code}
> // The name of the debug request header. This should probably be configurable.
> #define X_DEBUG_HEADER "X-Debug"
> {code}
> I agree!
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (TS-2485) move C++ API to an api/ directory
[
https://issues.apache.org/jira/browse/TS-2485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2485:
--
Fix Version/s: (was: sometime)
4.2.0
> move C++ API to an api/ directory
> -
>
> Key: TS-2485
> URL: https://issues.apache.org/jira/browse/TS-2485
> Project: Traffic Server
> Issue Type: Improvement
> Components: Core, TS API
>Reporter: James Peach
>Assignee: Brian Geffon
> Fix For: 4.2.0
>
>
> The C++ API is currently in {{lib/atscppapi/}}. The {{lib/}} directory is
> used for internal project library code, so it's a weird place to put API
> libraries. The C API is in {{proxy/api}}, so that could make sense. It might
> also make sense for there to be a top-level {{api/}} directory for both
> public APIs.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Comment Edited] (TS-2101) Segmentation fault collation log server
[
https://issues.apache.org/jira/browse/TS-2101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13875970#comment-13875970
]
Igor Galić edited comment on TS-2101 at 1/19/14 6:51 PM:
-
[~bettydreamit] Is this still an issue ? If so , please provide the details
Yunkai asks for. If not, please close.
was (Author: zwoop):
Is this still an issue ? If so , please provide the details Yunkai asks for. If
not, please close.
> Segmentation fault collation log server
>
>
> Key: TS-2101
> URL: https://issues.apache.org/jira/browse/TS-2101
> Project: Traffic Server
> Issue Type: Bug
>Reporter: bettydramit
>Assignee: Yunkai Zhang
> Fix For: sometime
>
>
> gitmaster centos 6 x86_64
> {code}
> zym@zymtest1 /tmp $ c++filt < c
> [TrafficServer] using root directory '/usr'
> NOTE: Traffic Server received Sig 11: Segmentation fault
> /usr/bin/traffic_server - STACK TRACE:
> /lib64/libpthread.so.0(+0xf500)[0x2b324c3a5500]
> /usr/bin/traffic_server(LogObjectManager::get_object_with_signature(unsigned
> long)+0x24)[0x5a28e4]
> /usr/bin/traffic_server(Log::match_logobject(LogBufferHeader*)+0x3b)[0x58b98b]
> /usr/bin/traffic_server(LogCollationHostSM::host_recv(int,
> void*)+0x1e0)[0x5ad940]
> /usr/bin/traffic_server[0x671291]
> /usr/bin/traffic_server[0x673f8a]
> /usr/bin/traffic_server(NetHandler::mainNetEvent(int, Event*)+0x1f2)[0x66c422]
> /usr/bin/traffic_server(EThread::process_event(Event*, int)+0x84)[0x696b64]
> /usr/bin/traffic_server(EThread::execute()+0x4bb)[0x69754b]
> /usr/bin/traffic_server[0x695ae2]
> /lib64/libpthread.so.0(+0x7851)[0x2b324c39d851]
> /lib64/libc.so.6(clone+0x6d)[0x2b324ea2f11d]
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (TS-2358) DNS does not fail-over promptly for DNS server returning SERVFAIL
[ https://issues.apache.org/jira/browse/TS-2358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2358: -- Fix Version/s: (was: sometime) 5.3.0 > DNS does not fail-over promptly for DNS server returning SERVFAIL > - > > Key: TS-2358 > URL: https://issues.apache.org/jira/browse/TS-2358 > Project: Traffic Server > Issue Type: Bug > Components: DNS >Affects Versions: 3.2.5 >Reporter: William Bardwell > Fix For: 5.3.0 > > Attachments: ats.dns.txt > > > If I have 2 dns servers listed in my resolv.conf and the first one is > returning SERVFAIL for something that I try to lookup, ATS takes a long time > to fail over, and won't do it for the first request to look something up. > Using normal system commands (host, ping etc.) with the same resolv.conf work > fine. > I tried various config values with out much improvement. I could make it > fail in 40sec instead of 60sec for the initial failure... > debug logs will be attached, doing one DNS and then waiting a while and doing > another. (Doing more before enough time has passed don't seem to help much.) -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (TS-2305) trafficserver restarts with !t_state.host_db_info.reverse_dns assert
[
https://issues.apache.org/jira/browse/TS-2305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13875976#comment-13875976
]
Leif Hedstrom commented on TS-2305:
---
Any thoughts / comments on this? Why is the host.db file 0 bytes size? Config
problem? Permissions problem maybe? Please clarify, if not we'll close this as
can't reproduce.
> trafficserver restarts with !t_state.host_db_info.reverse_dns assert
>
>
> Key: TS-2305
> URL: https://issues.apache.org/jira/browse/TS-2305
> Project: Traffic Server
> Issue Type: Bug
> Components: DNS
>Reporter: Sjaak Westdijk
> Labels: crash
> Fix For: sometime
>
>
> Running ATS 4.0.1 on OmniOS we observing a couple trafffic_server restarts on
> busy moments. At that time cpu load peakes and the system client throughput
> peakes to 1000Mbits. The messages in the system log are:
> FATAL: HttpSM.cc:2048: failed assert `!t_state.host_db_info.reverse_dns`
> and
> FATAL: HttpSM.cc:2049: failed assert`ats_is_ip(t_state.host_db_info.ip())`
> On the restart this in the diag.log
> {noformat}
> [Oct 29 12:03:21.892] Server {0x1} NOTE: cache clustering disabled
> [Oct 29 12:03:21.954] Server {0x1} NOTE: ip_allow.config updated, reloading
> [Oct 29 12:03:21.980] Server {0x1} WARNING: unable to set file
> '/opt/ts/var/trafficserver/host.db' size to 25935872: 22, Invalid argument
> [Oct 29 12:03:21.980] Server {0x1} WARNING: header missing/corrupt:
> [hostdb.config] : reinitializing database
> [Oct 29 12:03:21.980] Server {0x1} NOTE: reconfiguring host database
> [Oct 29 12:03:21.981] Server {0x1} WARNING: unable to set file
> '/opt/ts/var/trafficserver/host.db' size to 25935872: 22, Invalid argument
> [Oct 29 12:03:22.019] Server {0x1} NOTE: cache clustering disabled
> [Oct 29 12:03:22.021] Server {0x1} NOTE: logging initialized[15],
> logging_mode = 3
> [Oct 29 12:05:10.011] Server {0x1} NOTE: traffic server running
> [Oct 29 12:05:26.915] Server {0x6} NOTE: cache enabled
> {noformat}
> This in the manager.log
> {noformat}
> [Oct 29 12:03:19.711] Manager {0x1} ERROR:
> [LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig 6:
> Abort
> [Oct 29 12:03:19.718] Manager {0x1} ERROR: (last system error 2: No such
> file or directory)
> [Oct 29 12:03:19.718] Manager {0x1} ERROR: [Alarms::signalAlarm] Server
> Process was reset
> [Oct 29 12:03:19.718] Manager {0x1} ERROR: (last system error 2: No such
> file or directory)
> [Oct 29 12:03:20.724] Manager {0x1} NOTE: [LocalManager::startProxy]
> Launching ts process
> [Oct 29 12:03:20.745] Manager {0x1} NOTE:
> [LocalManager::pollMgmtProcessServer] New process connecting fd '12'
> [Oct 29 12:03:20.745] Manager {0x1} NOTE: [Alarms::signalAlarm] Server
> Process born
> {noformat}
> This is the dns config in records.config
> {noformat}
> CONFIG proxy.config.dns.search_default_domains INT 0
> CONFIG proxy.config.dns.splitDNS.enabled INT 0
> CONFIG proxy.config.dns.max_dns_in_flight INT 2048
># Additional URL expansions for http DNS lookup
> CONFIG proxy.config.dns.url_expansions STRING NULL
> CONFIG proxy.config.dns.round_robin_nameservers INT 0
> CONFIG proxy.config.dns.nameservers STRING 127.0.0.1
> CONFIG proxy.config.dns.resolv_conf STRING /etc/resolv.conf
># This provides additional resilience against DNS forgery, particularly in
># forward or transparent proxies, but requires that the resolver populates
># the queries section of the response properly.
> CONFIG proxy.config.dns.validate_query_name INT 0
> {noformat}
> We are running a local dns server which is actually a forwarding server with
> a blockingzone for botnet sites.
> Note: the host.db file keeps its 0 bytes size all the time
>
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (TS-2344) 404 error was logged while url redirect request was processed corrctly
[ https://issues.apache.org/jira/browse/TS-2344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2344: -- Fix Version/s: (was: sometime) 5.0.0 > 404 error was logged while url redirect request was processed corrctly > -- > > Key: TS-2344 > URL: https://issues.apache.org/jira/browse/TS-2344 > Project: Traffic Server > Issue Type: Bug > Components: Logging >Reporter: Eddie >Assignee: Bryan Call > Fix For: 5.0.0 > > > I am seeing a lot of entries in the error log for my url redirect request. > The request was processed correctly and I could see the expected response in > log as below: > 2013-11-08 18:23:37 301 FIN http://yahoo.com > http://www.yahoo.com/ > But log messages like following were printed in the error log too, which > generates a lot of error logs (log rotation configured) and filling up disk > space pretty fast. > 20131108.18h23m37s RESPONSE: sent status 404 (Not Found on > Accelerator) for 'http:///' > 20131108.18h23m37s RESPONSE: sent status 301 (Redirect) > for 'http:///' > I watched my tcpdump log and did not see that the 404 error was sent out at > all. I am using ATS/3.2.4 (also checked with I am seeing a lot of entries in > the error log for my url redirect request. The request was processed correctly > I could see the expected response in log as well: > 2013-11-08 18:23:37 301 FIN http://yahoo.com > http://www.yahoo.com/ > But log messages like following were printed too: > 20131108.18h23m37s RESPONSE: sent status 404 (Not Found on > Accelerator) for 'http:///' > 20131108.18h23m37s RESPONSE: sent status 301 (Redirect) > for 'http:///' > I watched my tcpdump log and did not see that the 404 error was sent out at > all. I am using ATS/3.2.4 and following > is the log configuration. > CONFIG proxy.config.log.logging_enabled INT 3 > CONFIG proxy.config.log.max_secs_per_buffer INT 1 > CONFIG proxy.config.log.max_space_mb_for_logs INT 25000 > CONFIG proxy.config.log.max_space_mb_for_orphan_logs INT 25 > CONFIG proxy.config.log.max_space_mb_headroom INT 1000 > CONFIG proxy.config.log.hostname STRING localhost > CONFIG proxy.config.log.logfile_dir STRING var/log/trafficserver > CONFIG proxy.config.log.logfile_perm STRING rw-r--r-- > CONFIG proxy.config.log.custom_logs_enabled INT 1 > CONFIG proxy.config.log.squid_log_enabled INT 0 > CONFIG proxy.config.log.squid_log_is_ascii INT 0 > CONFIG proxy.config.log.squid_log_name STRING squid > CONFIG proxy.config.log.squid_log_header STRING NULL > CONFIG proxy.config.log.common_log_enabled INT 0 > CONFIG proxy.config.log.common_log_is_ascii INT 1 > CONFIG proxy.config.log.common_log_name STRING common > CONFIG proxy.config.log.common_log_header STRING NULL > CONFIG proxy.config.log.extended_log_enabled INT 0 > CONFIG proxy.config.log.extended_log_is_ascii INT 0 > CONFIG proxy.config.log.extended_log_name STRING extended > CONFIG proxy.config.log.extended_log_header STRING NULL > CONFIG proxy.config.log.extended2_log_enabled INT 0 > CONFIG proxy.config.log.extended2_log_is_ascii INT 1 > CONFIG proxy.config.log.extended2_log_name STRING extended2 > CONFIG proxy.config.log.extended2_log_header STRING NULL > CONFIG proxy.config.log.separate_icp_logs INT 0 > CONFIG proxy.config.log.separate_host_logs INT 0 > Is this a bug or is this a misconfiguration? Does anyone have any idea?) and > following is the log configuration. > CONFIG proxy.config.log.logging_enabled INT 3 > CONFIG proxy.config.log.max_secs_per_buffer INT 1 > CONFIG proxy.config.log.max_space_mb_for_logs INT 25000 > CONFIG proxy.config.log.max_space_mb_for_orphan_logs INT 25 > CONFIG proxy.config.log.max_space_mb_headroom INT 1000 > CONFIG proxy.config.log.hostname STRING localhost > CONFIG proxy.config.log.logfile_dir STRING var/log/trafficserver > CONFIG proxy.config.log.logfile_perm STRING rw-r--r-- > CONFIG proxy.config.log.custom_logs_enabled INT 1 > CONFIG proxy.config.log.squid_log_enabled INT 0 > CONFIG proxy.config.log.squid_log_is_ascii INT 0 > CONFIG proxy.config.log.squid_log_name STRING squid > CONFIG proxy.config.log.squid_log_header STRING NULL > CONFIG proxy.config.log.common_log_enabled INT 0 > CONFIG proxy.config.log.common_log_is_ascii INT 1 > CONFIG proxy.config.log.common_log_name STRING common > CONFIG proxy.config.log.common_log_header STRING NULL > CONFIG proxy.config.log.extended_log_enabled INT 0 > CONFIG proxy.config.log.extended_log_is_ascii INT 0 > CONFIG proxy.config.log.extended_log_name STRING extended > CONFIG proxy.config.log.extended_log_header STRING NULL > CONFIG proxy.config.log.extended2_log_enabled INT 0 > CONFIG proxy.config.log.extended2_log_is_ascii INT 1 > CONFIG proxy.config.lo
[jira] [Commented] (TS-1982) Allow for @method=ALL in remap.config
[ https://issues.apache.org/jira/browse/TS-1982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13875977#comment-13875977 ] Igor Galić commented on TS-1982: Linking it to TS-2281 so we don't forget about it. > Allow for @method=ALL in remap.config > -- > > Key: TS-1982 > URL: https://issues.apache.org/jira/browse/TS-1982 > Project: Traffic Server > Issue Type: Improvement > Components: Configuration >Reporter: Leif Hedstrom > > This makes it more consistent with the configurations for ip_allow.config. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TS-1979) Investigate body factory and its use of malloc()
[ https://issues.apache.org/jira/browse/TS-1979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić updated TS-1979: --- Description: It might be a nice optimization to make it use heap allocation (that is, put the body factory on the freelist) for small bodies. (was: It might be a nice optimization to make it use heap allocation or something for small bodies.) > Investigate body factory and its use of malloc() > > > Key: TS-1979 > URL: https://issues.apache.org/jira/browse/TS-1979 > Project: Traffic Server > Issue Type: Improvement > Components: HTTP >Reporter: Leif Hedstrom > Fix For: sometime > > > It might be a nice optimization to make it use heap allocation (that is, put > the body factory on the freelist) for small bodies. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (TS-2294) Crash in LogUtils::timestamp_to_netscape_str
[
https://issues.apache.org/jira/browse/TS-2294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13875975#comment-13875975
]
Leif Hedstrom commented on TS-2294:
---
Any comments / thoughts on this ? If not, I will close.
> Crash in LogUtils::timestamp_to_netscape_str
>
>
> Key: TS-2294
> URL: https://issues.apache.org/jira/browse/TS-2294
> Project: Traffic Server
> Issue Type: Bug
>Reporter: bettydramit
>Assignee: Leif Hedstrom
> Labels: Crash
> Fix For: sometime
>
>
> gitmaster centos 6 x86_64
> {code}
>
>
> %<{chi}> % % [%] \"% %
> %\" % % \"%<{Referer}
> cqh>\" \"%<{user-agent}cqh>\" % %"/>
>
> {code}
> {code}
> /usr/bin/traffic_server - STACK TRACE:
> *** glibc detected *** /usr/bin/traffic_server: free(): invalid next size
> (normal): 0x2b12fc010f90 ***
> /lib64/libpthread.so.0(+0xf500)[0x2b1286896500]
> /usr/bin/traffic_server(LogUtils::timestamp_to_netscape_str(long)+0x41)[0x5ab821]
> /usr/bin/traffic_server(LogBuffer::resolve_custom_entry(LogFieldList*, char*,
> char*, char*, int, long, long, unsigned int, LogFieldList*,
> char*)+0x3be)[0x58bfae]
> /usr/bin/traffic_server(LogBuffer::to_ascii(LogEntryHeader*, LogFormatType,
> char*, int, char*, char*, unsigned int, char*)+0x21b)[0x58c2bb]
> /usr/bin/traffic_server(LogFile::preproc_and_try_delete(LogBuffer*)+0x3eb)[0x59df7b]
> /usr/bin/traffic_server(LogBufferManager::preproc_buffers(LogBufferSink*)+0x130)[0x5a6990]
> === Backtrace: =
> /usr/bin/traffic_server(LogObjectManager::preproc_buffers(int)+0x43)[0x5a6e63]
> /lib64/libc.so.6(+0x76126)[0x2b128783b126]
> /lib64/libc.so.6(+0x78c53)[0x2b128783dc53]
> /usr/bin/traffic_server(Log::preproc_thread_main(void*)+0x91)[0x58d6e1]
> /usr/bin/traffic_server(LoggingPreprocContinuation::mainEvent(int,
> void*)+0xd)[0x591e1d]
> /usr/bin/traffic_server(EThread::execute()+0xc90)[0x6ab390]
> /usr/bin/traffic_server[0x6a905a]
> /lib64/libpthread.so.0(+0x7851)[0x2b128688e851]
> /lib64/libc.so.6(clone+0x6d)[0x2b12878ad94d]
> /usr/bin/traffic_server(HdrHeap::destroy()+0x126)[0x5b2556]
> /usr/bin/traffic_server(HttpSM::cleanup()+0x99)[0x5207e9]
> /usr/bin/traffic_server(HttpSM::destroy()+0x9)[0x520e19]
> /usr/bin/traffic_server(HttpSM::main_handler(int, void*)+0x188)[0x52bc78]
> Oct 22 00:57:36 utn-hz-1-4-c1131 sendEmail[1919]: Email was sent successfully!
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (TS-1845) Make proxy.config.cache.max_doc_size configurable via conf_remap plugin
[ https://issues.apache.org/jira/browse/TS-1845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13875974#comment-13875974 ] Igor Galić commented on TS-1845: first off, This won't work as part of HttpConfig, because it's not part of HttpConfig, it's part of CacheConfig. We should handle this similarly to TS-1326 for storage. Finally, we should handle it as part of TS-2281. > Make proxy.config.cache.max_doc_size configurable via conf_remap plugin > --- > > Key: TS-1845 > URL: https://issues.apache.org/jira/browse/TS-1845 > Project: Traffic Server > Issue Type: Improvement > Components: Cache, Plugins >Reporter: David Carlin > Fix For: 5.3.0 > > > It would be very helpful if proxy.config.cache.max_doc_size and possibly > proxy.config.cache.ram_cache_cutoff were configurable via the conf_remap > plugin. > Of the two, proxy.config.cache.max_doc_size is more important. Thank You! -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (TS-1326) way to control the ram space usage
[ https://issues.apache.org/jira/browse/TS-1326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13875973#comment-13875973 ] Igor Galić commented on TS-1326: This needs to be part of the LuaConfig Revolution > way to control the ram space usage > -- > > Key: TS-1326 > URL: https://issues.apache.org/jira/browse/TS-1326 > Project: Traffic Server > Issue Type: Improvement > Components: Cache >Reporter: Zhao Yongming >Priority: Minor > Fix For: 5.3.0 > > > we have the ram cache binding to volume and the space is used for all > contents in the volume, with LRU. > in some situation, you'd need to give one site for more or less ram cache > because you know they demand it. > we should take the ram space as a control resource, and control it -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (TS-2101) Segmentation fault collation log server
[
https://issues.apache.org/jira/browse/TS-2101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13875970#comment-13875970
]
Leif Hedstrom commented on TS-2101:
---
Is this still an issue ? If so , please provide the details Yunkai asks for. If
not, please close.
> Segmentation fault collation log server
>
>
> Key: TS-2101
> URL: https://issues.apache.org/jira/browse/TS-2101
> Project: Traffic Server
> Issue Type: Bug
>Reporter: bettydramit
>Assignee: Yunkai Zhang
> Fix For: sometime
>
>
> gitmaster centos 6 x86_64
> {code}
> zym@zymtest1 /tmp $ c++filt < c
> [TrafficServer] using root directory '/usr'
> NOTE: Traffic Server received Sig 11: Segmentation fault
> /usr/bin/traffic_server - STACK TRACE:
> /lib64/libpthread.so.0(+0xf500)[0x2b324c3a5500]
> /usr/bin/traffic_server(LogObjectManager::get_object_with_signature(unsigned
> long)+0x24)[0x5a28e4]
> /usr/bin/traffic_server(Log::match_logobject(LogBufferHeader*)+0x3b)[0x58b98b]
> /usr/bin/traffic_server(LogCollationHostSM::host_recv(int,
> void*)+0x1e0)[0x5ad940]
> /usr/bin/traffic_server[0x671291]
> /usr/bin/traffic_server[0x673f8a]
> /usr/bin/traffic_server(NetHandler::mainNetEvent(int, Event*)+0x1f2)[0x66c422]
> /usr/bin/traffic_server(EThread::process_event(Event*, int)+0x84)[0x696b64]
> /usr/bin/traffic_server(EThread::execute()+0x4bb)[0x69754b]
> /usr/bin/traffic_server[0x695ae2]
> /lib64/libpthread.so.0(+0x7851)[0x2b324c39d851]
> /lib64/libc.so.6(clone+0x6d)[0x2b324ea2f11d]
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (TS-2088) Change TSRecordType enum values to powers of two
[ https://issues.apache.org/jira/browse/TS-2088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13875969#comment-13875969 ] Leif Hedstrom commented on TS-2088: --- Phil, are you going to do this? :) > Change TSRecordType enum values to powers of two > > > Key: TS-2088 > URL: https://issues.apache.org/jira/browse/TS-2088 > Project: Traffic Server > Issue Type: Improvement >Reporter: Phil Sorber >Assignee: Phil Sorber >Priority: Minor > Labels: C > Fix For: sometime > > > This way we can OR them together and do multiple types at once. Also add an > "ALL" value. This should not effect the API compatibility with old usage. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (TS-2084) support forcing to put some very hot url in ram?
[ https://issues.apache.org/jira/browse/TS-2084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-2084. --- Resolution: Won't Fix Fix Version/s: (was: sometime) No traction here, and no response, so closing as won't fix. Reopen if necessary. > support forcing to put some very hot url in ram? > > > Key: TS-2084 > URL: https://issues.apache.org/jira/browse/TS-2084 > Project: Traffic Server > Issue Type: Improvement > Components: Cache, HTTP >Reporter: Bin Chen >Assignee: Bin Chen > > 1. should ts support forcing to put some very hot url in ram by cache.config? -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (TS-1326) way to control the ram space usage
[ https://issues.apache.org/jira/browse/TS-1326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13875968#comment-13875968 ] Igor Galić commented on TS-1326: This needs to be related to TS-2281 (The luaConfig Revolution) > way to control the ram space usage > -- > > Key: TS-1326 > URL: https://issues.apache.org/jira/browse/TS-1326 > Project: Traffic Server > Issue Type: Improvement > Components: Cache >Reporter: Zhao Yongming >Priority: Minor > Fix For: 5.3.0 > > > we have the ram cache binding to volume and the space is used for all > contents in the volume, with LRU. > in some situation, you'd need to give one site for more or less ram cache > because you know they demand it. > we should take the ram space as a control resource, and control it -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (TS-1697) Add basic authentication for parent proxy
[ https://issues.apache.org/jira/browse/TS-1697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13875967#comment-13875967 ] Bryan Call commented on TS-1697: This can be implemented in header_rewrite if set-status on the read response hook would send an error to the client. > Add basic authentication for parent proxy > - > > Key: TS-1697 > URL: https://issues.apache.org/jira/browse/TS-1697 > Project: Traffic Server > Issue Type: Improvement > Components: Core, Security >Reporter: ilya stromberg > Fix For: sometime > > > We should add the basic access authentication method for parent proxy. > Without this feature we can use only open parent proxy or ip-based > authentication method, but we can have dynamic ip-adrees. > The basic authentication is trivial. Description can be found here: > http://en.wikipedia.org/wiki/Basic_access_authentication -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (TS-2066) FATAL: HttpTransact.cc:1564: failed assert `s->dns_info.attempts >= max_dns_lookups`
[
https://issues.apache.org/jira/browse/TS-2066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13875965#comment-13875965
]
Leif Hedstrom commented on TS-2066:
---
Any more details on this ? If not, I think we'll close this.
> FATAL: HttpTransact.cc:1564: failed assert `s->dns_info.attempts >=
> max_dns_lookups`
>
>
> Key: TS-2066
> URL: https://issues.apache.org/jira/browse/TS-2066
> Project: Traffic Server
> Issue Type: Bug
>Affects Versions: 3.2.5
>Reporter: imtif
>Priority: Critical
> Fix For: sometime
>
>
> OS:Centos 5.9 x86_64
> ats version:3.2.5
> FATAL: HttpTransact.cc:1564: failed assert `s->dns_info.attempts >=
> max_dns_lookups`
> /usr/local/bin/traffic_server - STACK TRACE:
> /usr/local/lib/libtsutil.so.3(ink_fatal+0x88)[0x2b5532eb1758]
> /usr/local/lib/libtsutil.so.3(_ink_assert+0x1f)[0x2b5532eaffbf]
> /usr/local/bin/traffic_server(_ZN12HttpTransact11OSDNSLookupEPNS_5StateE+0xaef)[0x56802f]
> /usr/local/bin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x64)[0x5215e4]
> /usr/local/bin/traffic_server(_ZN6HttpSM19state_hostdb_lookupEiPv+0xb0)[0x529180]
> /usr/local/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0xdc)[0x53082c]
> /usr/local/bin/traffic_server[0x5e5d16]
> /usr/local/bin/traffic_server(_ZN18HostDBContinuation8dnsEventEiP7HostEnt+0x7e1)[0x5eaab1]
> /usr/local/bin/traffic_server(_ZN8DNSEntry9postEventEiP5Event+0xe5)[0x5f7a75]
> /usr/local/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x22f)[0x6b998f]
> /usr/local/bin/traffic_server(_ZN7EThread7executeEv+0x1aa)[0x6b9e8a]
> /usr/local/bin/traffic_server[0x6b8dde]
> /lib64/libpthread.so.0[0x31fda0683d]
> /lib64/libc.so.6(clone+0x6d)[0x31fd2d4f8d]
> [Jul 25 12:50:48.305] Manager {0x2ae40da788c0} ERROR:
> [LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig 6:
> Aborted
> [Jul 25 12:50:48.305] Manager {0x2ae40da788c0} ERROR: (last system error 2:
> No such file or directory)
> [Jul 25 12:50:48.305] Manager {0x2ae40da788c0} ERROR: [Alarms::signalAlarm]
> Server Process was reset
> [Jul 25 12:50:48.305] Manager {0x2ae40da788c0} ERROR: (last system error 2:
> No such file or directory)
> [Jul 25 12:50:49.308] Manager {0x2ae40da788c0} NOTE:
> [LocalManager::startProxy] Launching ts process
> [TrafficServer] using root directory '/usr/local'
> [Jul 25 12:50:49.319] Manager {0x2ae40da788c0} NOTE:
> [LocalManager::pollMgmtProcessServer] New process connecting fd '14'
> [Jul 25 12:50:49.319] Manager {0x2ae40da788c0} NOTE: [Alarms::signalAlarm]
> Server Process born
> [Jul 25 12:50:50.332] {0x2aca84844930} STATUS: opened
> /usr/local/var/log/trafficserver/diags.log
> [Jul 25 12:50:50.332] {0x2aca84844930} NOTE: updated diags config
> [Jul 25 12:50:50.335] Server {0x2aca84844930} NOTE: cache clustering disabled
> [Jul 25 12:50:50.349] Server {0x2aca84844930} NOTE: cache clustering disabled
> [Jul 25 12:50:50.366] Server {0x2aca84844930} NOTE: logging initialized[15],
> logging_mode = 0
> [Jul 25 12:50:50.369] Server {0x2aca84844930} NOTE: loading plugin
> '/usr/local/libexec/trafficserver/cacheurl.so'
> [Jul 25 12:50:50.371] Server {0x2aca84844930} NOTE: traffic server running
> [Jul 25 12:51:12.752] Server {0x2aca869e1940} NOTE: cache enabled
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Assigned] (TS-2065) full-url feature has been removed from the regex_remap plugin
[ https://issues.apache.org/jira/browse/TS-2065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-2065: - Assignee: Leif Hedstrom > full-url feature has been removed from the regex_remap plugin > - > > Key: TS-2065 > URL: https://issues.apache.org/jira/browse/TS-2065 > Project: Traffic Server > Issue Type: Bug > Components: Plugins >Reporter: Justin Bennett >Assignee: Leif Hedstrom > Fix For: 5.1.0 > > > It seems there used to be a full-url parameter that could be passed to the > regex_remap plugin so that regexes could be matched on the full URL rather > than just on the query string. That functionality is not in the code at this > time. I spoke with user zwoop on IRC today and he indicated that it is > something that could probably be put back in and to file a bug report if I > thought I needed it, which I think I do. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TS-2065) full-url feature has been removed from the regex_remap plugin
[ https://issues.apache.org/jira/browse/TS-2065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2065: -- Fix Version/s: (was: sometime) 5.1.0 > full-url feature has been removed from the regex_remap plugin > - > > Key: TS-2065 > URL: https://issues.apache.org/jira/browse/TS-2065 > Project: Traffic Server > Issue Type: Bug > Components: Plugins >Reporter: Justin Bennett > Fix For: 5.1.0 > > > It seems there used to be a full-url parameter that could be passed to the > regex_remap plugin so that regexes could be matched on the full URL rather > than just on the query string. That functionality is not in the code at this > time. I spoke with user zwoop on IRC today and he indicated that it is > something that could probably be put back in and to file a bug report if I > thought I needed it, which I think I do. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (TS-2049) Remove new_RamCache*
[ https://issues.apache.org/jira/browse/TS-2049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-2049. --- Resolution: Won't Fix Fix Version/s: (was: sometime) Since no need for this, closing. > Remove new_RamCache* > > > Key: TS-2049 > URL: https://issues.apache.org/jira/browse/TS-2049 > Project: Traffic Server > Issue Type: Improvement >Reporter: Phil Sorber >Assignee: Phil Sorber >Priority: Trivial > > There are two functions, new_RamCacheLRU and new_RamCacheCLFUS that only wrap > a 'new RamCacheLRU;' and 'new RamCacheCLFUS;' calls respectively. I'm for > exposing the RamCacheLRU and RamCacheCLFUS classes, but I would also be happy > just seeing a param passed to 'new RamCache;' that would dictate the type > instantiated. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TS-2031) Two SSL certs with overlapping CNs stomps over each other without warnings
[ https://issues.apache.org/jira/browse/TS-2031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2031: -- Fix Version/s: (was: sometime) 5.1.0 > Two SSL certs with overlapping CNs stomps over each other without warnings > -- > > Key: TS-2031 > URL: https://issues.apache.org/jira/browse/TS-2031 > Project: Traffic Server > Issue Type: Bug > Components: SSL >Reporter: Leif Hedstrom >Priority: Minor > Fix For: 5.1.0 > > > If you have two certs that has the same CNs, the last one wins in the SNI > negotiation. This even takes precedence over "assigned" IPs (SNI trumps IP). > We should at least warn on this. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (TS-1989) Crash report: HdrCsvIter::find_csv
[
https://issues.apache.org/jira/browse/TS-1989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13875962#comment-13875962
]
Leif Hedstrom commented on TS-1989:
---
Any details on this bug? Is it still an issue? What can be done to reproduce?
If no more details, will close as "Can't reproduce".
> Crash report: HdrCsvIter::find_csv
> --
>
> Key: TS-1989
> URL: https://issues.apache.org/jira/browse/TS-1989
> Project: Traffic Server
> Issue Type: Bug
> Components: Cache, HTTP
>Affects Versions: 3.3.4
> Environment: Apache Traffic Server - traffic_server - 3.3.4-dev -
> (build # 52714 on Jun 27 2013 at 14:54:29)
> reverse proxy, with read_while_writer=0
>Reporter: yin
> Labels: Crash
> Fix For: sometime
>
>
> v3.3.4 with default configure options
> {code}
> NOTE: Traffic Server received Sig 11: Segmentation fault
> /usr/local/bin/traffic_server - STACK TRACE:
> /lib64/libpthread.so.0[0x35a2a0eca0]
> /usr/local/bin/traffic_server(HdrCsvIter::find_csv()+0x16)[0x5b5e96]
> /usr/local/bin/traffic_server(HttpTransactHeaders::_process_xxx_connection_field_in_outgoing_header(char
> const*, int, HTTPHdr*, HTTPHdr*)+0xb3)[0x561113]
> /usr/local/bin/traffic_server(HttpTransactHeaders::process_connection_headers(HTTPHdr*,
> HTTPHdr*)+0x2c)[0x5613ac]
> /usr/local/bin/traffic_server(HttpTransact::build_response(HttpTransact::State*,
> HTTPHdr*, HTTPHdr*, HTTPVersion, HTTPStatus, char const*)+0x1f8)[0x5465d8]
> /usr/local/bin/traffic_server(HttpTransact::build_response_from_cache(HttpTransact::State*,
> HTTPWarningCode)+0x2fa)[0x55830a]
> /usr/local/bin/traffic_server(HttpTransact::HandleCacheOpenReadHit(HttpTransact::State*)+0x37c)[0x55979c]
> /usr/local/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void
> (*)(HttpTransact::State*))+0x66)[0x517be6]
> /usr/local/bin/traffic_server(HttpSM::set_next_state()+0x3f4)[0x533c84]
> /usr/local/bin/traffic_server(HttpSM::set_next_state()+0x3f4)[0x533c84]
> /usr/local/bin/traffic_server(HttpSM::state_cache_open_read(int,
> void*)+0x110)[0x529ec0]
> /usr/local/bin/traffic_server(HttpSM::main_handler(int, void*)+0xcc)[0x52ce9c]
> /usr/local/bin/traffic_server(HttpCacheSM::state_cache_open_read(int,
> void*)+0xf5)[0x508395]
> /usr/local/bin/traffic_server(CacheVC::openReadStartHead(int,
> Event*)+0xc43)[0x650653]
> /usr/local/bin/traffic_server(CacheVC::handleReadDone(int,
> Event*)+0x395)[0x62ac85]
> /usr/local/bin/traffic_server(Cache::open_read(Continuation*, INK_MD5*,
> HTTPHdr*, CacheLookupHttpConfig*, CacheFragType, char*, int)+0x77e)[0x6587de]
> /usr/local/bin/traffic_server(CacheProcessor::open_read(Continuation*, URL*,
> bool, HTTPHdr*, CacheLookupHttpConfig*, long, CacheFragType)+0xa8)[0x627f88]
> /usr/local/bin/traffic_server(HttpCacheSM::open_read(URL*, HTTPHdr*,
> CacheLookupHttpConfig*, long)+0x94)[0x508094]
> /usr/local/bin/traffic_server(HttpSM::do_cache_lookup_and_read()+0xf1)[0x51b171]
> /usr/local/bin/traffic_server(HttpSM::set_next_state()+0x7b8)[0x534048]
> /usr/local/bin/traffic_server(HttpSM::set_next_state()+0x3f4)[0x533c84]
> /usr/local/bin/traffic_server(HttpSM::set_next_state()+0xa04)[0x534294]
> /usr/local/bin/traffic_server(HttpSM::set_next_state()+0x3f4)[0x533c84]
> /usr/local/bin/traffic_server(HttpSM::set_next_state()+0x3f4)[0x533c84]
> /usr/local/bin/traffic_server(HttpSM::state_read_client_request_header(int,
> void*)+0x389)[0x52c079]
> /usr/local/bin/traffic_server(HttpSM::main_handler(int, void*)+0xcc)[0x52ce9c]
> /usr/local/bin/traffic_server[0x687124]
> /usr/local/bin/traffic_server(NetHandler::mainNetEvent(int,
> Event*)+0x474)[0x67f7f4]
> /usr/local/bin/traffic_server(EThread::process_event(Event*,
> int)+0x238)[0x6ad108]
> /usr/local/bin/traffic_server(EThread::execute()+0x625)[0x6adaa5]
> /usr/local/bin/traffic_server[0x6acbce]
> /lib64/libpthread.so.0[0x35a2a0683d]
> /lib64/libc.so.6(clone+0x6d)[0x35a1ed4f8d]
> [E. Mgmt] log ==> [TrafficManager] using root directory
> '/usr/local/trafficserver'
> [TrafficServer] using root directory '/usr/local/trafficserver'
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Resolved] (TS-1982) Allow for @method=ALL in remap.config
[ https://issues.apache.org/jira/browse/TS-1982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-1982. --- Resolution: Won't Fix Fix Version/s: (was: sometime) this is ugly, and difficult, closing for now. It's possible this can be nicely generalized as part of the Lua stuff :). > Allow for @method=ALL in remap.config > -- > > Key: TS-1982 > URL: https://issues.apache.org/jira/browse/TS-1982 > Project: Traffic Server > Issue Type: Improvement > Components: Configuration >Reporter: Leif Hedstrom > > This makes it more consistent with the configurations for ip_allow.config. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (TS-1956) Under Heavy Load TS 3.3.4-dev can't (re)start
[
https://issues.apache.org/jira/browse/TS-1956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13875960#comment-13875960
]
Leif Hedstrom commented on TS-1956:
---
Bryan, I was not able to reproduce this, can you take a look ? Sounds like you
just have to a) put pressure on the system, and then kill -9 the
traffic_server process.
> Under Heavy Load TS 3.3.4-dev can't (re)start
> -
>
> Key: TS-1956
> URL: https://issues.apache.org/jira/browse/TS-1956
> Project: Traffic Server
> Issue Type: Bug
>Reporter: Tommy Lee
>Assignee: Bryan Call
>Priority: Blocker
> Labels: Crash
> Fix For: sometime
>
> Attachments: backtrace.log
>
>
> Hi,
> We run TS in forward mode, under REALLY HEAVY load. Currently we run version
> 3.3.2-dev without problems.
> But today, we tried to upgrade to version 3.3.4-dev without lucky.
> We've noticed that, if TS restarts, it enters in this Segfault Loop.
> Below are traffic.out logs with debug .*
> I'll try to debug with GDB too, but I cannot stop this server for too long,
> because of our operations.
> Thanks in advance.
>
> {code}
> [Jun 14 11:54:14.563] Server {0x2b069d226500} DEBUG: (iocore_net_processor)
> NetProcessor::main_accept - port 3128,recv_bufsize 0, send_bufsize 262144,
> sockopt 0x0
> [Jun 14 11:54:14.563] Server {0x2b069d226500} DEBUG: (http_tproxy) Marking
> accept server 0x20fd9e0 on port 3128 as inbound transparent
> [Jun 14 11:54:14.563] Server {0x2b069d226500} DEBUG: (http_tproxy) Listen
> port inbound transparency enabled.
> [Jun 14 11:54:14.563] Server {0x2b069d226500} DEBUG: (iocore_net_accept)
> Created accept thread #1 for port 3128
> [Jun 14 11:54:14.563] Server {0x2b069d226500} DEBUG: (iocore_net_processor)
> NetProcessor::main_accept - port 3128,recv_bufsize 0, send_bufsize 262144,
> sockopt 0x0
> [Jun 14 11:54:14.563] Server {0x2b069d226500} DEBUG: (http_tproxy) Marking
> accept server 0x20fdd00 on port 3128 as inbound transparent
> [Jun 14 11:54:14.563] Server {0x2b069d226500} DEBUG: (http_tproxy) Listen
> port inbound transparency enabled.
> [Jun 14 11:54:14.563] Server {0x2b069d226500} DEBUG: (iocore_net_accept)
> Created accept thread #1 for port 3128
> [Jun 14 11:54:14.563] Server {0x2b0850514700} DEBUG: (iocore_net_server)
> Connection accepted [Server]. 10.202.81.5:46089 -> *Not IP address [0]*:0
> [Jun 14 11:54:14.564] Server {0x2b0850514700} DEBUG: (iocore_net_server)
> Connection accepted [Server]. 10.202.101.4:41361 -> *Not IP address [0]*:0
> [Jun 14 11:54:14.564] Server {0x2b0850514700} DEBUG: (iocore_net_server)
> Connection accepted [Server]. 10.200.156.38:59164 -> *Not IP address [0]*:0
> [Jun 14 11:54:14.564] Server {0x2b06a5413700} DEBUG: (http_seq)
> [HttpAccept:mainEvent 0x2b085c00] accepted connection from
> 10.202.81.5:46089 transport type = 0
> [Jun 14 11:54:14.564] Server {0x2b0850514700} DEBUG: (iocore_net_server)
> Connection accepted [Server]. 10.200.35.9:51533 -> *Not IP address [0]*:0
> [Jun 14 11:54:14.564] Server {0x2b0850514700} DEBUG: (iocore_net_server)
> Connection accepted [Server]. 10.200.201.20:10964 -> *Not IP address [0]*:0
> [Jun 14 11:54:14.564] Server {0x2b06a5615700} DEBUG: (http_seq)
> [HttpAccept:mainEvent 0x2b085c015a80] accepted connection from
> 10.200.156.38:59164 transport type = 0
> [Jun 14 11:54:14.564] Server {0x2b069d226500} DEBUG: (iocore_net_processor)
> NetProcessor::main_accept - port 3128,recv_bufsize 0, send_bufsize 262144,
> sockopt 0x0
> [Jun 14 11:54:14.564] Server {0x2b0850514700} DEBUG: (iocore_net_server)
> Connection accepted [Server]. 10.202.148.2:44203 -> *Not IP address [0]*:0
> [Jun 14 11:54:14.564] Server {0x2b069d226500} DEBUG: (http_tproxy) Marking
> accept server 0x20fe020 on port 3128 as inbound transparent
> [Jun 14 11:54:14.564] Server {0x2b06a5514700} DEBUG: (http_seq)
> [HttpAccept:mainEvent 0x2b085c015d20] accepted connection from
> 10.202.101.4:41361 transport type = 0
> [Jun 14 11:54:14.564] Server {0x2b06a5817700} DEBUG: (http_seq)
> [HttpAccept:mainEvent 0x2b085c015540] accepted connection from
> 10.200.201.20:10964 transport type = 0NOTE: Traffic Server received Sig 11:
> Segmentation fault
> /usr/local/cache-3.3.4/bin/traffic_server - STACK TRACE:
> [Jun 14 11:54:14.564] Server {0x2b069d226500} DEBUG: (http_tproxy) Listen
> port inbound transparency enabled.
> [Jun 14 11:54:14.564] Server {0x2b069d226500} DEBUG: (iocore_net_accept)
> Created accept thread #1 for port 3128
> NOTE: Traffic Server received Sig 11: Segmentation fault
> [Jun 14 11:54:14.564] Server {0x2b06a5716700} DEBUG: (http_seq)
> [HttpAccept:mainEvent 0x2b085c0157e0] accepted connection from
> 10.200.35.9:51533 transport type = 0/usr/local/cache-3.3.4/bin/traffic_server
> - STACK TR
[jira] [Updated] (TS-1956) Under Heavy Load TS 3.3.4-dev can't (re)start
[
https://issues.apache.org/jira/browse/TS-1956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1956:
--
Assignee: Bryan Call
> Under Heavy Load TS 3.3.4-dev can't (re)start
> -
>
> Key: TS-1956
> URL: https://issues.apache.org/jira/browse/TS-1956
> Project: Traffic Server
> Issue Type: Bug
>Reporter: Tommy Lee
>Assignee: Bryan Call
>Priority: Blocker
> Labels: Crash
> Fix For: sometime
>
> Attachments: backtrace.log
>
>
> Hi,
> We run TS in forward mode, under REALLY HEAVY load. Currently we run version
> 3.3.2-dev without problems.
> But today, we tried to upgrade to version 3.3.4-dev without lucky.
> We've noticed that, if TS restarts, it enters in this Segfault Loop.
> Below are traffic.out logs with debug .*
> I'll try to debug with GDB too, but I cannot stop this server for too long,
> because of our operations.
> Thanks in advance.
>
> {code}
> [Jun 14 11:54:14.563] Server {0x2b069d226500} DEBUG: (iocore_net_processor)
> NetProcessor::main_accept - port 3128,recv_bufsize 0, send_bufsize 262144,
> sockopt 0x0
> [Jun 14 11:54:14.563] Server {0x2b069d226500} DEBUG: (http_tproxy) Marking
> accept server 0x20fd9e0 on port 3128 as inbound transparent
> [Jun 14 11:54:14.563] Server {0x2b069d226500} DEBUG: (http_tproxy) Listen
> port inbound transparency enabled.
> [Jun 14 11:54:14.563] Server {0x2b069d226500} DEBUG: (iocore_net_accept)
> Created accept thread #1 for port 3128
> [Jun 14 11:54:14.563] Server {0x2b069d226500} DEBUG: (iocore_net_processor)
> NetProcessor::main_accept - port 3128,recv_bufsize 0, send_bufsize 262144,
> sockopt 0x0
> [Jun 14 11:54:14.563] Server {0x2b069d226500} DEBUG: (http_tproxy) Marking
> accept server 0x20fdd00 on port 3128 as inbound transparent
> [Jun 14 11:54:14.563] Server {0x2b069d226500} DEBUG: (http_tproxy) Listen
> port inbound transparency enabled.
> [Jun 14 11:54:14.563] Server {0x2b069d226500} DEBUG: (iocore_net_accept)
> Created accept thread #1 for port 3128
> [Jun 14 11:54:14.563] Server {0x2b0850514700} DEBUG: (iocore_net_server)
> Connection accepted [Server]. 10.202.81.5:46089 -> *Not IP address [0]*:0
> [Jun 14 11:54:14.564] Server {0x2b0850514700} DEBUG: (iocore_net_server)
> Connection accepted [Server]. 10.202.101.4:41361 -> *Not IP address [0]*:0
> [Jun 14 11:54:14.564] Server {0x2b0850514700} DEBUG: (iocore_net_server)
> Connection accepted [Server]. 10.200.156.38:59164 -> *Not IP address [0]*:0
> [Jun 14 11:54:14.564] Server {0x2b06a5413700} DEBUG: (http_seq)
> [HttpAccept:mainEvent 0x2b085c00] accepted connection from
> 10.202.81.5:46089 transport type = 0
> [Jun 14 11:54:14.564] Server {0x2b0850514700} DEBUG: (iocore_net_server)
> Connection accepted [Server]. 10.200.35.9:51533 -> *Not IP address [0]*:0
> [Jun 14 11:54:14.564] Server {0x2b0850514700} DEBUG: (iocore_net_server)
> Connection accepted [Server]. 10.200.201.20:10964 -> *Not IP address [0]*:0
> [Jun 14 11:54:14.564] Server {0x2b06a5615700} DEBUG: (http_seq)
> [HttpAccept:mainEvent 0x2b085c015a80] accepted connection from
> 10.200.156.38:59164 transport type = 0
> [Jun 14 11:54:14.564] Server {0x2b069d226500} DEBUG: (iocore_net_processor)
> NetProcessor::main_accept - port 3128,recv_bufsize 0, send_bufsize 262144,
> sockopt 0x0
> [Jun 14 11:54:14.564] Server {0x2b0850514700} DEBUG: (iocore_net_server)
> Connection accepted [Server]. 10.202.148.2:44203 -> *Not IP address [0]*:0
> [Jun 14 11:54:14.564] Server {0x2b069d226500} DEBUG: (http_tproxy) Marking
> accept server 0x20fe020 on port 3128 as inbound transparent
> [Jun 14 11:54:14.564] Server {0x2b06a5514700} DEBUG: (http_seq)
> [HttpAccept:mainEvent 0x2b085c015d20] accepted connection from
> 10.202.101.4:41361 transport type = 0
> [Jun 14 11:54:14.564] Server {0x2b06a5817700} DEBUG: (http_seq)
> [HttpAccept:mainEvent 0x2b085c015540] accepted connection from
> 10.200.201.20:10964 transport type = 0NOTE: Traffic Server received Sig 11:
> Segmentation fault
> /usr/local/cache-3.3.4/bin/traffic_server - STACK TRACE:
> [Jun 14 11:54:14.564] Server {0x2b069d226500} DEBUG: (http_tproxy) Listen
> port inbound transparency enabled.
> [Jun 14 11:54:14.564] Server {0x2b069d226500} DEBUG: (iocore_net_accept)
> Created accept thread #1 for port 3128
> NOTE: Traffic Server received Sig 11: Segmentation fault
> [Jun 14 11:54:14.564] Server {0x2b06a5716700} DEBUG: (http_seq)
> [HttpAccept:mainEvent 0x2b085c0157e0] accepted connection from
> 10.200.35.9:51533 transport type = 0/usr/local/cache-3.3.4/bin/traffic_server
> - STACK TRACE:
> [Jun 14 11:54:14.564] Server {0x2b085c120700} DEBUG: (iocore_net_server)
> Connection accepted [Server]. 10.200.131.24:65434 -> *Not IP address [0]*:0
> [Jun 14 11:54:14.564] Server {0x2b0850514
[jira] [Updated] (TS-1845) Make proxy.config.cache.max_doc_size configurable via conf_remap plugin
[ https://issues.apache.org/jira/browse/TS-1845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić updated TS-1845: --- Fix Version/s: (was: sometime) 5.3.0 > Make proxy.config.cache.max_doc_size configurable via conf_remap plugin > --- > > Key: TS-1845 > URL: https://issues.apache.org/jira/browse/TS-1845 > Project: Traffic Server > Issue Type: Improvement > Components: Cache, Plugins >Reporter: David Carlin > Fix For: 5.3.0 > > > It would be very helpful if proxy.config.cache.max_doc_size and possibly > proxy.config.cache.ram_cache_cutoff were configurable via the conf_remap > plugin. > Of the two, proxy.config.cache.max_doc_size is more important. Thank You! -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (TS-1950) tsxs should generate sample plugin codes
[
https://issues.apache.org/jira/browse/TS-1950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13875959#comment-13875959
]
Leif Hedstrom commented on TS-1950:
---
Is anyone going to work on this? I don't really feel this should be part of
tsxs, but if that's what you'd like, go ahead. Someone should probably own this
though if it's something we want.
> tsxs should generate sample plugin codes
>
>
> Key: TS-1950
> URL: https://issues.apache.org/jira/browse/TS-1950
> Project: Traffic Server
> Issue Type: New Feature
> Components: Plugins
>Reporter: Zhao Yongming
> Fix For: sometime
>
>
> Apache Httpd ships the apxs2 with a `-g`, which will generate a new plugin
> with the inline skeleton, we should implement that feature too.
> {code}
> apxs -n %NAME% -g
> {code}
> we need take care of the Global plugin and Remap plugin, :D
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Created] (TS-2512) Optimize performance in channel_stats plugin
Leif Hedstrom created TS-2512:
-
Summary: Optimize performance in channel_stats plugin
Key: TS-2512
URL: https://issues.apache.org/jira/browse/TS-2512
Project: Traffic Server
Issue Type: Improvement
Components: Plugins
Reporter: Leif Hedstrom
Using per-remap ("instance") data, we could pre-calculate a lot of the things
(such as metrics names / indexes) such that we don't have to look it up on
every request. Instead, it can just use the pre-calculated information.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Resolved] (TS-1814) We only allow caching zero-length documents if there is an explicit Content-Length: 0 header.
[ https://issues.apache.org/jira/browse/TS-1814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-1814. --- Resolution: Won't Fix Fix Version/s: (was: sometime) Closing this as Won't Fix, no one seems to really want this anyways. The use cases for it seems to be nonexistent :) > We only allow caching zero-length documents if there is an explicit > Content-Length: 0 header. > - > > Key: TS-1814 > URL: https://issues.apache.org/jira/browse/TS-1814 > Project: Traffic Server > Issue Type: Improvement > Components: HTTP >Reporter: Leif Hedstrom > > See TS-621 for more details, which has the partial fix. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (TS-1759) encouter Sig 11 while enable cluster
[ https://issues.apache.org/jira/browse/TS-1759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-1759. --- Resolution: Duplicate Fix Version/s: (was: sometime) I'm going to close this as a dupe of TS-1666. > encouter Sig 11 while enable cluster > > > Key: TS-1759 > URL: https://issues.apache.org/jira/browse/TS-1759 > Project: Traffic Server > Issue Type: Bug > Components: Clustering >Reporter: hu xiao >Assignee: portl4t > > I have two box running ATS and they are nomally when running separately. > But if enable cluster, they are random reboot, and have " Sig 11 " in > traffic.out. > The core.dump in gdb : > Core was generated by `traffic_server'. > Program terminated with signal 11, Segmentation fault. > Reading symbols from /usr/local/trafficserver/lib/libtsutil.so.6...done. > Loaded symbols for /usr/local/trafficserver/lib/libtsutil.so.6 > Reading symbols from /lib/libthr.so.3...done. > Loaded symbols for /lib/libthr.so.3 > Reading symbols from /usr/lib/librt.so.1...done. > Loaded symbols for /usr/lib/librt.so.1 > Reading symbols from /usr/local/lib/libpcre.so.3...done. > Loaded symbols for /usr/local/lib/libpcre.so.3 > Reading symbols from /usr/lib/libssl.so.6...done. > Loaded symbols for /usr/lib/libssl.so.6 > Reading symbols from /lib/libcrypto.so.6...done. > Loaded symbols for /lib/libcrypto.so.6 > Reading symbols from /usr/local/lib/libtcl85.so.1...done. > Loaded symbols for /usr/local/lib/libtcl85.so.1 > Reading symbols from /usr/local/lib/libexpat.so.6...done. > Loaded symbols for /usr/local/lib/libexpat.so.6 > Reading symbols from /usr/local/lib/libiconv.so.3...done. > Loaded symbols for /usr/local/lib/libiconv.so.3 > Reading symbols from /lib/libz.so.6...done. > Loaded symbols for /lib/libz.so.6 > Reading symbols from /usr/lib/liblzma.so.5...done. > Loaded symbols for /usr/lib/liblzma.so.5 > Reading symbols from /usr/local/lib/libexecinfo.so.1...done. > Loaded symbols for /usr/local/lib/libexecinfo.so.1 > Reading symbols from /usr/lib/libstdc++.so.6...done. > Loaded symbols for /usr/lib/libstdc++.so.6 > Reading symbols from /lib/libm.so.5...done. > Loaded symbols for /lib/libm.so.5 > Reading symbols from /lib/libgcc_s.so.1...done. > Loaded symbols for /lib/libgcc_s.so.1 > Reading symbols from /lib/libc.so.7...done. > Loaded symbols for /lib/libc.so.7 > Reading symbols from /usr/lib/libsupc++.so.1...done. > Loaded symbols for /usr/lib/libsupc++.so.1 > Reading symbols from /libexec/ld-elf.so.1...done. > Loaded symbols for /libexec/ld-elf.so.1 > #0 UnixNetVConnection::do_io_write (this=0x81b5cc240, c=0xfab8, nbytes=0, > reader=0x0, owner=false) at Ptr.h:414 > 414 Ptr.h: No such file or directory. > in Ptr.h > [New Thread 8050e8c00 (LWP 100933/traffic_server)] > [New Thread 8050e8800 (LWP 100932/traffic_server)] > [New Thread 8050e8400 (LWP 100931/traffic_server)] > [New Thread 8050e8000 (LWP 100930/traffic_server)] > [New Thread 8050e7c00 (LWP 100929/traffic_server)] > [New Thread 80380e400 (LWP 100928/traffic_server)] > [New Thread 80380e000 (LWP 100927/traffic_server)] > [New Thread 80380dc00 (LWP 100926/traffic_server)] > [New Thread 80380d800 (LWP 100925/traffic_server)] > [New Thread 80380d400 (LWP 100924/traffic_server)] > [New Thread 80380d000 (LWP 100923/traffic_server)] > [New Thread 80380cc00 (LWP 100922/traffic_server)] > [New Thread 80380c800 (LWP 100921/traffic_server)] > [New Thread 80380c400 (LWP 100920/traffic_server)] > [New Thread 80380c000 (LWP 100919/traffic_server)] > [New Thread 80380bc00 (LWP 100918/traffic_server)] > [New Thread 80380b800 (LWP 100917/traffic_server)] > [New Thread 80380b400 (LWP 100916/traffic_server)] > [New Thread 80380b000 (LWP 100915/traffic_server)] > [New Thread 80380ac00 (LWP 100914/traffic_server)] > [New Thread 80380a800 (LWP 100882/traffic_server)] > [New Thread 80380a400 (LWP 100881/traffic_server)] > [New Thread 80380a000 (LWP 100877/traffic_server)] > [New Thread 803809c00 (LWP 100875/traffic_server)] > [New Thread 803809800 (LWP 100874/traffic_server)] > [New Thread 803809400 (LWP 100873/traffic_server)] > [New Thread 803809000 (LWP 100872/traffic_server)] > [New Thread 803808c00 (LWP 100871/traffic_server)] > [New Thread 803808800 (LWP 100870/traffic_server)] > [New Thread 803808400 (LWP 100869/traffic_server)] > [New Thread 803807800 (LWP 100867/traffic_server)] > [New Thread 803807400 (LWP 100241/traffic_server)] > (gdb) bt > #0 UnixNetVConnection::do_io_write (this=0x81b5cc240, c=0xfab8, nbytes=0, > reader=0x0, owner=false) at Ptr.h:414 > #1 0x00526a71 in HttpSessionManager::release_session (this=0x9aad60, > to_release=0x8036dd860) at HttpSessionManager.cc:309 > #2 0x0052ee22 in HttpSM::tunnel_handler_server (this=0x81b6c6e30, > event=58905600, p=0x8036dd860) at HttpSM.cc:2893 > #3 0
[jira] [Commented] (TS-1689) Wccp doesn't compile on OmniOS/gcc-4.7
[
https://issues.apache.org/jira/browse/TS-1689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13875953#comment-13875953
]
Igor Galić commented on TS-1689:
[~jpe...@apache.org] can you please help me create jobs for jenkins for gcc 4.7
and gcc 4.8, please?
> Wccp doesn't compile on OmniOS/gcc-4.7
> --
>
> Key: TS-1689
> URL: https://issues.apache.org/jira/browse/TS-1689
> Project: Traffic Server
> Issue Type: Bug
> Components: Build
>Reporter: Igor Galić
>Assignee: Igor Galić
> Fix For: 4.2.0
>
>
> {noformat}
> CXX WccpStatic.o
> WccpStatic.cc: In function ‘uint32_t wccp::Get_Local_Address(int)’:
> WccpStatic.cc:62:21: error: ‘SIOCGIFCONF’ was not declared in this scope
> WccpStatic.cc: In function ‘ts::Errata wccp::log_errno(ts::Errata::Code,
> const char*)’:
> WccpStatic.cc:150:78: error: ‘strerror_r’ was not declared in this scope
> WccpStatic.cc: In function ‘ts::Errata wccp::vlogf_errno(ts::Errata::Code,
> const char*, __va_list_tag (&)[1])’:
> WccpStatic.cc:165:35: error: ‘strerror_r’ was not declared in this scope
> WccpStatic.cc: In function ‘ts::Errata wccp::log_errno(ts::Errata::Code,
> const char*)’:
> WccpStatic.cc:151:1: error: control reaches end of non-void function
> [-Werror=return-type]
> cc1plus: all warnings being treated as errors
> gmake: *** [WccpStatic.o] Error 1
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (TS-1712) Double Free Issue with Basic Auth Type Plugin
[
https://issues.apache.org/jira/browse/TS-1712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13875952#comment-13875952
]
Leif Hedstrom commented on TS-1712:
---
[~xianthe] Is this still an issue ?
> Double Free Issue with Basic Auth Type Plugin
> -
>
> Key: TS-1712
> URL: https://issues.apache.org/jira/browse/TS-1712
> Project: Traffic Server
> Issue Type: Bug
> Components: Plugins
>Reporter: Valerie Thompson
> Labels: Crash
> Fix For: sometime
>
>
> I am creating a new plugin based off of basic-auth.c example from 3.0.5
> version of ATS. When I load the plugin and start running traffic through it I
> am getting memory issues and eventually crashes.
> I plan on having a username and password for my plugin, and as I add more
> features, the more unstable everything becomes. Today I stripped everything
> down to the bare minimum and ran it as and here is an example of memory
> issues, below. Let me know if you need further information.
> uname info for the type of box I'm running on:
> 2.6.32-279.5.1.el6.x86_64 #1 SMP Tue Aug 14 16:11:42 CDT 2012 x86_64 x86_64
> x86_64 GNU/Linux
> {quote}
> *** glibc detected *** /usr/bin/traffic_server: double free or corruption
> (!prev): 0x030c4ab0 ***
> === Backtrace: =
> /lib64/libc.so.6[0x3197275916]
> /lib64/libc.so.6[0x3197278443]
> /usr/lib64/trafficserver/plugins/ena-auth.so(+0x16a0)[0x2b051fc026a0]
> /usr/bin/traffic_server(_ZN6HttpSM17state_api_calloutEiPv+0x525)[0x52d3e5]
> /usr/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x1ea)[0x536e7a]
> /usr/bin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x9f)[0x5209df]
> /usr/bin/traffic_server(_ZN6HttpSM16do_hostdb_lookupEv+0x35a)[0x5222fa]
> /usr/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0xac3)[0x537753]
> /usr/bin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x9f)[0x5209df]
> /usr/bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x32a)[0x53828a]
> /usr/bin/traffic_server(_ZN6HttpSM17state_api_calloutEiPv+0x278)[0x52d138]
> /usr/bin/traffic_server(_ZN6HttpSM21state_cache_open_readEiPv+0x280)[0x52e760]
> /usr/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0xe8)[0x5309a8]
> /usr/bin/traffic_server(_ZN11HttpCacheSM21state_cache_open_readEiPv+0x202)[0x510d22]
> /usr/bin/traffic_server(_ZN5Cache9open_readEP12ContinuationP7INK_MD5P7HTTPHdrP21CacheLookupHttpConfig13CacheFragTypePci+0x4be)[0x65a41e]
> /usr/bin/traffic_server(_ZN14CacheProcessor9open_readEP12ContinuationP3URLP7HTTPHdrP21CacheLookupHttpConfigl13CacheFragType+0x170)[0x638910]
> /usr/bin/traffic_server(_ZN11HttpCacheSM9open_readEP3URLP7HTTPHdrP21CacheLookupHttpConfigl+0x84)[0x510674]
> /usr/bin/traffic_server(_ZN6HttpSM24do_cache_lookup_and_readEv+0x151)[0x521ab1]
> /usr/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x6f3)[0x537383]
> /usr/bin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x9f)[0x5209df]
> /usr/bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x32a)[0x53828a]
> /usr/bin/traffic_server(_ZN6HttpSM17state_api_calloutEiPv+0x278)[0x52d138]
> /usr/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x1ea)[0x536e7a]
> /usr/bin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x9f)[0x5209df]
> /usr/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x7fd)[0x53748d]
> /usr/bin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x9f)[0x5209df]
> /usr/bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x32a)[0x53828a]
> /usr/bin/traffic_server(_ZN6HttpSM17state_api_calloutEiPv+0x278)[0x52d138]
> /usr/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x1ea)[0x536e7a]
> /usr/bin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x9f)[0x5209df]
> /usr/bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x32a)[0x53828a]
> /usr/bin/traffic_server(_ZN6HttpSM17state_api_calloutEiPv+0x278)[0x52d138]
> /usr/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x1ea)[0x536e7a]
> /usr/bin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x9f)[0x5209df]
> /usr/bin/traffic_server(_ZN6HttpSM32state_read_client_request_headerEiPv+0x5ab)[0x52c06b]
> /usr/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0xe8)[0x5309a8]
> /usr/bin/traffic_server[0x68314b]
> /usr/bin/traffic_server[0x685c71]
> /usr/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x2e2)[0x67e782]
> /usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0xb4)[0x6aaff4]
> /usr/bin/traffic_server(_ZN7EThread7executeEv+0x4c3)[0x6ab983]
> /usr/bin/traffic_server(main+0x1128)[0x4c0878]
> /lib64/libc.so.6(__libc_start_main+0xfd)[0x319721ecdd]
> /usr/bin/traffic_server[0x47e14
[jira] [Commented] (TS-1691) remap config refine
[ https://issues.apache.org/jira/browse/TS-1691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13875950#comment-13875950 ] Leif Hedstrom commented on TS-1691: --- [~zym] In lieu of the Summit decision to move towards Lua based configs, what do we want to do with this bug? > remap config refine > --- > > Key: TS-1691 > URL: https://issues.apache.org/jira/browse/TS-1691 > Project: Traffic Server > Issue Type: Improvement > Components: Configuration, HTTP, Management >Reporter: Zhao Yongming > Fix For: sometime > > > here we track the remap config refine job, maybe a long story -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (TS-1669) evaluate SipHash as a replacement for MD5
[ https://issues.apache.org/jira/browse/TS-1669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13875949#comment-13875949 ] Bryan Call commented on TS-1669: I don't think that the performance of the hash is a limiting factor for ATS. I have never seen the hash function come up when profiling. I wouldn't worry about the hash algorithm unless there are security issues with MD5. > evaluate SipHash as a replacement for MD5 > - > > Key: TS-1669 > URL: https://issues.apache.org/jira/browse/TS-1669 > Project: Traffic Server > Issue Type: Improvement > Components: Core, Performance >Reporter: James Peach > Fix For: sometime > > Attachments: siphash.pdf > > > SipHash is claimed to have the stability of MD5 but the performance of a > non-crypto hash function. Let's take a look and see whether there's any > benefit to that. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TS-1689) Wccp doesn't compile on OmniOS/gcc-4.7
[
https://issues.apache.org/jira/browse/TS-1689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1689:
--
Assignee: Igor Galić
> Wccp doesn't compile on OmniOS/gcc-4.7
> --
>
> Key: TS-1689
> URL: https://issues.apache.org/jira/browse/TS-1689
> Project: Traffic Server
> Issue Type: Bug
> Components: Build
>Reporter: Igor Galić
>Assignee: Igor Galić
> Fix For: 4.2.0
>
>
> {noformat}
> CXX WccpStatic.o
> WccpStatic.cc: In function ‘uint32_t wccp::Get_Local_Address(int)’:
> WccpStatic.cc:62:21: error: ‘SIOCGIFCONF’ was not declared in this scope
> WccpStatic.cc: In function ‘ts::Errata wccp::log_errno(ts::Errata::Code,
> const char*)’:
> WccpStatic.cc:150:78: error: ‘strerror_r’ was not declared in this scope
> WccpStatic.cc: In function ‘ts::Errata wccp::vlogf_errno(ts::Errata::Code,
> const char*, __va_list_tag (&)[1])’:
> WccpStatic.cc:165:35: error: ‘strerror_r’ was not declared in this scope
> WccpStatic.cc: In function ‘ts::Errata wccp::log_errno(ts::Errata::Code,
> const char*)’:
> WccpStatic.cc:151:1: error: control reaches end of non-void function
> [-Werror=return-type]
> cc1plus: all warnings being treated as errors
> gmake: *** [WccpStatic.o] Error 1
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (TS-1687) Solaris has POSIX capabilities, but TPROXY doesn't know of these.
[
https://issues.apache.org/jira/browse/TS-1687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1687:
--
Fix Version/s: (was: sometime)
5.3.0
> Solaris has POSIX capabilities, but TPROXY doesn't know of these.
> --
>
> Key: TS-1687
> URL: https://issues.apache.org/jira/browse/TS-1687
> Project: Traffic Server
> Issue Type: Bug
> Components: Build, Portability
>Reporter: Igor Galić
> Fix For: 5.3.0
>
>
> When compiling ATS for Solaris, enabling the full feature set is impossible
> because currently the handling of POSIX capabilities (privileges under
> Solaris) is restricted to Linux:
> {noformat}
> checking whether to enable transparent proxy... configure: error: in
> `/home/i.galic/src/trafficserver':
> configure: error: TPROXY feature requires POSIX capabilities.
> {noformat}
> Here's the man page documenting
> [privileges(5)|http://illumos.org/man/5/privileges] - and here's a sample
> use, in the form of Apache httpd's
> [mod_pvivileges|https://svn.apache.org/repos/asf/httpd/httpd/trunk/modules/arch/unix/mod_privileges.c]
> Further man relevant man pages: [getpriv(2),
> setppriv(2)|http://illumos.org/man/2/setppriv] [getpflags(2),
> setpflags(2)|http://illumos.org/man/2/setpflags]
> As well as the "highlevel API" (convinience wrappers) such as
> [priv_set(3C)|http://illumos.org/man/3C/priv_set]
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (TS-1689) Wccp doesn't compile on OmniOS/gcc-4.7
[
https://issues.apache.org/jira/browse/TS-1689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1689:
--
Fix Version/s: (was: sometime)
4.2.0
> Wccp doesn't compile on OmniOS/gcc-4.7
> --
>
> Key: TS-1689
> URL: https://issues.apache.org/jira/browse/TS-1689
> Project: Traffic Server
> Issue Type: Bug
> Components: Build
>Reporter: Igor Galić
> Fix For: 4.2.0
>
>
> {noformat}
> CXX WccpStatic.o
> WccpStatic.cc: In function ‘uint32_t wccp::Get_Local_Address(int)’:
> WccpStatic.cc:62:21: error: ‘SIOCGIFCONF’ was not declared in this scope
> WccpStatic.cc: In function ‘ts::Errata wccp::log_errno(ts::Errata::Code,
> const char*)’:
> WccpStatic.cc:150:78: error: ‘strerror_r’ was not declared in this scope
> WccpStatic.cc: In function ‘ts::Errata wccp::vlogf_errno(ts::Errata::Code,
> const char*, __va_list_tag (&)[1])’:
> WccpStatic.cc:165:35: error: ‘strerror_r’ was not declared in this scope
> WccpStatic.cc: In function ‘ts::Errata wccp::log_errno(ts::Errata::Code,
> const char*)’:
> WccpStatic.cc:151:1: error: control reaches end of non-void function
> [-Werror=return-type]
> cc1plus: all warnings being treated as errors
> gmake: *** [WccpStatic.o] Error 1
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (TS-1661) Cluster Communications fails without retries ..
[ https://issues.apache.org/jira/browse/TS-1661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13875946#comment-13875946 ] Leif Hedstrom commented on TS-1661: --- Has this been addressed / fixed ? Any updates? Should we leave it open, and or target it for some version? > Cluster Communications fails without retries .. > --- > > Key: TS-1661 > URL: https://issues.apache.org/jira/browse/TS-1661 > Project: Traffic Server > Issue Type: Bug > Components: Clustering >Reporter: Dow Buzzell >Assignee: Bin Chen > Fix For: sometime > > Attachments: dropped-packet.png, dropped-packet.png, > refuse-reconnect.png > > > It has been observed that once a lost packet is seen in the TCP cache calls > to fetch a object from a member of the cache cluster, that the connection is > fin'ed and refused reconnect attempts with resets .. Is this the expected > behavior.. a private cache network with perfect delivery solves this problem, > however, seems like this might help if the member would accept reconnect > attempts. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TS-1629) add documentation of important log files
[ https://issues.apache.org/jira/browse/TS-1629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić updated TS-1629: --- Fix Version/s: (was: sometime) 4.2.0 > add documentation of important log files > > > Key: TS-1629 > URL: https://issues.apache.org/jira/browse/TS-1629 > Project: Traffic Server > Issue Type: Task > Components: Documentation >Reporter: Conan Wang > Fix For: Docs > > > After 3.3, if ATS fail to start, startup logs will be in diags.log instead of > traffic.out(stdout). We need documentation to describe those log files. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TS-1629) add documentation of important log files
[ https://issues.apache.org/jira/browse/TS-1629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić updated TS-1629: --- Fix Version/s: (was: 4.2.0) Docs > add documentation of important log files > > > Key: TS-1629 > URL: https://issues.apache.org/jira/browse/TS-1629 > Project: Traffic Server > Issue Type: Task > Components: Documentation >Reporter: Conan Wang > Fix For: Docs > > > After 3.3, if ATS fail to start, startup logs will be in diags.log instead of > traffic.out(stdout). We need documentation to describe those log files. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (TS-1620) Traffic Server 3.2.0 stable can't record ttms correctly
[ https://issues.apache.org/jira/browse/TS-1620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-1620. --- Resolution: Not A Problem Fix Version/s: (was: sometime) > Traffic Server 3.2.0 stable can't record ttms correctly > > > Key: TS-1620 > URL: https://issues.apache.org/jira/browse/TS-1620 > Project: Traffic Server > Issue Type: Bug > Components: Logging >Reporter: evilbandon > > Traffic Server 3.2.0 stable can't record ttms correctly > when I use Traffic Server 3.2.0 stable ,I find it can't record ttms correcly > ,most records of ttms is 0 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (TS-1610) if httpSessionManager.acquire_session can't acquire server_session, how to do is better?
[ https://issues.apache.org/jira/browse/TS-1610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13875945#comment-13875945 ] Bryan Call commented on TS-1610: Can you clarify the issue on this bug? Can you post a use case and how to reproduce it? > if httpSessionManager.acquire_session can't acquire server_session, how to do > is better? > > > Key: TS-1610 > URL: https://issues.apache.org/jira/browse/TS-1610 > Project: Traffic Server > Issue Type: Improvement > Components: Network >Reporter: Bin Chen >Assignee: Bin Chen > Fix For: sometime > > > if httpSessionManager.acquire_session can't acquire server_session, how to do > it better? > 1. retry by rescheduler? > 2. use spin lock in server_session if use global_session_pool? -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TS-1610) if httpSessionManager.acquire_session can't acquire server_session, how to do is better?
[ https://issues.apache.org/jira/browse/TS-1610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić updated TS-1610: --- Description: if httpSessionManager.acquire_session can't acquire server_session, how to do it better? 1. retry by rescheduler? 2. use spin lock in server_session if use global_session_pool? was: if httpSessionManager.acquire_session can't acquire server_session, how to do is better? 1. retry by rescheduler? 2. use spin lock in server_session if use global_session_pool? > if httpSessionManager.acquire_session can't acquire server_session, how to do > is better? > > > Key: TS-1610 > URL: https://issues.apache.org/jira/browse/TS-1610 > Project: Traffic Server > Issue Type: Improvement > Components: Network >Reporter: Bin Chen >Assignee: Bin Chen > Fix For: sometime > > > if httpSessionManager.acquire_session can't acquire server_session, how to do > it better? > 1. retry by rescheduler? > 2. use spin lock in server_session if use global_session_pool? -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Closed] (TS-1595) different domain have different origin_max_connections?
[ https://issues.apache.org/jira/browse/TS-1595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call closed TS-1595. -- Resolution: Fixed This is overridable with conf_remap or using the plugin APIs. > different domain have different origin_max_connections? > --- > > Key: TS-1595 > URL: https://issues.apache.org/jira/browse/TS-1595 > Project: Traffic Server > Issue Type: Sub-task > Components: Network >Reporter: Bin Chen >Assignee: Yu Qing >Priority: Minor > Fix For: sometime > > > In our env, we want different domain having different > "origin_max_connections" to manage connection more careful avoiding network > throttling. If not have different config in remap, use > "origin_max_connections" default. Other, config in remap will replace > "origin_max_connections". -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (TS-1605) crash at mime_parse_int64
[
https://issues.apache.org/jira/browse/TS-1605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13875944#comment-13875944
]
Leif Hedstrom commented on TS-1605:
---
Any update on this?
> crash at mime_parse_int64
> -
>
> Key: TS-1605
> URL: https://issues.apache.org/jira/browse/TS-1605
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP, MIME
>Reporter: Bin Chen
>Assignee: Bin Chen
> Labels: Crash
> Fix For: sometime
>
>
> {code}
> #0 0x00610f76 in mime_parse_int64 (buf=0x3fb bounds>,
> end=0x380f74 ) at MIME.cc:3076
> /usr/src/debug/trafficserver-3.2.0/proxy/hdrs/MIME.cc:3076:106103:beg:0x610f76
> Missing separate debuginfos, use: debuginfo-install
> expat-2.0.1-9.1.el6.x86_64 glibc-2.12-1.47.el6.x86_64
> keyutils-libs-1.4-3.el6.x86_64 krb5-libs-1.9-22.el6.x86_64
> libcom_err-1.41.12-11.el6.x86_64 libgcc-4.4.6-3.el6.x86_64
> libselinux-2.0.94-5.2.el6.x86_64 libstdc++-4.4.6-3.el6.x86_64
> ncurses-libs-5.7-3.20090208.el6.x86_64 openssl-1.0.0-20.el6.x86_64
> pcre-7.8-3.1.el6.x86_64 readline-6.0-3.el6.x86_64 tcl-8.5.7-6.el6.x86_64
> xz-libs-4.999.9-0.3.beta.20091007git.el6.x86_64 zlib-1.2.3-27.el6.x86_64
> (gdb) bt
> #0 0x00610f76 in mime_parse_int64 (buf=0x3fb bounds>,
> end=0x380f74 ) at MIME.cc:3076
> #1 0x0060d7a6 in mime_field_value_get_int64 (field=0x2af6853bfdd0)
> at MIME.cc:1694
> #2 0x0057d41c in MIMEHdr::value_get_int64 (this=0x2af6853bf5c8,
> name=0x2db7388 "Age", name_length=3)
> at ../../proxy/hdrs/MIME.h:1217
> #3 0x005a9230 in MIMEHdr::get_age (this=0x2af6853bf5c8) at
> ../../proxy/hdrs/MIME.h:1356
> #4 0x005aac0b in HttpTransactHeaders::calculate_document_age
> (request_time=1353920547, response_time=1353920547,
> base_response=0x2af6853bf5c8, base_response_date=1352509636,
> now=1354258269) at HttpTransactHeaders.cc:400
> #5 0x00581d73 in HttpTransactCache::SelectFromAlternates
> (cache_vector=0x2af5f0a057c0,
> client_request=0x2af5f0a05780, http_config_params=0x2af6005fda30) at
> HttpTransactCache.cc:221
> #6 0x00692c34 in CacheVC::openReadStartHead (this=0x2af5f0a056c0,
> event=3900, e=0x0) at CacheRead.cc:1019
> #7 0x004e6fae in Continuation::handleEvent (this=0x2af5f0a056c0,
> event=3900, data=0x0)
> at ../iocore/eventsystem/I_Continuation.h:146
> #8 0x006717e2 in CacheVC::handleReadDone (this=0x2af5f0a056c0,
> event=3900, e=0x2af5f0a05840) at Cache.cc:1952
> #9 0x004e6fae in Continuation::handleEvent (this=0x2af5f0a056c0,
> event=3900, data=0x2af5f0a05840)
> at ../iocore/eventsystem/I_Continuation.h:146
> #10 0x006761cc in AIOCallbackInternal::io_complete
> (this=0x2af5f0a05840, event=1, data=0x2af79c001420)
> at ../../iocore/aio/P_AIO.h:80
> #11 0x004e6fae in Continuation::handleEvent (this=0x2af5f0a05840,
> event=1, data=0x2af79c001420)
> at ../iocore/eventsystem/I_Continuation.h:146
> #12 0x006d99b8 in EThread::process_event (this=0x2af4f84e6010,
> e=0x2af79c001420, calling_code=1)
> at UnixEThread.cc:189
> #13 0x006d9b86 in EThread::execute (this=0x2af4f84e6010) at
> UnixEThread.cc:240
> #14 0x006d89e7 in spawn_thread_internal (a=0x2af4fc603b00) at
> Thread.cc:88
> #15 0x0034bfc077f1 in start_thread () from /lib64/libpthread.so.0
> #16 0x0034bf8e570d in clone () from /lib64/libc.so.6
> (gdb) f 0
> #0 0x00610f76 in mime_parse_int64 (buf=0x3fb bounds>,
> end=0x380f74 ) at MIME.cc:3076
> /usr/src/debug/trafficserver-3.2.0/proxy/hdrs/MIME.cc:3076:106103:beg:0x610f76
> (gdb) l
> 3071bool negative;
> 3072
> 3073if (!buf || (buf == end))
> 3074 return 0;
> 3075
> 3076if (is_digit(*buf)) // fast case
> 3077 {
> 3078num = *buf++ - '0';
> 3079while ((buf != end) && is_digit(*buf))
> 3080 num = (num * 10) + (*buf++ - '0');
> (gdb) p buf
> $1 = 0x3fb
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (TS-1603) crash at ClusterHandler::mainClusterEvent
[
https://issues.apache.org/jira/browse/TS-1603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13875941#comment-13875941
]
Leif Hedstrom commented on TS-1603:
---
Any Update on this?
> crash at ClusterHandler::mainClusterEvent
> -
>
> Key: TS-1603
> URL: https://issues.apache.org/jira/browse/TS-1603
> Project: Traffic Server
> Issue Type: Bug
> Components: Clustering
>Affects Versions: 3.2.0
>Reporter: Bin Chen
>Assignee: Bin Chen
> Labels: Crash
> Fix For: sometime
>
>
> {code}
> #0 0x006556c4 in ClusterHandler::mainClusterEvent
> (this=0x2ab444c1e4e0, event=2, e=0x0) at ClusterHandler.cc:2469
> /usr/src/debug/trafficserver-3.2.0/iocore/cluster/ClusterHandler.cc:2469:81142:beg:0x6556c4
> Missing separate debuginfos, use: debuginfo-install
> expat-2.0.1-9.1.el6.x86_64 glibc-2.12-1.47.el6.x86_64
> keyutils-libs-1.4-3.el6.x86_64 krb5-libs-1.9-22.el6.x86_64
> libcom_err-1.41.12-11.el6.x86_64 libgcc-4.4.6-3.el6.x86_64
> libselinux-2.0.94-5.2.el6.x86_64 libstdc++-4.4.6-3.el6.x86_64
> ncurses-libs-5.7-3.20090208.el6.x86_64 openssl-1.0.0-20.el6.x86_64
> pcre-7.8-3.1.el6.x86_64 readline-6.0-3.el6.x86_64 tcl-8.5.7-6.el6.x86_64
> xz-libs-4.999.9-0.3.beta.20091007git.el6.x86_64 zlib-1.2.3-27.el6.x86_64
> (gdb) bt
> #0 0x006556c4 in ClusterHandler::mainClusterEvent
> (this=0x2ab444c1e4e0, event=2, e=0x0) at ClusterHandler.cc:2469
> #1 0x0065d6a3 in ClusterHandler::protoZombieEvent
> (this=0x2ab444c1e4e0, event=1, e=0x0)
> at ClusterHandlerBase.cc:1219
> #2 0x004e6fae in Continuation::handleEvent (this=0x2ab444c1e4e0,
> event=1, data=0x0)
> at ../iocore/eventsystem/I_Continuation.h:146
> #3 0x0065b081 in ClusterState::IOComplete (this=0x2ab444c1e840) at
> ClusterHandlerBase.cc:584
> #4 0x0065ae1a in ClusterState::doIO_read_event (this=0x2ab444c1e840,
> event=104, d=0x2ab3613601d8)
> at ClusterHandlerBase.cc:496
> #5 0x004e6fae in Continuation::handleEvent (this=0x2ab444c1e840,
> event=104, data=0x2ab3613601d8)
> at ../iocore/eventsystem/I_Continuation.h:146
> #6 0x006b806c in read_signal_and_update (event=104,
> vc=0x2ab3613600d0) at UnixNetVConnection.cc:129
> #7 0x006b81bd in read_signal_done (event=104, nh=0x2ab35f1211e8,
> vc=0x2ab3613600d0) at UnixNetVConnection.cc:159
> #8 0x006b8707 in read_from_net (nh=0x2ab35f1211e8,
> vc=0x2ab3613600d0, thread=0x2ab35f11e010)
> at UnixNetVConnection.cc:282
> #9 0x006ba351 in UnixNetVConnection::net_read_io
> (this=0x2ab3613600d0, nh=0x2ab35f1211e8, lthread=0x2ab35f11e010)
> at UnixNetVConnection.cc:802
> #10 0x006b5064 in NetHandler::mainNetEvent (this=0x2ab35f1211e8,
> event=5, e=0x2ab33c536dd0) at UnixNet.cc:337
> #11 0x004e6fae in Continuation::handleEvent (this=0x2ab35f1211e8,
> event=5, data=0x2ab33c536dd0)
> at ../iocore/eventsystem/I_Continuation.h:146
> #12 0x006d99b8 in EThread::process_event (this=0x2ab35f11e010,
> e=0x2ab33c536dd0, calling_code=5)
> at UnixEThread.cc:189
> #13 0x006d9e55 in EThread::execute (this=0x2ab35f11e010) at
> UnixEThread.cc:301
> #14 0x006d89e7 in spawn_thread_internal (a=0x2ab344334f20) at
> Thread.cc:88
> #15 0x0037a14077f1 in start_thread () from /lib64/libpthread.so.0
> #16 0x0037a10e570d in clone () from /lib64/libc.so.6
> (gdb) f 0
> #0 0x006556c4 in ClusterHandler::mainClusterEvent
> (this=0x2ab444c1e4e0, event=2, e=0x0) at ClusterHandler.cc:2469
> /usr/src/debug/trafficserver-3.2.0/iocore/cluster/ClusterHandler.cc:2469:81142:beg:0x6556c4
> (gdb) l
> 2464 thread = (EThread *) e;
> 2465} else {
> 2466 if (io_callback) {
> 2467thread = this_ethread();
> 2468 } else {
> 2469thread = e->ethread;
> 2470 }
> 2471}
> 2472
> 2473int io_activity = 1;
> (gdb) p e
> $1 = (Event *) 0x0
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (TS-1602) crash at http_hdr_type_get
[
https://issues.apache.org/jira/browse/TS-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13875943#comment-13875943
]
Leif Hedstrom commented on TS-1602:
---
Any update on this?
> crash at http_hdr_type_get
> --
>
> Key: TS-1602
> URL: https://issues.apache.org/jira/browse/TS-1602
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP, MIME
>Affects Versions: 3.2.0
>Reporter: Bin Chen
>Assignee: weijin
> Labels: Crash
> Fix For: sometime
>
>
> {code}
> Program terminated with signal 11, Segmentation fault.
> #0 0x005034b0 in http_hdr_type_get (hh=0x2abf98de9898) at
> hdrs/HTTP.h:957
> /usr/src/debug/trafficserver-3.2.0/proxy/hdrs/HTTP.h:957:28250:beg:0x5034b0
> Missing separate debuginfos, use: debuginfo-install
> expat-2.0.1-9.1.el6.x86_64 glibc-2.12-1.47.el6.x86_64
> keyutils-libs-1.4-3.el6.x86_64 krb5-libs-1.9-22.el6.x86_64
> libcom_err-1.41.12-11.el6.x86_64 libgcc-4.4.6-3.el6.x86_64
> libselinux-2.0.94-5.2.el6.x86_64 libstdc++-4.4.6-3.el6.x86_64
> ncurses-libs-5.7-3.20090208.el6.x86_64 openssl-1.0.0-20.el6.x86_64
> pcre-7.8-3.1.el6.x86_64 readline-6.0-3.el6.x86_64 tcl-8.5.7-6.el6.x86_64
> xz-libs-4.999.9-0.3.beta.20091007git.el6.x86_64 zlib-1.2.3-27.el6.x86_64
> (gdb) bt
> #0 0x005034b0 in http_hdr_type_get (hh=0x2abf98de9898) at
> hdrs/HTTP.h:957
> #1 0x005034d2 in HTTPHdr::type_get (this=0x2ba4d149f088) at
> hdrs/HTTP.h:967
> #2 0x0058e6f4 in HttpTransact::HandleCacheOpenRead
> (s=0x2ba51d5d2838) at HttpTransact.cc:2046
> #3 0x0057af93 in HttpSM::call_transact_and_set_next_state
> (this=0x2ba51d5d27d0,
> f=0x58e5cc ) at
> HttpSM.cc:6425
> #4 0x0056e576 in HttpSM::state_cache_open_read (this=0x2ba51d5d27d0,
> event=1102, data=0x2ba3f8d00c10)
> at HttpSM.cc:2406
> #5 0x0056e968 in HttpSM::main_handler (this=0x2ba51d5d27d0,
> event=1102, data=0x2ba3f8d00c10) at HttpSM.cc:2465
> #6 0x004e6fae in Continuation::handleEvent (this=0x2ba51d5d27d0,
> event=1102, data=0x2ba3f8d00c10)
> at ../iocore/eventsystem/I_Continuation.h:146
> #7 0x00556f02 in HttpCacheSM::state_cache_open_read
> (this=0x2ba51d5d4898, event=1102, data=0x2ba3f8d00c10)
> at HttpCacheSM.cc:118
> #8 0x004e6fae in Continuation::handleEvent (this=0x2ba51d5d4898,
> event=1102, data=0x2ba3f8d00c10)
> at ../iocore/eventsystem/I_Continuation.h:146
> #9 0x00649779 in CacheContinuation::callback_user
> (this=0x2ba410a95560, res=1102, e=0x2ba3f8d00c10)
> at ClusterCache.cc:2813
> #10 0x00648433 in CacheContinuation::remoteOpEvent
> (this=0x2ba410a95560, event_code=1151, e=0x2ba4d149f000)
> at ClusterCache.cc:2345
> #11 0x004e6fae in Continuation::handleEvent (this=0x2ba410a95560,
> event=1151, data=0x2ba4d149f000)
> at ../iocore/eventsystem/I_Continuation.h:146
> #12 0x0064751c in cache_op_result_ClusterFunction (ch=0x2ba428881140,
> d=0x2ba570cd4018, l=2776)
> at ClusterCache.cc:2088
> #13 0x00651747 in ClusterHandler::process_incoming_callouts
> (this=0x2ba428881140, m=0x2ba3f92a3c50)
> at ClusterHandler.cc:1237
> #14 0x006598db in ClusterCalloutContinuation::CalloutHandler
> (this=0x2ba4284057c0, event=2, e=0x2ba314b48ef0)
> at ClusterHandlerBase.cc:62
> #15 0x004e6fae in Continuation::handleEvent (this=0x2ba4284057c0,
> event=2, data=0x2ba314b48ef0)
> at ../iocore/eventsystem/I_Continuation.h:146
> #16 0x006d99b8 in EThread::process_event (this=0x2ba2cf72e010,
> e=0x2ba314b48ef0, calling_code=2)
> at UnixEThread.cc:189
> #17 0x006dbd79 in PriorityEventQueue::check_ready
> (this=0x2ba2cf82ec40, now=135396960399086, t=0x2ba2cf72e010)
> at PQ-List.cc:141
> #18 0x006d9c8a in EThread::execute (this=0x2ba2cf72e010) at
> UnixEThread.cc:258
> #19 0x006d89e7 in spawn_thread_internal (a=0x15c19a0) at Thread.cc:88
> #20 0x003c088077f1 in start_thread () from /lib64/libpthread.so.0
> #21 0x003c084e570d in clone () from /lib64/libc.so.6
> (gdb) f 0
> #0 0x005034b0 in http_hdr_type_get (hh=0x2abf98de9898) at
> hdrs/HTTP.h:957
> /usr/src/debug/trafficserver-3.2.0/proxy/hdrs/HTTP.h:957:28250:beg:0x5034b0
> (gdb) l
> 952
> -*/
> 953
> 954 inline HTTPType
> 955 http_hdr_type_get(HTTPHdrImpl *hh)
> 956 {
> 957 return (hh->m_polarity);
> 958 }
> 959
> 960
> /*-
> 961
> -*/
> (gdb) p hh->m_polarity
> Cannot access memory at address 0x2abf98de989c
> (gdb) p *hh
> Cannot access memory at address 0x2abf98de9898
>
[jira] [Commented] (TS-1592) crash at HttpCompat::parse_tok_list
[
https://issues.apache.org/jira/browse/TS-1592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13875938#comment-13875938
]
Leif Hedstrom commented on TS-1592:
---
No answer, should we close this as can't reproduce ?
> crash at HttpCompat::parse_tok_list
> ---
>
> Key: TS-1592
> URL: https://issues.apache.org/jira/browse/TS-1592
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
>Affects Versions: 3.2.0
> Environment: full_cluster
>Reporter: Bin Chen
>Assignee: weijin
> Labels: Crash
> Fix For: sometime
>
>
> {code}
> Program terminated with signal 11, Segmentation fault.
> #0 HttpCompat::parse_tok_list (list=0x2b3d7aca86f0, trim_quotes= optimized out>, string=,
> len=, sep=59 ';') at HttpCompat.cc:77
> /usr/src/debug/trafficserver-3.2.0/proxy/hdrs/HttpCompat.cc:77:2565:beg:0x5a7990
> Missing separate debuginfos, use: debuginfo-install
> expat-2.0.1-9.1.el6.x86_64 glibc-2.12-1.47.el6.x86_64
> keyutils-libs-1.4-3.el6.x86_64 krb5-libs-1.9-22.el6.x86_64
> libcom_err-1.41.12-11.el6.x86_64 libgcc-4.4.6-3.el6.x86_64
> libselinux-2.0.94-5.2.el6.x86_64 libstdc++-4.4.6-3.el6.x86_64
> ncurses-libs-5.7-3.20090208.el6.x86_64 openssl-1.0.0-20.el6.x86_64
> pcre-7.8-3.1.el6.x86_64 readline-6.0-3.el6.x86_64 tcl-8.5.7-6.el6.x86_64
> xz-libs-4.999.9-0.3.beta.20091007git.el6.x86_64 zlib-1.2.3-27.el6.x86_64
> (gdb) bt
> #0 HttpCompat::parse_tok_list (list=0x2b3d7aca86f0, trim_quotes= optimized out>, string=,
> len=, sep=59 ';') at HttpCompat.cc:77
> #1 0x0052e4fc in parse_semicolon_list (accept_field=0x2b3da50ab118,
> content_field=)
> at ../../proxy/hdrs/HttpCompat.h:92
> #2 HttpTransactCache::calculate_quality_of_accept_match
> (accept_field=0x2b3da50ab118, content_field=)
> at HttpTransactCache.cc:519
> #3 0x00530cf6 in HttpTransactCache::calculate_quality_of_match
> (http_config_param=0x2b3da6a074a0,
> client_request=0x2b3d94749ba0, obj_client_request=0x2b3f4748d5c0,
> obj_origin_server_response=0x2b3f4748d600)
> at HttpTransactCache.cc:327
> #4 0x00531a7d in HttpTransactCache::SelectFromAlternates
> (cache_vector=0x2b3d94749be0,
> client_request=0x2b3d94749ba0, http_config_params=0x2b3da6a074a0) at
> HttpTransactCache.cc:214
> #5 0x006245e5 in CacheVC::openReadStartHead (this=0x2b3d94749ae0,
> event=3900, e=0x0) at CacheRead.cc:1019
> #6 0x00604348 in handleEvent (this=0x2b3d94749ae0, event= optimized out>, e=)
> at ../../iocore/eventsystem/I_Continuation.h:146
> #7 CacheVC::handleReadDone (this=0x2b3d94749ae0, event= out>, e=) at Cache.cc:1952
> #8 0x00608035 in handleEvent (this=,
> event=, data=)
> at ../../iocore/eventsystem/I_Continuation.h:146
> #9 AIOCallbackInternal::io_complete (this=,
> event=, data=)
> at ../../iocore/aio/P_AIO.h:80
> #10 0x0066ae94 in handleEvent (this=0x2b3d7a42b010, e=0x213ec10,
> calling_code=1) at I_Continuation.h:146
> #11 EThread::process_event (this=0x2b3d7a42b010, e=0x213ec10, calling_code=1)
> at UnixEThread.cc:189
> #12 0x0066b773 in EThread::execute (this=0x2b3d7a42b010) at
> UnixEThread.cc:240
> #13 0x00669c72 in spawn_thread_internal (a=0x1785910) at Thread.cc:88
> #14 0x0034bfc077f1 in start_thread () from /lib64/libpthread.so.0
> #15 0x0034bf8e570d in clone () from /lib64/libc.so.6
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (TS-1570) remap doesn't reject request whose Host has extra characters after port (like "test.com:80xxx")
[ https://issues.apache.org/jira/browse/TS-1570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1570: -- Fix Version/s: (was: sometime) 4.2.0 > remap doesn't reject request whose Host has extra characters after port (like > "test.com:80xxx") > --- > > Key: TS-1570 > URL: https://issues.apache.org/jira/browse/TS-1570 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Affects Versions: 3.3.0 >Reporter: Conan Wang >Priority: Minor > Fix For: 4.2.0 > > > remap.config:map http://test.com http://1.1.1.1 > The request with Host: 'test.com:80xxx' or 'test.com:xxx' will get passed. > Such host is not filtered strictly. > Just report, didn't have big problem for me though. > curl http://127.0.0.1:8080/ -H "Host: test.com:80xxx" > or curl -x 127.0.0.1:8080 http://test.com:80xxx/ -v -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TS-1570) remap doesn't reject request whose Host has extra characters after port (like "test.com:80xxx")
[ https://issues.apache.org/jira/browse/TS-1570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1570: -- Assignee: Igor Galić > remap doesn't reject request whose Host has extra characters after port (like > "test.com:80xxx") > --- > > Key: TS-1570 > URL: https://issues.apache.org/jira/browse/TS-1570 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Affects Versions: 3.3.0 >Reporter: Conan Wang >Assignee: Igor Galić >Priority: Minor > Fix For: 4.2.0 > > > remap.config:map http://test.com http://1.1.1.1 > The request with Host: 'test.com:80xxx' or 'test.com:xxx' will get passed. > Such host is not filtered strictly. > Just report, didn't have big problem for me though. > curl http://127.0.0.1:8080/ -H "Host: test.com:80xxx" > or curl -x 127.0.0.1:8080 http://test.com:80xxx/ -v -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TS-1447) Add User Space DTrace (USDT) probe capability
[ https://issues.apache.org/jira/browse/TS-1447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić updated TS-1447: --- Summary: Add User Space DTrace (USDT) probe capability (was: Add USDT probe capability) > Add User Space DTrace (USDT) probe capability > - > > Key: TS-1447 > URL: https://issues.apache.org/jira/browse/TS-1447 > Project: Traffic Server > Issue Type: Bug > Components: Core >Reporter: Phil Sorber > Fix For: 5.3.0 > > > http://www.solarisinternals.com/wiki/index.php/DTrace_Topics_USDT#USDT -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TS-1447) Add Userlevel Statically Defined Tracing (USDT) probe capability
[ https://issues.apache.org/jira/browse/TS-1447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić updated TS-1447: --- Summary: Add Userlevel Statically Defined Tracing (USDT) probe capability (was: Add User Space DTrace (USDT) probe capability) > Add Userlevel Statically Defined Tracing (USDT) probe capability > > > Key: TS-1447 > URL: https://issues.apache.org/jira/browse/TS-1447 > Project: Traffic Server > Issue Type: Bug > Components: Core >Reporter: Phil Sorber > Fix For: 5.3.0 > > > http://www.solarisinternals.com/wiki/index.php/DTrace_Topics_USDT#USDT -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TS-1964) Make Accept threads NUMA aware
[ https://issues.apache.org/jira/browse/TS-1964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić updated TS-1964: --- Assignee: Bryan Call > Make Accept threads NUMA aware > -- > > Key: TS-1964 > URL: https://issues.apache.org/jira/browse/TS-1964 > Project: Traffic Server > Issue Type: Bug > Components: Core >Reporter: Leif Hedstrom >Assignee: Bryan Call > Labels: NUMA > Fix For: 6.0.0 > > > To work efficiently, we should have one (or several) accept threads per NUMA > node. In addition, it should schedule the VCs on ET_NET threads that are > assigned to the same NUMA node. This assures that memory allocated for the VC > stays on the same NUMA node. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (TS-1447) Add USDT probe capability
[ https://issues.apache.org/jira/browse/TS-1447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13875936#comment-13875936 ] Leif Hedstrom commented on TS-1447: --- I'm putting this as 5.3.0, I think it'd be great to have this Phil! > Add USDT probe capability > - > > Key: TS-1447 > URL: https://issues.apache.org/jira/browse/TS-1447 > Project: Traffic Server > Issue Type: Bug > Components: Core >Reporter: Phil Sorber > Fix For: 5.3.0 > > > http://www.solarisinternals.com/wiki/index.php/DTrace_Topics_USDT#USDT -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TS-1447) Add USDT probe capability
[ https://issues.apache.org/jira/browse/TS-1447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1447: -- Fix Version/s: (was: sometime) 5.3.0 > Add USDT probe capability > - > > Key: TS-1447 > URL: https://issues.apache.org/jira/browse/TS-1447 > Project: Traffic Server > Issue Type: Bug > Components: Core >Reporter: Phil Sorber > Fix For: 5.3.0 > > > http://www.solarisinternals.com/wiki/index.php/DTrace_Topics_USDT#USDT -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (TS-1434) limited max bandwidth
[ https://issues.apache.org/jira/browse/TS-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-1434. --- Resolution: Cannot Reproduce Fix Version/s: (was: sometime) I'm not able to reproduce this, tested a single box, single connection, over normal (2 10GigE NIC's) network, at around 15Gbps. > limited max bandwidth > - > > Key: TS-1434 > URL: https://issues.apache.org/jira/browse/TS-1434 > Project: Traffic Server > Issue Type: Bug >Affects Versions: 3.2.0, 3.0.5 >Reporter: samahee > > I'm using 3.2.0. bonding 2G > cached large file(2GB) and then downloaded full speed on some servers. > but bandwidth limited 800M bit/sec > please check it. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (TS-2511) Document the 90% of Transparent Proxy use-cases
Igor Galić created TS-2511: -- Summary: Document the 90% of Transparent Proxy use-cases Key: TS-2511 URL: https://issues.apache.org/jira/browse/TS-2511 Project: Traffic Server Issue Type: Bug Components: Documentation Reporter: Igor Galić 90% of transparent proxy users need to one IPTables rule on their router and they're done. Please document that. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TS-2511) Document the 90% of Transparent Proxy use-cases
[ https://issues.apache.org/jira/browse/TS-2511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić updated TS-2511: --- Assignee: Leif Hedstrom > Document the 90% of Transparent Proxy use-cases > --- > > Key: TS-2511 > URL: https://issues.apache.org/jira/browse/TS-2511 > Project: Traffic Server > Issue Type: Bug > Components: Documentation >Reporter: Igor Galić >Assignee: Leif Hedstrom > > 90% of transparent proxy users need to one IPTables rule on their router and > they're done. > Please document that. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TS-1429) Log collation of custom xml logs failing
[
https://issues.apache.org/jira/browse/TS-1429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1429:
--
Fix Version/s: (was: sometime)
5.1.0
> Log collation of custom xml logs failing
>
>
> Key: TS-1429
> URL: https://issues.apache.org/jira/browse/TS-1429
> Project: Traffic Server
> Issue Type: Bug
> Components: Logging
>Affects Versions: 3.2.0
> Environment: Linux
>Reporter: Dan Morgan
> Fix For: 5.1.0
>
>
> When configuring logs_xml.config to send to a collation host with the
> entry, we start to get these errors in traffic.out:
> NOTE: [log-coll] send-queue full; orphaning logs [192.168.57.248:8085]
> NOTE: [log-coll] send-queue clear; resuming collation [192.168.57.248:8085]
> thousands of them.
> It looks like there used to be a config value called:
> collation_max_send_buffers that has been removed, but there's still code in
> LogCollationClientSM.cc that references that value (which appears to now be
> zero). Line 185 looks like:
> if (m_buffer_send_list->get_size() >=
> Log::config->collation_max_send_buffers) {
> Debug("log-coll", "[%d]client::send - m_flow = DENY", m_id);
> Note("[log-coll] send-queue full; orphaning logs "
> "[%s:%u]", m_log_host->ip_addr().toString(ipb, sizeof(ipb)),
> m_log_host->port());
> m_flow = LOG_COLL_FLOW_DENY;
> }
> but since collation_max_send_buffers is zero, it always goes into that if
> block.
> Just as a note as well, issue TS-1299
> (https://issues.apache.org/jira/browse/TS-1299) which has a patch for 3.1.4,
> never made it into 3.2 (looks like it was done on the same day as 3.2 was
> released).
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (TS-1429) Log collation of custom xml logs failing
[
https://issues.apache.org/jira/browse/TS-1429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13875933#comment-13875933
]
Leif Hedstrom commented on TS-1429:
---
[~bknight] There has been quite a lot of changes to logging and log collation
lately. Is this still an issue?
> Log collation of custom xml logs failing
>
>
> Key: TS-1429
> URL: https://issues.apache.org/jira/browse/TS-1429
> Project: Traffic Server
> Issue Type: Bug
> Components: Logging
>Affects Versions: 3.2.0
> Environment: Linux
>Reporter: Dan Morgan
> Fix For: 5.1.0
>
>
> When configuring logs_xml.config to send to a collation host with the
> entry, we start to get these errors in traffic.out:
> NOTE: [log-coll] send-queue full; orphaning logs [192.168.57.248:8085]
> NOTE: [log-coll] send-queue clear; resuming collation [192.168.57.248:8085]
> thousands of them.
> It looks like there used to be a config value called:
> collation_max_send_buffers that has been removed, but there's still code in
> LogCollationClientSM.cc that references that value (which appears to now be
> zero). Line 185 looks like:
> if (m_buffer_send_list->get_size() >=
> Log::config->collation_max_send_buffers) {
> Debug("log-coll", "[%d]client::send - m_flow = DENY", m_id);
> Note("[log-coll] send-queue full; orphaning logs "
> "[%s:%u]", m_log_host->ip_addr().toString(ipb, sizeof(ipb)),
> m_log_host->port());
> m_flow = LOG_COLL_FLOW_DENY;
> }
> but since collation_max_send_buffers is zero, it always goes into that if
> block.
> Just as a note as well, issue TS-1299
> (https://issues.apache.org/jira/browse/TS-1299) which has a patch for 3.1.4,
> never made it into 3.2 (looks like it was done on the same day as 3.2 was
> released).
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (TS-1336) High CPU Usage at idle
[
https://issues.apache.org/jira/browse/TS-1336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13875932#comment-13875932
]
Igor Galić commented on TS-1336:
We have a workaround in TS-2474 - but that's still not entirely fixed.
> High CPU Usage at idle
> --
>
> Key: TS-1336
> URL: https://issues.apache.org/jira/browse/TS-1336
> Project: Traffic Server
> Issue Type: Bug
> Components: Performance
>Affects Versions: 3.0.5, 3.0.2
> Environment: Ubuntu 12.04 server, amd64, Xenon E5520 (4-core, 16
> cores with HT)
>Reporter: Greg Smolyn
> Labels: A
> Fix For: sometime
>
>
> On this unloaded system, a very basic traffic server instance is using 180%
> CPU, with 3 threads ET_TASK 0, ET_TASK 1, and LOGGING taking up about 60%
> each.
> top -H output:
> PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
>
>
> 10723 traffics 20 0 1960m 113m 4168 R 61 0.4 9:11.27 [ET_TASK 1]
>
>
> 10722 traffics 20 0 1960m 113m 4168 R 60 0.4 8:41.61 [ET_TASK 0]
>
>
> 10720 traffics 20 0 1960m 113m 4168 S 59 0.4 8:49.19 [LOGGING]
>
>
>19 root 20 0 000 R 15 0.0 898:45.74 ksoftirqd/3
>
>
>10 root 20 0 000 S 15 0.0 930:16.92 ksoftirqd/1
>
>
>27 root 20 0 000 S 14 0.0 893:18.41 ksoftirqd/5
>
>
>35 root 20 0 000 S 14 0.0 888:54.41 ksoftirqd/7
>
>
> 3 root 20 0 000 S8 0.0 942:48.39 ksoftirqd/0
>
>
>15 root 20 0 000 S7 0.0 906:40.98 ksoftirqd/2
>
>
>23 root 20 0 000 S7 0.0 907:30.33 ksoftirqd/4
>
>
>31 root 20 0 000 S7 0.0 898:13.05 ksoftirqd/6
>
>
> 13530 root 20 0 98.2m 3244 2572 S1 0.0 29:28.86 flip_server
>
>
> 9425 root 20 0 17568 1592 1060 R0 0.0 0:04.16 top
>
>
> 10689 traffics 20 0 1960m 113m 4168 S0 0.4 0:00.54 [ET_NET 5]
>
>
> 10693 traffics 20 0 1960m 113m 4168 S0 0.4 0:00.51 [ET_NET 9]
>
>
> 10701 traffics 20 0 1960m 113m 4168 S0 0.4 0:00.56 [ET_NET 17]
>
>
> 10702 traffics 20 0 1960m 113m 4168 S0 0.4 0:00.53 [ET_NET 18]
>
>
> 10705 traffics 20 0 1960m 113m 4168 S0 0.4 0:00.54 [ET_NET 21]
>
>
> 1 root 20 0 24328 2256 1344 S0 0.0 0:02.53 init
>
>
> 2 root 20 0 000 S0 0.0 0:00.05 kthreadd
> stracing the ET_TASK threads showed a repeating set of calls to futex:
> futex(0x946ca4, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 255405471,
> {1341604150, 0}, ) = -1 ETIMEDO
[jira] [Commented] (TS-1403) f_inbound_transparency is not handled by all accept cases
[ https://issues.apache.org/jira/browse/TS-1403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13875931#comment-13875931 ] Leif Hedstrom commented on TS-1403: --- [~ushachar] What's the status on this one? Something to do? > f_inbound_transparency is not handled by all accept cases > - > > Key: TS-1403 > URL: https://issues.apache.org/jira/browse/TS-1403 > Project: Traffic Server > Issue Type: Bug > Components: Network >Affects Versions: 3.2.0 >Reporter: Yossi Gottlieb >Assignee: Uri Shachar >Priority: Minor > Fix For: sometime > > Attachments: transparency.diff > > > The inbound transparency flag does not always take affect, depending on the > accept configuration. This is not currently an issue because TSAPI doesn't > provide a standard transparent accept API, but it will become an issue once > the interface is created. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Comment Edited] (TS-1403) f_inbound_transparency is not handled by all accept cases
[ https://issues.apache.org/jira/browse/TS-1403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13875931#comment-13875931 ] Leif Hedstrom edited comment on TS-1403 at 1/19/14 5:21 PM: [~ushachar] What's the status on this one? Something to do? Please target the fix version and/or close etc. as appropriate. was (Author: zwoop): [~ushachar] What's the status on this one? Something to do? > f_inbound_transparency is not handled by all accept cases > - > > Key: TS-1403 > URL: https://issues.apache.org/jira/browse/TS-1403 > Project: Traffic Server > Issue Type: Bug > Components: Network >Affects Versions: 3.2.0 >Reporter: Yossi Gottlieb >Assignee: Uri Shachar >Priority: Minor > Fix For: sometime > > Attachments: transparency.diff > > > The inbound transparency flag does not always take affect, depending on the > accept configuration. This is not currently an issue because TSAPI doesn't > provide a standard transparent accept API, but it will become an issue once > the interface is created. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TS-1326) way to control the ram space usage
[ https://issues.apache.org/jira/browse/TS-1326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić updated TS-1326: --- Fix Version/s: (was: 6.0.0) 5.3.0 > way to control the ram space usage > -- > > Key: TS-1326 > URL: https://issues.apache.org/jira/browse/TS-1326 > Project: Traffic Server > Issue Type: Improvement > Components: Cache >Reporter: Zhao Yongming >Priority: Minor > Fix For: 5.3.0 > > > we have the ram cache binding to volume and the space is used for all > contents in the volume, with LRU. > in some situation, you'd need to give one site for more or less ram cache > because you know they demand it. > we should take the ram space as a control resource, and control it -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (TS-1326) way to control the ram space usage
[ https://issues.apache.org/jira/browse/TS-1326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13875929#comment-13875929 ] Leif Hedstrom commented on TS-1326: --- I've had a use case where a large box, 8 disks and 64GB of RAM cache, which yielded 8GB of RAM per stripe (disk). However, this prevented a very large object (12GB) from being cached in RAM, and therefore, killed the single disk which held this popular, large object. Our solution was to RAID stripe the 8 disks on the box, presenting one big disk to ATS, such that the cache gets the full 64GB. I can see a number of options here, but one would be to coalesce the RAM cache into one single entity (and not divided). Another would be to be able to control the RAM size per volume / stripe. > way to control the ram space usage > -- > > Key: TS-1326 > URL: https://issues.apache.org/jira/browse/TS-1326 > Project: Traffic Server > Issue Type: Improvement > Components: Cache >Reporter: Zhao Yongming >Priority: Minor > Fix For: 5.3.0 > > > we have the ram cache binding to volume and the space is used for all > contents in the volume, with LRU. > in some situation, you'd need to give one site for more or less ram cache > because you know they demand it. > we should take the ram space as a control resource, and control it -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TS-1326) way to control the ram space usage
[ https://issues.apache.org/jira/browse/TS-1326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić updated TS-1326: --- Fix Version/s: (was: sometime) 6.0.0 > way to control the ram space usage > -- > > Key: TS-1326 > URL: https://issues.apache.org/jira/browse/TS-1326 > Project: Traffic Server > Issue Type: Improvement > Components: Cache >Reporter: Zhao Yongming >Priority: Minor > Fix For: 5.3.0 > > > we have the ram cache binding to volume and the space is used for all > contents in the volume, with LRU. > in some situation, you'd need to give one site for more or less ram cache > because you know they demand it. > we should take the ram space as a control resource, and control it -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TS-1326) way to control the ram spaces usage
[ https://issues.apache.org/jira/browse/TS-1326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić updated TS-1326: --- Description: we have the ram cache binding to volume and the space is used for all contents in the volume, with LRU. in some situation, you'd need to give one site for more or less ram cache because you know they demand it. we should take the ram space as a control resource, and control it was: we have the ram cache binding to volume and the space is used for all contents in the volume, with lru. in some situation, you'd need to give one site for more or less ram cache because you know they demand it. we should take the ram space as a control resource, and control it > way to control the ram spaces usage > --- > > Key: TS-1326 > URL: https://issues.apache.org/jira/browse/TS-1326 > Project: Traffic Server > Issue Type: Improvement > Components: Cache >Reporter: Zhao Yongming >Priority: Minor > Fix For: sometime > > > we have the ram cache binding to volume and the space is used for all > contents in the volume, with LRU. > in some situation, you'd need to give one site for more or less ram cache > because you know they demand it. > we should take the ram space as a control resource, and control it -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TS-1326) way to control the ram space usage
[ https://issues.apache.org/jira/browse/TS-1326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić updated TS-1326: --- Summary: way to control the ram space usage (was: way to control the ram spaces usage) > way to control the ram space usage > -- > > Key: TS-1326 > URL: https://issues.apache.org/jira/browse/TS-1326 > Project: Traffic Server > Issue Type: Improvement > Components: Cache >Reporter: Zhao Yongming >Priority: Minor > Fix For: sometime > > > we have the ram cache binding to volume and the space is used for all > contents in the volume, with LRU. > in some situation, you'd need to give one site for more or less ram cache > because you know they demand it. > we should take the ram space as a control resource, and control it -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TS-1268) Control cache clustering via API and records.config for e.g. object sizes
[ https://issues.apache.org/jira/browse/TS-1268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1268: -- Fix Version/s: (was: sometime) > Control cache clustering via API and records.config for e.g. object sizes > - > > Key: TS-1268 > URL: https://issues.apache.org/jira/browse/TS-1268 > Project: Traffic Server > Issue Type: New Feature > Components: Clustering >Reporter: Leif Hedstrom > > For optimal site performance, it would make sense to let the admin / > programmer control which objects should be cached on only as single node vs > all (or a few nodes). For example: > 1) Always cache all objects smaller than 32KB on all cache nodes. > 2) Cache all objects of content type text/html on all nodes. > Ideally, we'd have both TSAPI's as well as records.config or cluster configs > for the common cases. This gives the user of a cluster finer control of > performance tradeoffs between storage vs latency / network congestion. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Closed] (TS-1193) Traffic Server building on OpenBSD
[ https://issues.apache.org/jira/browse/TS-1193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić closed TS-1193. -- Resolution: Duplicate Fix Version/s: (was: sometime) I don't think we need two of these. > Traffic Server building on OpenBSD > -- > > Key: TS-1193 > URL: https://issues.apache.org/jira/browse/TS-1193 > Project: Traffic Server > Issue Type: Improvement >Affects Versions: 3.1.3 >Reporter: Brian Geffon >Assignee: Brian Geffon > > This is a parent issue for the task of getting traffic server building on > OpenBSD. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (TS-1268) Control cache clustering via API and records.config for e.g. object sizes
[ https://issues.apache.org/jira/browse/TS-1268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-1268. --- Resolution: Won't Fix Closing as won't fix, I have no interest in this, and I don't think anyone else does ? > Control cache clustering via API and records.config for e.g. object sizes > - > > Key: TS-1268 > URL: https://issues.apache.org/jira/browse/TS-1268 > Project: Traffic Server > Issue Type: New Feature > Components: Clustering >Reporter: Leif Hedstrom > Fix For: sometime > > > For optimal site performance, it would make sense to let the admin / > programmer control which objects should be cached on only as single node vs > all (or a few nodes). For example: > 1) Always cache all objects smaller than 32KB on all cache nodes. > 2) Cache all objects of content type text/html on all nodes. > Ideally, we'd have both TSAPI's as well as records.config or cluster configs > for the common cases. This gives the user of a cluster finer control of > performance tradeoffs between storage vs latency / network congestion. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (TS-1187) TSMimeHdrFieldNameSet does not work for headers read from the client or origin server (but does work for headers added by traffic server)
[ https://issues.apache.org/jira/browse/TS-1187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13875924#comment-13875924 ] Bryan Call commented on TS-1187: I will write a unit test for it and see what happens... > TSMimeHdrFieldNameSet does not work for headers read from the client or > origin server (but does work for headers added by traffic server) > - > > Key: TS-1187 > URL: https://issues.apache.org/jira/browse/TS-1187 > Project: Traffic Server > Issue Type: Bug > Components: MIME >Affects Versions: 3.0.2 > Environment: Redhat linux with plugin that wants to rename a header > read from the client. >Reporter: Alistair Stevenson >Assignee: Bryan Call > Labels: api-change > Fix For: 4.2.0 > > > TSMimeHdrFieldNameSet does not work for headers read from the client or > origin server (but does work for headers added by traffic server) > The name appears set (and the function returns SUCCESS) but when the data is > sent to the origin Server it is corrupted at the point where the header is > set. i.e the header name is sent but the header is corrupted after this. > I am having to create a new header and copy the values and then destroy the > original header which is not as efficient. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TS-1187) TSMimeHdrFieldNameSet does not work for headers read from the client or origin server (but does work for headers added by traffic server)
[ https://issues.apache.org/jira/browse/TS-1187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1187: -- Assignee: Bryan Call > TSMimeHdrFieldNameSet does not work for headers read from the client or > origin server (but does work for headers added by traffic server) > - > > Key: TS-1187 > URL: https://issues.apache.org/jira/browse/TS-1187 > Project: Traffic Server > Issue Type: Bug > Components: MIME >Affects Versions: 3.0.2 > Environment: Redhat linux with plugin that wants to rename a header > read from the client. >Reporter: Alistair Stevenson >Assignee: Bryan Call > Labels: api-change > Fix For: 4.2.0 > > > TSMimeHdrFieldNameSet does not work for headers read from the client or > origin server (but does work for headers added by traffic server) > The name appears set (and the function returns SUCCESS) but when the data is > sent to the origin Server it is corrupted at the point where the header is > set. i.e the header name is sent but the header is corrupted after this. > I am having to create a new header and copy the values and then destroy the > original header which is not as efficient. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TS-1187) TSMimeHdrFieldNameSet does not work for headers read from the client or origin server (but does work for headers added by traffic server)
[ https://issues.apache.org/jira/browse/TS-1187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1187: -- Fix Version/s: (was: sometime) 4.2.0 > TSMimeHdrFieldNameSet does not work for headers read from the client or > origin server (but does work for headers added by traffic server) > - > > Key: TS-1187 > URL: https://issues.apache.org/jira/browse/TS-1187 > Project: Traffic Server > Issue Type: Bug > Components: MIME >Affects Versions: 3.0.2 > Environment: Redhat linux with plugin that wants to rename a header > read from the client. >Reporter: Alistair Stevenson >Assignee: Bryan Call > Labels: api-change > Fix For: 4.2.0 > > > TSMimeHdrFieldNameSet does not work for headers read from the client or > origin server (but does work for headers added by traffic server) > The name appears set (and the function returns SUCCESS) but when the data is > sent to the origin Server it is corrupted at the point where the header is > set. i.e the header name is sent but the header is corrupted after this. > I am having to create a new header and copy the values and then destroy the > original header which is not as efficient. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (TS-1179) libraries and plugins are installed with .la files
[
https://issues.apache.org/jira/browse/TS-1179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13875923#comment-13875923
]
Igor Galić commented on TS-1179:
We can fix this when we replace our buildsystem.
> libraries and plugins are installed with .la files
> --
>
> Key: TS-1179
> URL: https://issues.apache.org/jira/browse/TS-1179
> Project: Traffic Server
> Issue Type: Bug
> Components: Build
>Reporter: Igor Galić
> Fix For: sometime
>
>
> Who needs or uses {{.la}} files?
> We have {{tsxs}} which compiles stuff without {{libtool}}, and the plugins
> definitely don't need {{.la}} files for loading.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (TS-1170) ats_ip_getbestaddrinfo should provide better options
[ https://issues.apache.org/jira/browse/TS-1170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13875922#comment-13875922 ] Leif Hedstrom commented on TS-1170: --- Alan, did you not resolve this stuff? Does this still need work, and if so, which version? > ats_ip_getbestaddrinfo should provide better options > > > Key: TS-1170 > URL: https://issues.apache.org/jira/browse/TS-1170 > Project: Traffic Server > Issue Type: Improvement > Components: Network >Affects Versions: 3.1.3 >Reporter: Alan M. Carroll >Assignee: Alan M. Carroll >Priority: Minor > Labels: ipv6 > Fix For: sometime > > > ats_ip_getbestaddrinfo should support better options about how it selects > addresses. > * Pick just one address that can be either family. > * Force IPv4, IPv6 or be able to prefer if two are equivalent. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TS-1069) better handle of the gzipped content
[ https://issues.apache.org/jira/browse/TS-1069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić updated TS-1069: --- Assignee: Zhao Yongming > better handle of the gzipped content > > > Key: TS-1069 > URL: https://issues.apache.org/jira/browse/TS-1069 > Project: Traffic Server > Issue Type: Sub-task >Reporter: Zhao Yongming >Assignee: Zhao Yongming > Fix For: sometime > > > when the triggered URL is gzipped, prefetch engine will skip that request, > while not put that URL in the prefetch url list, and start another request > without accept gzip encodes? -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (TS-1137) Expose API such that tests can easily be written in a glue-language such as Lua.
[ https://issues.apache.org/jira/browse/TS-1137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-1137. --- Resolution: Incomplete Fix Version/s: (was: sometime) > Expose API such that tests can easily be written in a glue-language such as > Lua. > > > Key: TS-1137 > URL: https://issues.apache.org/jira/browse/TS-1137 > Project: Traffic Server > Issue Type: New Feature > Components: Lua, TS API >Reporter: Igor Galić > > To unify and simplify our tests it would be great to have them in a script > language. > Lua is an ideal candidate as it is easy to embed. Imagine what it would be > like if users experiencing a bug could file a report with a test case > attached that reproduces it? -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (TS-1069) better handle of the gzipped content
[ https://issues.apache.org/jira/browse/TS-1069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13875920#comment-13875920 ] Igor Galić commented on TS-1069: [~zym] is this related to TS-983 ? Is it still an issue? > better handle of the gzipped content > > > Key: TS-1069 > URL: https://issues.apache.org/jira/browse/TS-1069 > Project: Traffic Server > Issue Type: Sub-task >Reporter: Zhao Yongming > Fix For: sometime > > > when the triggered URL is gzipped, prefetch engine will skip that request, > while not put that URL in the prefetch url list, and start another request > without accept gzip encodes? -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (TS-1034) reduce futex locking period
[
https://issues.apache.org/jira/browse/TS-1034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13875918#comment-13875918
]
Bryan Call commented on TS-1034:
I don't see a difference between Original and New? What changes did you make
to the futex locking period?
> reduce futex locking period
> ---
>
> Key: TS-1034
> URL: https://issues.apache.org/jira/browse/TS-1034
> Project: Traffic Server
> Issue Type: Improvement
> Components: Core, HTTP
>Affects Versions: 3.1.1
>Reporter: Zhao Yongming
>Assignee: Zhao Yongming
> Fix For: sometime
>
>
> we need to reduce futex locking period, here is a simple testing in my
> 24cores HP380 system, with 24 ab, all cached in memory:
> {code}
> #!/bin/sh
> for i in {1..24}
> do
> ab -n 1 -c 16 -X 127.0.0.$i:8080
> http://img02.taobaocdn.com/tps/i2/T1o0ypXk4w-1000-40.png?$i &
> done
> {code}
> result:
> {code}
> Every 2.0s: echo show:proxy-stats | traffic_shell
> Mon Nov 28 16:06:42 2011
> Successfully Initialized MgmtAPI in /var/run/trafficserver
> Document Hit Rate 100.00 % *
> Bandwidth Saving - 100.00 % *
> Cache Percent Free --- 99.999619 %
> Open Server Connections -- 0
> Open Client Connections -- 9
> Open Cache Connections --- 2
> Client Throughput 6824.747070 MBit/Sec
> Transaction Per Second --- 53914.925781
> * Value represents 10 second average.
> strace -c -p 11712
> Process 11712 attached - interrupt to quit
> ^CProcess 11712 detached
> % time seconds usecs/call callserrors syscall
> -- --- --- - -
> 26.850.890335 15 58920 writev
> 24.450.810866 7118147 epoll_ctl
> 22.270.738451 13 58920 close
> 11.500.381362 6 59227 getsockname
> 9.860.326843 3119192 59228 read
> 3.530.117058 16 7100 1931 futex
> 1.530.050884 58 884 epoll_wait
> 0.000.37 0 404 rt_sigprocmask
> 0.000.00 0 3 write
> 0.000.00 0 2 brk
> 0.000.00 010 msync
> -- --- --- - -
> 100.003.315836422809 61159 total
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (TS-1120) Use ink_zero / ats_zero instead of calling memset when zeroing a variable or member.
[ https://issues.apache.org/jira/browse/TS-1120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13875917#comment-13875917 ] Leif Hedstrom commented on TS-1120: --- Alan: Are we going to do this ? > Use ink_zero / ats_zero instead of calling memset when zeroing a variable or > member. > > > Key: TS-1120 > URL: https://issues.apache.org/jira/browse/TS-1120 > Project: Traffic Server > Issue Type: Improvement > Components: Cleanup >Affects Versions: 3.1.2 >Reporter: Alan M. Carroll >Priority: Minor > Labels: cleanup, memory, safety > Fix For: sometime > > > We have an inline template, ink_zero(foo) which does "memset(&foo, 0, > sizeof(foo))". Because this is easy to mess up with a typo, the inline > template should be used for safety and clarity. Also, the template should be > renamed "ats_zero" to be consistent. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TS-1050) Cached objects become inaccessible when new volumes are added to the cache.
[ https://issues.apache.org/jira/browse/TS-1050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1050: -- Fix Version/s: (was: sometime) 4.2.0 Assignee: Alan M. Carroll Alan: Please take a look at this bug, and decide what to do. Is this a dupe? New feature? Something you are or will fix? > Cached objects become inaccessible when new volumes are added to the cache. > --- > > Key: TS-1050 > URL: https://issues.apache.org/jira/browse/TS-1050 > Project: Traffic Server > Issue Type: Bug > Components: Cache >Affects Versions: 3.1.1 >Reporter: B Wyatt >Assignee: Alan M. Carroll > Fix For: 4.2.0 > > > During the investigation of TS-949 it came to light that even a consistent > hashing solution fails to maintain access for all objects in the cache when a > new volume is added. This is because a new volume will necessarily assume > ownership for some portion of the object/hash space. As a side effect of > this ownership change, new searches for previously cached objects may return > the new owner instead of the previous owner (which retained the cached copy). > According to the volume itself (and thus several aggregate statistics like > cache space usage), the objects are still valid and will remain as effective > dead weight until evicted during the normal cache operation. > See comments on TS-949 for initial discussion of possible solutions. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Assigned] (TS-983) prefetch: the documents
[ https://issues.apache.org/jira/browse/TS-983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić reassigned TS-983: - Assignee: Igor Galić (was: Zhao Yongming) > prefetch: the documents > --- > > Key: TS-983 > URL: https://issues.apache.org/jira/browse/TS-983 > Project: Traffic Server > Issue Type: Sub-task > Components: HTTP >Reporter: Zhao Yongming >Assignee: Igor Galić > Fix For: sometime > > -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TS-983) prefetch: the documents
[ https://issues.apache.org/jira/browse/TS-983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić updated TS-983: -- Assignee: Zhao Yongming (was: Igor Galić) > prefetch: the documents > --- > > Key: TS-983 > URL: https://issues.apache.org/jira/browse/TS-983 > Project: Traffic Server > Issue Type: Sub-task > Components: HTTP >Reporter: Zhao Yongming >Assignee: Zhao Yongming > Fix For: sometime > > -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (TS-983) prefetch: the documents
[ https://issues.apache.org/jira/browse/TS-983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13875914#comment-13875914 ] Igor Galić commented on TS-983: --- [~zym] Can you please either describe what this is supposed to do or close it. > prefetch: the documents > --- > > Key: TS-983 > URL: https://issues.apache.org/jira/browse/TS-983 > Project: Traffic Server > Issue Type: Sub-task > Components: HTTP >Reporter: Zhao Yongming >Assignee: Igor Galić > Fix For: sometime > > -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (TS-952) when turn off config.proxy.hostdb, ts just reponse a 502 page.
[ https://issues.apache.org/jira/browse/TS-952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-952. -- Resolution: Won't Fix Fix Version/s: (was: sometime) No objections, so closing. > when turn off config.proxy.hostdb, ts just reponse a 502 page. > -- > > Key: TS-952 > URL: https://issues.apache.org/jira/browse/TS-952 > Project: Traffic Server > Issue Type: Bug > Components: DNS, HTTP >Affects Versions: 3.1.0 > Environment: all. >Reporter: weijin >Assignee: Leif Hedstrom > > If turn config.proxy.hostdb off, ts does not do the dns query but just return > a 502 page. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (TS-910) log collation in custom log will make dedicate connection to the same collation server
[ https://issues.apache.org/jira/browse/TS-910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13875904#comment-13875904 ] Leif Hedstrom commented on TS-910: -- [~zym] Is this still an issue? If not, please remove the Fix version and close. If it is an issue, and someone will work on it, move the Fix Version and assignee accordingly. > log collation in custom log will make dedicate connection to the same > collation server > -- > > Key: TS-910 > URL: https://issues.apache.org/jira/browse/TS-910 > Project: Traffic Server > Issue Type: Improvement > Components: Logging >Affects Versions: 3.1.0 >Reporter: Zhao Yongming >Assignee: Zhao Yongming >Priority: Trivial > Fix For: sometime > > > when you define LogObject in logs_xml.config, and set CollationHosts, it will > open connections for each LogObject, despite you put the same host in > CollationHosts. > it will affect the default squid logging too. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (TS-910) log collation in custom log will make dedicate connection to the same collation server
[ https://issues.apache.org/jira/browse/TS-910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13875907#comment-13875907 ] Leif Hedstrom commented on TS-910: -- Also as Bryan points out, is the additional complication worth saving the connections? Is it a real performance hit? > log collation in custom log will make dedicate connection to the same > collation server > -- > > Key: TS-910 > URL: https://issues.apache.org/jira/browse/TS-910 > Project: Traffic Server > Issue Type: Improvement > Components: Logging >Affects Versions: 3.1.0 >Reporter: Zhao Yongming >Assignee: Zhao Yongming >Priority: Trivial > Fix For: sometime > > > when you define LogObject in logs_xml.config, and set CollationHosts, it will > open connections for each LogObject, despite you put the same host in > CollationHosts. > it will affect the default squid logging too. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (TS-904) when doing custom logging, it would be nice if we can set dedicate sampling rate for each rule
[
https://issues.apache.org/jira/browse/TS-904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13875905#comment-13875905
]
Igor Galić commented on TS-904:
---
[~zym] do you mean one of those:
{code}
{RECT_NODE, "proxy.node.log.event_log_error_aggr", RECD_INT, "0", RECU_NULL,
RR_NULL, RECC_NULL, NULL, RECA_NULL}
{RECT_NODE, "proxy.node.log.event_log_access_aggr", RECD_INT, "0",
RECU_NULL, RR_NULL, RECC_NULL, NULL, RECA_NULL}
{RECT_CLUSTER, "proxy.cluster.log.event_log_error_aggr", RECD_INT, "0",
RECU_NULL, RR_NULL, RECC_NULL, NULL, RECA_NULL}
{RECT_CLUSTER, "proxy.cluster.log.event_log_access_aggr", RECD_INT, "0",
RECU_NULL, RR_NULL, RECC_NULL, NULL, RECA_NULL}
{code}
or this stuff from log.xml:
{code}
This tag is needed when the format contains any of the aggregate
operators. The "aggregate_interval_secs" value is a number
representing the number of seconds over which the entry is aggregated
before being produced. The valid set of aggregate operators are:
COUNT '*' can be used for the field value
SUM
AVG
FIRST
LAST
{code}
Can you please clarify on the bug, and if it's no longer relevant, please close
it.
> when doing custom logging, it would be nice if we can set dedicate sampling
> rate for each rule
> --
>
> Key: TS-904
> URL: https://issues.apache.org/jira/browse/TS-904
> Project: Traffic Server
> Issue Type: New Feature
> Components: Logging
>Affects Versions: 3.0.0
>Reporter: Zhao Yongming
>Priority: Minor
> Fix For: sometime
>
>
> the sampling is a global config in logging, we want to get it custom-able.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (TS-2431) Add SPDY supporting to ATS
[
https://issues.apache.org/jira/browse/TS-2431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13875906#comment-13875906
]
Yunkai Zhang commented on TS-2431:
--
1) In fact, this version doesn't have significant improvement on performance
then plugin, as it denpends on FetchSM which will work with PluginVC. But in
this version, I have do some optimization for FetchSM, I think the new FetchSM
will be much more better than the old one, for more detail, you can read the
commit log or source code of
"0003-TS-2431-Extends-and-optimizes-FetchSM.V2.patch".
2) Our PluginVC should take both the locks of active_vc and passive_vc, and
more worse, the active_vc will go on to take the lock of FetchSM, so the lock
is too heavy for SPDY protocol. Ideally, all HTTP requests within a SPDY
session should run concurrently, but PluginVC can't archieve this purpose.
3) There is another shortcoming of PluginVC. In FetchSM, it will use PluginVC
to replace UnixNetVConnection to launch HTTP request. There are some important
code, such as stats code and throttle of connection in UnixNetVConnection, will
be missed in PluginVC. I hope we can reuse UnixNetVConnection when we launch
new HTTP request in SPDY, so that we can keep all HTTP requests are same as the
normal HTTP request.
That is why I want to implemant SPDY in core, although this version can't solve
all problems mentioned above, but it will be the first step. More work can
based on it.
> Add SPDY supporting to ATS
> --
>
> Key: TS-2431
> URL: https://issues.apache.org/jira/browse/TS-2431
> Project: Traffic Server
> Issue Type: New Feature
> Components: HTTP
>Reporter: Yunkai Zhang
>Assignee: Yunkai Zhang
> Fix For: 5.0.0
>
> Attachments: 0001-TS-2431-Preparation-of-SPDY-protocol.V2.patch,
> 0002-TS-2431-Add-autoconf-options-for-SPDY.V2.patch,
> 0003-TS-2431-Extends-and-optimizes-FetchSM.V2.patch,
> 0004-TS-2431-Implement-dechunk-supporting-in-FetchSM.V2.patch,
> 0005-TS-2431-Migrate-Taobao-SPDY-plugin-to-ATS-core.V2.patch,
> 0006-TS-2431-Add-SSL-supporting-for-SPDY.V2.patch,
> 0007-Fix-crypto.m4-when-detect-openssl-library-in-64bit-O.V2.patch
>
>
> I must say, sorry for my late. And now, I have finished the first version,
> the migration of Taobao SPDY plugin to ATS core.
> But seriously speaking, the migration to ATS core is finished *partially*. I
> had tried to remove the dependency of *fetcher* library created by @Quehan
> and create a specific VC for each http request in spdy sm, but I found it was
> too difficult, so I give up temporarily.
> Let me push this series patches to here before it's perfect enough, at least,
> this series can statisfy TAOBAO's current demand (in fact, this version has
> had good performance in our testing, but it can do much better I think).
> I had thought another solution instread of recreating a new VC for each http
> request in spdy sm, which will replace FetchSM's function and speed up SPDY
> protocol, but will not change the framework of this version. So I can hacking
> it based on these patches in the future.
> == *UPDATE* ==
> - From now on, SPDY can work with SSL, Cheers!
> ==How to test it==
> - Install *spdylay* library, here is URL of this lib:
> Download spdylay library: https://github.com/tatsuhiro-t/spdylay
> - Use '--enable-spdy' option to compile ATS:
> {code}
> $ ./configure --enable-spdy
> $ make all && make install
> {code}
> - SPDY can work with SSL now, it depends on OpenSSL >= 1.0.1. You can use
> '--with-openssl=' option to tell ATS where to search it:
> {code}
> $ ./configure --enable-spdy --with-openssl=/path/to/openssl-1.01
> {code}
> - Need not to config anything if you just want to test SPDY without SSL.
>The code can recognize SPDY or HTTP by reading this first byte of request.
> - When test SPDY+SSL, you may need to configure SSL key properly for ATS.
> - You can use *spdycat* in spdylay(or other SPDY client) to do request, for
> example:
> {code}
> # SPDY without SSL
> $ spdycat -3 -v --no-tls http://localhost/b.txt
> # SPDY + SSL
> $ spdycat -3 -v https://localhost/b.txt
> {code}
> - You can enable debuging logs of SPDY:
> {code}
> CONFIG proxy.config.diags.debug.enabled INT 1
> CONFIG proxy.config.diags.debug.tags STRING spdy
> {code}
> ==TODO===
> - Migrate spdy configuration to ATS records.config
> Any feedbacks are welcome.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (TS-879) Seek on cached file
[ https://issues.apache.org/jira/browse/TS-879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-879: - Assignee: Alan M. Carroll Alan, is this something we should work on? Can you take a quick gander please. It sounds like the request is to expose some of the pread feature into InkAPI? Note that we still don't have a way to read/ write the HTTP cache, and perhaps this would be part of that? I.e. why would we bother to expose the pread functionality for that, shouldn't that just be automatic ? > Seek on cached file > --- > > Key: TS-879 > URL: https://issues.apache.org/jira/browse/TS-879 > Project: Traffic Server > Issue Type: Bug > Components: Cache, TS API >Affects Versions: 3.0.0 >Reporter: Nelson Pérez >Assignee: Alan M. Carroll > Labels: api-addition, cache, trafficserver > Fix For: sometime > > > I want a custom written plugin to be able to seek to any point in a cached > file. According to John Plevyak > (http://www.mail-archive.com/dev@trafficserver.apache.org/msg02785.html) this > feature is new in the cache, but not yet available to the API. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
