[jira] [Updated] (TS-3577) ATS with --enable-static-proxy does not compile
[
https://issues.apache.org/jira/browse/TS-3577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-3577:
---
Fix Version/s: (was: 6.0.0)
6.1.0
ATS with --enable-static-proxy does not compile
---
Key: TS-3577
URL: https://issues.apache.org/jira/browse/TS-3577
Project: Traffic Server
Issue Type: Bug
Components: Build
Reporter: Thomas Jackson
Fix For: 6.1.0
Lots of errors in the build:
{code}
libtool: link: warning: complete static linking is impossible in this
configuration
../lib/records/librecords_p.a(P_RecCore.o): In function `RecSetRecord(RecT,
char const*, RecDataT, RecData*, RecRawStat*, bool, bool)':
/var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:465:
undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
/var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:376:
undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
../lib/records/librecords_p.a(P_RecCore.o): In function `RecSetRecord':
/var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:465:
undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
/var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:376:
undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
/var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:465:
undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
/var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:376:
undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
/var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:465:
undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
/var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:376:
undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
/var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:465:
undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
/var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:376:
undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
/var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:465:
undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
/var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:376:
undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
../lib/records/librecords_p.a(P_RecCore.o): In function `RecReadStatsFile()':
/var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:525:
undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
/var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:562:
undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
../lib/records/librecords_p.a(P_RecCore.o): In function
`RecReadConfigFile(bool)':
/var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:633:
undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
/var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:639:
undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
../lib/records/librecords_p.a(P_RecCore.o): In function
`RecSyncConfigToTB(textBuffer*, bool*)':
/var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:702:
undefined reference to `textBuffer::reUse()'
/var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:704:
undefined reference to `ink_rwlock_rdlock(ink_rwlock*)'
/var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:710:
undefined reference to `textBuffer::copyFrom(void const*, unsigned int)'
/var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:711:
undefined reference to `textBuffer::copyFrom(void const*, unsigned int)'
/var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:774:
undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
/var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:718:
undefined reference to `textBuffer::copyFrom(void const*, unsigned int)'
/var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:737:
undefined reference to `textBuffer::copyFrom(void const*, unsigned int)'
/var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:738:
undefined reference to `textBuffer::copyFrom(void const*, unsigned int)'
/var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:760:
undefined reference to `textBuffer::copyFrom(void const*, unsigned int)'
/var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:762:
undefined reference to `textBuffer::copyFrom(void const*, unsigned int)'
../lib/records/librecords_p.a(P_RecCore.o):/var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:752:
more undefined references to `textBuffer::copyFrom(void const*, unsigned
int)' follow
../lib/records/librecords_p.a(P_RecCore.o): In function
`RecSetSyncRequired(char*, bool)':
[jira] [Updated] (TS-3575) Make an option for traffic_layout to reproduce the configure invocation
[ https://issues.apache.org/jira/browse/TS-3575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-3575: --- Assignee: (was: Leif Hedstrom) Make an option for traffic_layout to reproduce the configure invocation --- Key: TS-3575 URL: https://issues.apache.org/jira/browse/TS-3575 Project: Traffic Server Issue Type: Improvement Components: CI, Tools Reporter: Leif Hedstrom Fix For: 6.1.0 Basically have it echo out the equivalent of what is in config.nice. This will be useful not only for someone to check the build, but our tsqa tool can then use that to decide what tests are suitable for the run. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TS-3586) milestones/slow log data do not have visibility to internal redirect follow
[ https://issues.apache.org/jira/browse/TS-3586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheer Vinukonda resolved TS-3586. --- Resolution: Fixed Unfortunately, there was no consensus on how exactly to report the timing info during 3xx follow. For the time being, I just added a count of number of redirects to the slow log to indicate whether or not a txn included redirect follow. Closing this for now - will open a new jira to track more timing info for 3xx follow, when/if required. milestones/slow log data do not have visibility to internal redirect follow --- Key: TS-3586 URL: https://issues.apache.org/jira/browse/TS-3586 Project: Traffic Server Issue Type: Improvement Components: HTTP Reporter: Sudheer Vinukonda Fix For: 6.0.0 milestones/slow log data do not have visibility to internal redirect follow. It is still under discussion on how best to fit the data (if at all), and the impact the change would have on the slow log API, log tags, metrics, slow log format etc. For the time being, added the *redirection_tries* to the slow log to indicate how many internal redirect follow events occurred on the TXN. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3589) Enhance header_rewrite to support TRANSACT_COUNT as a condition
[ https://issues.apache.org/jira/browse/TS-3589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-3589: --- Assignee: Alan M. Carroll (was: Eric Schwartz) Enhance header_rewrite to support TRANSACT_COUNT as a condition --- Key: TS-3589 URL: https://issues.apache.org/jira/browse/TS-3589 Project: Traffic Server Issue Type: New Feature Components: Plugins Reporter: Eric Schwartz Assignee: Alan M. Carroll Fix For: 6.0.0 Adding support to header_rewrite to support TRANSACT_COUNT as a condition. Will allow us to add/modify headers on connections that share a Client Session. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3625) Some statistics not being gathered
[ https://issues.apache.org/jira/browse/TS-3625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-3625: --- Fix Version/s: (was: 7.0.0) 6.0.0 Some statistics not being gathered -- Key: TS-3625 URL: https://issues.apache.org/jira/browse/TS-3625 Project: Traffic Server Issue Type: Bug Components: Metrics Reporter: Jon Sime Labels: compatibility Fix For: 6.0.0 The following statistics appear to not have any data collected for them in recent versions of TS, instead only emitting a zero value. The list was put together by examining the stats_over_http output on a production instance which receives enough varied traffic that it should, in theory at least, cause most implemented statistics to go non-zero. proxy.node.cache.contents.num_docs proxy.node.cache_hit_mem_ratio_avg_10s_int_pct proxy.node.cache_hit_mem_ratio_int_pct proxy.node.current_cache_connections proxy.node.dns.lookup_avg_time_ms proxy.node.dns.lookups_per_second proxy.node.dns.total_dns_lookups proxy.node.http.transaction_frac_avg_10s.errors.aborts_int_pct proxy.node.http.transaction_frac_avg_10s.errors.connect_failed_int_pct proxy.node.http.transaction_frac_avg_10s.errors.early_hangups_int_pct proxy.node.http.transaction_frac_avg_10s.errors.empty_hangups_int_pct proxy.node.http.transaction_frac_avg_10s.errors.other_int_pct proxy.node.http.transaction_frac_avg_10s.errors.possible_aborts_int_pct proxy.node.http.transaction_frac_avg_10s.errors.pre_accept_hangups_int_pct proxy.node.http.transaction_frac_avg_10s.hit_fresh_int_pct proxy.node.http.transaction_frac_avg_10s.hit_revalidated_int_pct proxy.node.http.transaction_frac_avg_10s.miss_changed_int_pct proxy.node.http.transaction_frac_avg_10s.miss_client_no_cache_int_pct proxy.node.http.transaction_frac_avg_10s.miss_cold_int_pct proxy.node.http.transaction_frac_avg_10s.miss_not_cacheable_int_pct proxy.node.http.transaction_frac_avg_10s.other.unclassified_int_pct proxy.node.log.bytes_flush_to_disk proxy.node.log.bytes_lost_before_flush_to_disk proxy.node.log.bytes_lost_before_preproc proxy.node.log.bytes_lost_before_sent_to_network proxy.node.log.bytes_lost_before_written_to_disk proxy.node.log.bytes_received_from_network proxy.node.log.bytes_received_from_network_avg_10s proxy.node.log.bytes_sent_to_network proxy.node.log.bytes_sent_to_network_avg_10s proxy.node.log.bytes_written_to_disk proxy.node.log.event_log_access_aggr proxy.node.log.event_log_access_fail proxy.node.log.event_log_access_full proxy.node.log.event_log_access_ok proxy.node.log.event_log_access_skip proxy.node.log.event_log_error_aggr proxy.node.log.event_log_error_fail proxy.node.log.event_log_error_full proxy.node.log.event_log_error_ok proxy.node.log.event_log_error_skip proxy.node.log.num_flush_to_disk proxy.node.log.num_lost_before_flush_to_disk proxy.node.log.num_lost_before_sent_to_network proxy.node.log.num_received_from_network proxy.node.log.num_sent_to_network proxy.process.cache.directory_collision proxy.process.cache.evacuate.active proxy.process.cache.evacuate.failure proxy.process.cache.evacuate.success proxy.process.cache.frags_per_doc.1 proxy.process.cache.frags_per_doc.2 proxy.process.cache.frags_per_doc.3+ proxy.process.cache.gc_bytes_evacuated proxy.process.cache.gc_frags_evacuated proxy.process.cache.hdr_marshal_bytes proxy.process.cache.hdr_marshals proxy.process.cache.lookup.active proxy.process.cache.lookup.failure proxy.process.cache.lookup.success proxy.process.cache.percent_full proxy.process.cache.pread_count proxy.process.cache.read_busy.failure proxy.process.cache.read_busy.success proxy.process.cache.remove.active proxy.process.cache.remove.failure proxy.process.cache.remove.success proxy.process.cache.scan.active proxy.process.cache.scan.failure proxy.process.cache.scan.success proxy.process.cache.volume_0.directory_collision proxy.process.cache.volume_0.evacuate.active proxy.process.cache.volume_0.evacuate.failure proxy.process.cache.volume_0.evacuate.success proxy.process.cache.volume_0.frags_per_doc.1 proxy.process.cache.volume_0.frags_per_doc.2 proxy.process.cache.volume_0.frags_per_doc.3+ proxy.process.cache.volume_0.gc_bytes_evacuated proxy.process.cache.volume_0.gc_frags_evacuated proxy.process.cache.volume_0.hdr_marshal_bytes proxy.process.cache.volume_0.hdr_marshals proxy.process.cache.volume_0.lookup.active proxy.process.cache.volume_0.lookup.failure proxy.process.cache.volume_0.lookup.success proxy.process.cache.volume_0.pread_count proxy.process.cache.volume_0.remove.active proxy.process.cache.volume_0.remove.failure proxy.process.cache.volume_0.remove.success proxy.process.cache.volume_0.scan.active proxy.process.cache.volume_0.scan.failure
[jira] [Commented] (TS-3136) Change default TLS cipher suites
[
https://issues.apache.org/jira/browse/TS-3136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14588253#comment-14588253
]
Dave Thompson commented on TS-3136:
---
I did some performance tests a while back using ATS. For some relative
general reference ballpark numbers see below. Hardware was AES-NI capable.
3DES was clearly CPU bound, the others were likely network bound in the test
environment.
100% 3DES ciphers, I was able to see 1.5Gbps with ~99% CPU.
100% AES_GCM ciphers, I was able to see 5.3Gbps with 35%CPU.
100% RC4_CBC, 4.5Gbps with 50% CPU.
Change default TLS cipher suites
Key: TS-3136
URL: https://issues.apache.org/jira/browse/TS-3136
Project: Traffic Server
Issue Type: Improvement
Components: Security, SSL
Reporter: Leif Hedstrom
Assignee: Susan Hinrichs
Labels: compatibility
Fix For: 6.0.0
In TS-3135 [~i.galic] suggested:
{quote}
also, recommendations for a safer ciphersuite:
SSLCipherSuite
ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4
from https://cipherli.st/
{quote}
[~jacksontj] had responded with:
{quote}
[~i.galic] That cipher quite is geared towards security, but doesn't support
quite a few older clients. I'd recommend we use the suite from mozilla
(https://wiki.mozilla.org/Security/Server_Side_TLS#Recommended_Server_Configurations)
which is a good mix of security and compatibility:
{code}
ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA
{code}
{quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (TS-3655) regression test segfault
[ https://issues.apache.org/jira/browse/TS-3655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call resolved TS-3655. Resolution: Fixed regression test segfault Key: TS-3655 URL: https://issues.apache.org/jira/browse/TS-3655 Project: Traffic Server Issue Type: Bug Reporter: weijin Fix For: 6.0.0 the regression test SDK_API_TSPortDescriptor forget to close the net_vc of server side when free the caller. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3694) Fix function documentation to Log::error
[
https://issues.apache.org/jira/browse/TS-3694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-3694:
---
Assignee: (was: Daniel Xu)
Fix function documentation to Log::error
Key: TS-3694
URL: https://issues.apache.org/jira/browse/TS-3694
Project: Traffic Server
Issue Type: Improvement
Components: Logging
Reporter: Daniel Xu
Fix For: Docs
The description for this function seems to be out of date. The note directly
contradicts what the function actually does.
{code:title=Log.cc|borderStyle=solid}
/*-
Log::error
Make an entry into the current error log. For convenience, it is given in
both variable argument (format, ...) and stdarg (format, va_list) forms.
Note that Log::error could call Log::va_error after calling va_start
so that va_error handles the statistics update. However, to make
Log::error slightly more efficient this is not the case. The
downside is that one has to be careful to update both functions if
need be.
-*/
int
Log::error(const char *format, ...)
{
va_list ap;
int ret;
va_start(ap, format);
ret = Log::va_error(format, ap);
va_end(ap);
return ret;
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3136) Change default TLS cipher suites
[
https://issues.apache.org/jira/browse/TS-3136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14588169#comment-14588169
]
Susan Hinrichs commented on TS-3136:
[~jacksontj] did the increase in 3DES impact your CPU utilization in a
significant way?
Change default TLS cipher suites
Key: TS-3136
URL: https://issues.apache.org/jira/browse/TS-3136
Project: Traffic Server
Issue Type: Improvement
Components: Security, SSL
Reporter: Leif Hedstrom
Assignee: Susan Hinrichs
Labels: compatibility
Fix For: 6.0.0
In TS-3135 [~i.galic] suggested:
{quote}
also, recommendations for a safer ciphersuite:
SSLCipherSuite
ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4
from https://cipherli.st/
{quote}
[~jacksontj] had responded with:
{quote}
[~i.galic] That cipher quite is geared towards security, but doesn't support
quite a few older clients. I'd recommend we use the suite from mozilla
(https://wiki.mozilla.org/Security/Server_Side_TLS#Recommended_Server_Configurations)
which is a good mix of security and compatibility:
{code}
ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA
{code}
{quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3583) cache.config matches all rules - action=never-cache
[ https://issues.apache.org/jira/browse/TS-3583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-3583: --- Summary: cache.config matches all rules - action=never-cache (was: cache.config action=never-cache) cache.config matches all rules - action=never-cache --- Key: TS-3583 URL: https://issues.apache.org/jira/browse/TS-3583 Project: Traffic Server Issue Type: Bug Components: Cache Reporter: Faysal Banna Fix For: sometime Hello Guys in cache.config i have url_regex=.*leagueof.* action=never-cache as the first rule in cache.config and i purged all files or url's for that contains http://.*leagueof.* now in the squid.log i get 1430817070.971 238 127.0.0.1 TCP_MISS/200 89507 GET http://news.cdn.leagueoflegends.com/public/oembed/0.0.173/img/patchnotes/full/background.jpg - DIRECT/news.cdn.leagueoflegends.com image/jpeg 1430817078.211 0 127.0.0.1 TCP_HIT/200 89576 GET http://news.cdn.leagueoflegends.com/public/oembed/0.0.173/img/patchnotes/full/background.jpg - NONE/- image/jpeg how can this be ? trafficserver 5.2.0 Much Regards -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3595) Cookie header split into multiple lines with H2
[
https://issues.apache.org/jira/browse/TS-3595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-3595:
---
Fix Version/s: (was: 6.0.0)
6.1.0
Cookie header split into multiple lines with H2
---
Key: TS-3595
URL: https://issues.apache.org/jira/browse/TS-3595
Project: Traffic Server
Issue Type: Bug
Components: HTTP/2
Reporter: Scott Beardsley
Priority: Critical
Fix For: 6.1.0
I've noticed that the Cookie header is now split into multiple lines. I can't
tell if this is a part of the HPACK spec but it is definitely different from
the SPDY 3.1 TS implementation.
[May 12 06:08:10.630] Server {0x2b387f285700} DEBUG: (http2_hpack_decode)
Decoded field: :authority: search.yahoo.com
[May 12 06:08:10.630] Server {0x2b387f285700} DEBUG: (http2_hpack_decode)
Decoded field: :method: GET
[May 12 06:08:10.630] Server {0x2b387f285700} DEBUG: (http2_hpack_decode)
Decoded field: :path: /
[May 12 06:08:10.630] Server {0x2b387f285700} DEBUG: (http2_hpack_decode)
Decoded field: :scheme: https
[May 12 06:08:10.630] Server {0x2b387f285700} DEBUG: (http2_hpack_decode)
Decoded field: Accept: */*
[May 12 06:08:10.630] Server {0x2b387f285700} DEBUG: (http2_hpack_decode)
Decoded field: Accept-Encoding: gzip, deflate, sdch
[May 12 06:08:10.630] Server {0x2b387f285700} DEBUG: (http2_hpack_decode)
Decoded field: Accept-Language: en-US,en;q=0.8,it-IT;q=0.6,it;q=0.4,ja;q=0.2
[May 12 06:08:10.630] Server {0x2b387f285700} DEBUG: (http2_hpack_decode)
Decoded field: Cookie: AO=u=1o=1
[May 12 06:08:10.631] Server {0x2b387f285700} DEBUG: (http2_hpack_decode)
Decoded field: Cookie: B=abc123
[May 12 06:08:10.631] Server {0x2b387f285700} DEBUG: (http2_hpack_decode)
Decoded field: Cookie: DSS=321321
[May 12 06:08:10.631] Server {0x2b387f285700} DEBUG: (http2_hpack_decode)
Decoded field: User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_5)
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.135 Safari/537.36
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3607) ats_pagespeed make error
[ https://issues.apache.org/jira/browse/TS-3607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-3607: --- Fix Version/s: (was: 6.0.0) sometime ats_pagespeed make error Key: TS-3607 URL: https://issues.apache.org/jira/browse/TS-3607 Project: Traffic Server Issue Type: Bug Reporter: Sebastian Pesman Assignee: Otto van der Schaaf Fix For: sometime When compiling ats_pagespeed from the current master git /tmp/trafficserver/plugins/experimental/ats_pagespeed the make process results in an error. The error: ats_pagespeed.cc: In function 'void ats_transform_init(TSCont, TransformCtx*)': ats_pagespeed.cc:485:109: error: 'INT64_MAX' was not declared in this scope ctx-downstream_vio = TSVConnWrite(downstream_conn, contp, TSIOBufferReaderAlloc(ctx-downstream_buffer), INT64_MAX); ^ make: *** [ats_pagespeed.so] Error 1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3606) Add configuration option to allow server context per thread
[ https://issues.apache.org/jira/browse/TS-3606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-3606: --- Fix Version/s: (was: 6.0.0) 6.1.0 Add configuration option to allow server context per thread --- Key: TS-3606 URL: https://issues.apache.org/jira/browse/TS-3606 Project: Traffic Server Issue Type: Improvement Components: SSL Reporter: Bryan Call Assignee: Bryan Call Fix For: 6.1.0 Attachments: TS-3606-hack-for-53.diff This was recommended by John Foley (OpenSSL developer) to reduce lock contention. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3625) Some statistics not being gathered
[ https://issues.apache.org/jira/browse/TS-3625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-3625: --- Fix Version/s: (was: 6.0.0) 6.1.0 Some statistics not being gathered -- Key: TS-3625 URL: https://issues.apache.org/jira/browse/TS-3625 Project: Traffic Server Issue Type: Bug Components: Metrics Reporter: Jon Sime Labels: compatibility Fix For: 7.0.0 The following statistics appear to not have any data collected for them in recent versions of TS, instead only emitting a zero value. The list was put together by examining the stats_over_http output on a production instance which receives enough varied traffic that it should, in theory at least, cause most implemented statistics to go non-zero. proxy.node.cache.contents.num_docs proxy.node.cache_hit_mem_ratio_avg_10s_int_pct proxy.node.cache_hit_mem_ratio_int_pct proxy.node.current_cache_connections proxy.node.dns.lookup_avg_time_ms proxy.node.dns.lookups_per_second proxy.node.dns.total_dns_lookups proxy.node.http.transaction_frac_avg_10s.errors.aborts_int_pct proxy.node.http.transaction_frac_avg_10s.errors.connect_failed_int_pct proxy.node.http.transaction_frac_avg_10s.errors.early_hangups_int_pct proxy.node.http.transaction_frac_avg_10s.errors.empty_hangups_int_pct proxy.node.http.transaction_frac_avg_10s.errors.other_int_pct proxy.node.http.transaction_frac_avg_10s.errors.possible_aborts_int_pct proxy.node.http.transaction_frac_avg_10s.errors.pre_accept_hangups_int_pct proxy.node.http.transaction_frac_avg_10s.hit_fresh_int_pct proxy.node.http.transaction_frac_avg_10s.hit_revalidated_int_pct proxy.node.http.transaction_frac_avg_10s.miss_changed_int_pct proxy.node.http.transaction_frac_avg_10s.miss_client_no_cache_int_pct proxy.node.http.transaction_frac_avg_10s.miss_cold_int_pct proxy.node.http.transaction_frac_avg_10s.miss_not_cacheable_int_pct proxy.node.http.transaction_frac_avg_10s.other.unclassified_int_pct proxy.node.log.bytes_flush_to_disk proxy.node.log.bytes_lost_before_flush_to_disk proxy.node.log.bytes_lost_before_preproc proxy.node.log.bytes_lost_before_sent_to_network proxy.node.log.bytes_lost_before_written_to_disk proxy.node.log.bytes_received_from_network proxy.node.log.bytes_received_from_network_avg_10s proxy.node.log.bytes_sent_to_network proxy.node.log.bytes_sent_to_network_avg_10s proxy.node.log.bytes_written_to_disk proxy.node.log.event_log_access_aggr proxy.node.log.event_log_access_fail proxy.node.log.event_log_access_full proxy.node.log.event_log_access_ok proxy.node.log.event_log_access_skip proxy.node.log.event_log_error_aggr proxy.node.log.event_log_error_fail proxy.node.log.event_log_error_full proxy.node.log.event_log_error_ok proxy.node.log.event_log_error_skip proxy.node.log.num_flush_to_disk proxy.node.log.num_lost_before_flush_to_disk proxy.node.log.num_lost_before_sent_to_network proxy.node.log.num_received_from_network proxy.node.log.num_sent_to_network proxy.process.cache.directory_collision proxy.process.cache.evacuate.active proxy.process.cache.evacuate.failure proxy.process.cache.evacuate.success proxy.process.cache.frags_per_doc.1 proxy.process.cache.frags_per_doc.2 proxy.process.cache.frags_per_doc.3+ proxy.process.cache.gc_bytes_evacuated proxy.process.cache.gc_frags_evacuated proxy.process.cache.hdr_marshal_bytes proxy.process.cache.hdr_marshals proxy.process.cache.lookup.active proxy.process.cache.lookup.failure proxy.process.cache.lookup.success proxy.process.cache.percent_full proxy.process.cache.pread_count proxy.process.cache.read_busy.failure proxy.process.cache.read_busy.success proxy.process.cache.remove.active proxy.process.cache.remove.failure proxy.process.cache.remove.success proxy.process.cache.scan.active proxy.process.cache.scan.failure proxy.process.cache.scan.success proxy.process.cache.volume_0.directory_collision proxy.process.cache.volume_0.evacuate.active proxy.process.cache.volume_0.evacuate.failure proxy.process.cache.volume_0.evacuate.success proxy.process.cache.volume_0.frags_per_doc.1 proxy.process.cache.volume_0.frags_per_doc.2 proxy.process.cache.volume_0.frags_per_doc.3+ proxy.process.cache.volume_0.gc_bytes_evacuated proxy.process.cache.volume_0.gc_frags_evacuated proxy.process.cache.volume_0.hdr_marshal_bytes proxy.process.cache.volume_0.hdr_marshals proxy.process.cache.volume_0.lookup.active proxy.process.cache.volume_0.lookup.failure proxy.process.cache.volume_0.lookup.success proxy.process.cache.volume_0.pread_count proxy.process.cache.volume_0.remove.active proxy.process.cache.volume_0.remove.failure proxy.process.cache.volume_0.remove.success proxy.process.cache.volume_0.scan.active proxy.process.cache.volume_0.scan.failure
[jira] [Updated] (TS-3663) Enhance redirect follow to allow storing intermediate redirect responses
[
https://issues.apache.org/jira/browse/TS-3663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-3663:
---
Fix Version/s: (was: 6.0.0)
6.1.0
Enhance redirect follow to allow storing intermediate redirect responses
Key: TS-3663
URL: https://issues.apache.org/jira/browse/TS-3663
Project: Traffic Server
Issue Type: New Feature
Components: HTTP
Reporter: Sudheer Vinukonda
Assignee: Sudheer Vinukonda
Fix For: 6.1.0
Attachments: TS-3663.diff
This is a follow up jira to TS-3661 and TS-3652.
Basically, TS stores the final (2xx or any other status that is cacheable)
response after all the redirect follow attempts against the original cache
key (i.e remapped url from the client url or a modified cache key via API).
All the intermediate 3xx responses are never stored in the cache. There's a
lot of confusing/misleading code that tries to build a new cache key with the
Location header and tries to read/write the 3xx responses. All these
read/writes fail, since, the cache_sm for the original key (remapped client
request url or modified API key) still is open.
Below are some snippets of code that are related:
https://github.com/apache/trafficserver/blob/master/proxy/http/HttpSM.cc#L4450
https://github.com/apache/trafficserver/blob/master/proxy/http/HttpSM.cc#L4350
{code}
if (t_state.redirect_info.redirect_in_process) {
o_url = (t_state.redirect_info.original_url);
ink_assert(o_url-valid());
restore_client_request = true;
s_url = o_url;
} else {
//..
{code}
{code}
if (t_state.redirect_info.redirect_in_process)
c_url = t_state.hdr_info.client_request.url_get();
else
//
{code}
After discussing further with [~bcall] and [~zwoop], we think that this could
be made as an improvement to the current redirect follow behavior. Basically,
extend the setting *proxy.config.http.redirection_enabled* to support a new
option that stores intermediate redirect responses against a cache key that
is set as the *Location* followed.
Further to simply configuration (and to avoid confusion via multiple ways of
doing the same thing), the setting *proxy.config.http.redirection_enabled*
will be made overridable while deprecating the existing TS API
*TSHttpTxnFollowRedirect*, since the config setting is sufficient to achieve
the same behavior. This should be done regardless of this new feature.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3666) Invalid response when response transform triggers TS_EVENT_ERROR
[
https://issues.apache.org/jira/browse/TS-3666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-3666:
---
Assignee: Phil Sorber
Invalid response when response transform triggers TS_EVENT_ERROR
Key: TS-3666
URL: https://issues.apache.org/jira/browse/TS-3666
Project: Traffic Server
Issue Type: Bug
Reporter: Michael Graham
Assignee: Phil Sorber
Fix For: 6.0.0
Attachments: ts.patch
I have a response transform plugin that triggers TS_EVENT_ERROR but when TS
returns the page the response is invalid:
{noformat}
http_proxy=127.0.0.1:6045 curl -v www.airfix.com/us-en/
* About to connect() to proxy 127.0.0.1 port 6045 (#0)
* Trying 127.0.0.1... connected
GET HTTP://www.airfix.com/us-en/ HTTP/1.1
User-Agent: curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0
OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3
Host: www.airfix.com
Accept: */*
Proxy-Connection: Keep-Alive
HTTP/1.1 500 INKApi Error
Date: Wed, 03 Jun 2015 17:51:22 GMT
Transfer-Encoding: chunked
Proxy-Connection: keep-alive
Server: ATS/5.1.2
X-Cache: MISS from death-cache
Content-Length: 0
{noformat}
TS is sending both TE chunked and a content-length of 0.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3676) CONFIG proxy.config.http.no_dns_just_forward_to_parent triggers crash
[
https://issues.apache.org/jira/browse/TS-3676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-3676:
---
Fix Version/s: (was: 6.0.0)
6.1.0
CONFIG proxy.config.http.no_dns_just_forward_to_parent triggers crash
-
Key: TS-3676
URL: https://issues.apache.org/jira/browse/TS-3676
Project: Traffic Server
Issue Type: Bug
Components: Parent Proxy
Reporter: Randall Meyer
Fix For: 6.1.0
Attachments: stacktrace.txt
I have a parent/child cluster running without issue. Recently, I added a new
map to a unresolvable name on the child host (in my example resource_host).
I set proxy.config.http.no_dns_just_forward_to_parent to 1 on the child.
This worked fine for some time(many hours), serving up . But after awhile,
the parent ATS-process crashes.
3 days later (with crashes happening every evening), I changed the config
back to 0 and started using a name resolvable on the child. Since that
change, there's been no crashes.
This was observed on a set of 30 child hosts all dying with the same
callstack.
records.config:
{noformat}
CONFIG proxy.config.http.no_dns_just_forward_to_parent INT 1
CONFIG proxy.config.http.parent_proxy_routing_enable INT 1
{noformat}
remap.config:
{noformat}
map /resource.json \
http://resource_host/mapped/resource.json
{noformat}
parent.config
{noformat}
dest_domain=resource_host method=get parent=parent_host.domain.com:80
round_robin=consistent_hash go_direct=false
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3675) Make HTTP/2 upgrade contexts handle bad settings properly
[
https://issues.apache.org/jira/browse/TS-3675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14588298#comment-14588298
]
Bryan Call commented on TS-3675:
Invalid settings frame is being sent. Do what the RFC says, most likely send
GOAWAY.
Make HTTP/2 upgrade contexts handle bad settings properly
-
Key: TS-3675
URL: https://issues.apache.org/jira/browse/TS-3675
Project: Traffic Server
Issue Type: Bug
Components: HTTP/2
Reporter: Leif Hedstrom
Fix For: sometime
Right now, we have:
{code}
if (!http2_parse_settings_parameter(make_iovec(out_buf + nbytes,
HTTP2_SETTINGS_PARAMETER_LEN), param) ||
!http2_settings_parameter_is_valid(param)) {
// TODO ignore incoming invalid parameters and send suitable
SETTINGS frame.
{code}
And then we continue trying to set the invalid parameter anyways.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3136) Change default TLS cipher suites
[
https://issues.apache.org/jira/browse/TS-3136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14588316#comment-14588316
]
Dave Thompson commented on TS-3136:
---
Doh, I meant RC4 as in RC4_SHA, That would be a trick to make that stream
cipher CBC :-)
Change default TLS cipher suites
Key: TS-3136
URL: https://issues.apache.org/jira/browse/TS-3136
Project: Traffic Server
Issue Type: Improvement
Components: Security, SSL
Reporter: Leif Hedstrom
Assignee: Susan Hinrichs
Labels: compatibility
Fix For: 6.0.0
In TS-3135 [~i.galic] suggested:
{quote}
also, recommendations for a safer ciphersuite:
SSLCipherSuite
ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4
from https://cipherli.st/
{quote}
[~jacksontj] had responded with:
{quote}
[~i.galic] That cipher quite is geared towards security, but doesn't support
quite a few older clients. I'd recommend we use the suite from mozilla
(https://wiki.mozilla.org/Security/Server_Side_TLS#Recommended_Server_Configurations)
which is a good mix of security and compatibility:
{code}
ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA
{code}
{quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3692) Remove code associated with proxy.config.url_remap.url_remap_mode
[ https://issues.apache.org/jira/browse/TS-3692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber updated TS-3692: Fix Version/s: 6.1.0 Remove code associated with proxy.config.url_remap.url_remap_mode - Key: TS-3692 URL: https://issues.apache.org/jira/browse/TS-3692 Project: Traffic Server Issue Type: Task Components: HTTP Reporter: John Rushford Assignee: John Rushford Fix For: 6.1.0 See https://issues.apache.org/jira/browse/TS-481. I removed the configuration parameter proxy.config.url_remap.url_remap_mode in time for release 6.0. Need to go back and remove the unused code associated with that parameter. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3563) Support cond expansions in string values in header_rewrite plugin
[
https://issues.apache.org/jira/browse/TS-3563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-3563:
---
Summary: Support cond expansions in string values in header_rewrite plugin
(was: support cond expansions in string values in header_rewrite plugin)
Support cond expansions in string values in header_rewrite plugin
-
Key: TS-3563
URL: https://issues.apache.org/jira/browse/TS-3563
Project: Traffic Server
Issue Type: New Feature
Components: Plugins
Affects Versions: 5.3.0
Reporter: Sudheer Vinukonda
Fix For: 6.0.0
There's a requirement to support expanding the cond expressions of headers
using header_rewrite plugin.
For example, one may want to concat to headers like the below:
{{set-header Vary '%{HEADER:Vary}, %{User-Agent}' }}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3629) TS corrupts Link: header in response
[
https://issues.apache.org/jira/browse/TS-3629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-3629:
---
Fix Version/s: (was: 6.0.0)
sometime
TS corrupts Link: header in response
Key: TS-3629
URL: https://issues.apache.org/jira/browse/TS-3629
Project: Traffic Server
Issue Type: Bug
Components: Plugins
Reporter: Felicity Tarnell
Assignee: Otto van der Schaaf
Fix For: sometime
(Using 5.3.0 on 64-bit Linux.)
We have an origin that links a {{Link}} header in its response. Requesting
the document directly from the origin (nginx) shows the correct header:
{noformat}
by-staging-1:~# curl -Ix localhost:81 http://plan-staging.torchboxapps.com/
HTTP/1.1 200 OK
Server: nginx
Date: Thu, 21 May 2015 10:04:54 GMT
Content-Type: text/html; charset=utf-8
Connection: keep-alive
Vary: Accept-Encoding
Expires: Sun, 19 Nov 1978 05:00:00 GMT
Cache-Control: no-cache, must-revalidate, post-check=0, pre-check=0
Content-Language: en
Link: http://plan-staging.torchboxapps.com/;
rel=canonical,http://plan-staging.torchboxapps.com/; rel=shortlink
{noformat}
However, requesting the same document from ATS, using the same origin,
truncates the header:
{noformat}
1 jobs exit 2 152!klamath:~/tbx/puppetcurl -I
https://plan-staging.torchboxapps.com/
HTTP/1.1 200 OK
Date: Thu, 21 May 2015 10:06:01 GMT
Content-Type: text/html; charset=utf-8
Vary: Accept-Encoding
Expires: Sun, 19 Nov 1978 05:00:00 GMT
Cache-Control: pre-check=0
Content-Language: en
Link: https://plan-staging.torchboxapps.com/; rel=shortlink
Content-Length: 0
Age: 0
Connection: keep-alive
Strict-Transport-Security: max-age=15552000
Via: http/1.1 by-staging-1 (uScMsSf pSeN:t cCMi pSs )
X-Cache: miss
{noformat}
(The reason for http vs. https is that ATS is terminating SSL, and the origin
uses http only.)
{{tcpdump}} shows that in the ATS request, the backend is sending the correct
header:
{noformat}
16:37:02.145579 IP 127.0.0.1.38756 127.0.0.1.81: Flags [P.], seq 1:376, ack
1, win 342, options [nop,nop,TS val 66617043 ecr 66617043], length 375
0x: 4500 01ab f8b6 4000 4006 4294 7f00 0001 E.@.@.B.
0x0010: 7f00 0001 9764 0051 170d 8668 cc19 17f9 .d.Q...h
0x0020: 8018 0156 ff9f 0101 080a 03f8 7ed3 ...V..~.
0x0030: 03f8 7ed3 4845 4144 2068 7474 703a 2f2f ..~.HEAD.http://
0x0040: 706c 616e 2d73 7461 6769 6e67 2e74 6f72 plan-staging.tor
0x0050: 6368 626f 7861 7070 732e 636f 6d2f 2048 chboxapps.com/.H
0x0060: 5454 502f 312e 310d 0a41 7574 686f 7269 TTP/1.1..Authori
0x0070: 7a61 7469 6f6e 3a20 4261 7369 6320 zation:.Basic...
0x0080:
0x0090: 0d0a xx..
0x00a0: 5573 6572 2d41 6765 6e74 3a20 6375 726c User-Agent:.curl
0x00b0: 2f37 2e34 312e 300d 0a48 6f73 743a 2070 /7.41.0..Host:.p
0x00c0: 6c61 6e2d 7374 6167 696e 672e 746f 7263 lan-staging.torc
0x00d0: 6862 6f78 6170 7073 2e63 6f6d 0d0a 4163 hboxapps.com..Ac
0x00e0: 6365 7074 3a20 2a2f 2a0d 0a58 2d46 6f72 cept:.*/*..X-For
0x00f0: 7761 7264 6564 2d50 726f 746f 3a20 6874 warded-Proto:.ht
0x0100: 7470 730d 0a43 6c69 656e 742d 6970 3a20 tps..Client-ip:.
0x0110: 3932 2e32 312e 3135 332e 360d 0a58 2d46 92.21.153.6..X-F
0x0120: 6f72 7761 7264 6564 2d46 6f72 3a20 3932 orwarded-For:.92
0x0130: 2e32 312e 3135 332e 360d 0a56 6961 3a20 .21.153.6..Via:.
0x0140: 6874 7470 732f 312e 3120 6279 2d73 7461 https/1.1.by-sta
0x0150: 6769 6e67 2d31 5b43 3145 3346 3436 365d ging-1[C1E3F466]
0x0160: 2028 4170 6163 6865 5472 6166 6669 6353 .(ApacheTrafficS
0x0170: 6572 7665 722f 352e 332e 3020 5b75 5363 erver/5.3.0.[uSc
0x0180: 4d73 2066 2070 2065 4e3a 7420 6343 4d69 Ms.f.p.eN:t.cCMi
0x0190: 2070 2073 205d 290d 0a50 6167 6553 7065 .p.s.])..PageSpe
0x01a0: 6564 3a20 6f66 660d 0a0d 0a ed:.off
16:37:02.145588 IP 127.0.0.1.81 127.0.0.1.38756: Flags [.], ack 376, win
350, options [nop,nop,TS val 66617043 ecr 66617043], length 0
0x: 4500 0034 692a 4000 4006 d397 7f00 0001 E..4i*@.@...
0x0010: 7f00 0001 0051 9764 cc19 17f9 170d 87df .Q.d
0x0020: 8010 015e fe28 0101 080a 03f8 7ed3 ...^.(~.
0x0030: 03f8 7ed3..~.
16:37:02.240195 IP 127.0.0.1.81 127.0.0.1.38756: Flags [P.], seq 1:413, ack
376, win 350, options [nop,nop,TS val 66617052 ecr 66617043], length 412
0x: 4500 01d0 692b 4000 4006 d1fa 7f00 0001
[jira] [Commented] (TS-3627) Count tx and rx bytes for WebSocket
[ https://issues.apache.org/jira/browse/TS-3627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14588241#comment-14588241 ] Phil Sorber commented on TS-3627: - [~briang]? Count tx and rx bytes for WebSocket --- Key: TS-3627 URL: https://issues.apache.org/jira/browse/TS-3627 Project: Traffic Server Issue Type: New Feature Components: Metrics Reporter: bettydramit Fix For: sometime How to count rx and tx per map websocket (ws and wss)? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3643) TS-2944 changes logging format / breaks compatibility
[ https://issues.apache.org/jira/browse/TS-3643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber updated TS-3643: Backport to Version: 5.3.1 TS-2944 changes logging format / breaks compatibility - Key: TS-3643 URL: https://issues.apache.org/jira/browse/TS-3643 Project: Traffic Server Issue Type: Bug Components: Configuration, Logging Affects Versions: 5.3.0 Reporter: David Carlin Fix For: 5.3.1 TS-2944 broke our log processing by changing cache result code from TCP_HIT to TCP_MEM_HIT for the majority of our responses. Additionally, TS-3036 is better. https://issues.apache.org/jira/browse/TS-3036?focusedCommentId=14561404page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14561404 Should TS-2944 be reverted since its redundant and breaks compatibility? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3648) Desire support for client TLS cipher in custom log format
[ https://issues.apache.org/jira/browse/TS-3648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-3648: --- Fix Version/s: (was: 6.0.0) sometime Desire support for client TLS cipher in custom log format - Key: TS-3648 URL: https://issues.apache.org/jira/browse/TS-3648 Project: Traffic Server Issue Type: New Feature Components: Logging Reporter: Eric Sproul Fix For: 6.1.0 While the TLS cipher stats from TS-2169 are awesome for seeing what ciphers are in active use, I would also like to be able to create a custom log to track cipher by client request. That would enable me, for example, to determine who among my users might be affected by a cipher list change. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3648) Desire support for client TLS cipher in custom log format
[ https://issues.apache.org/jira/browse/TS-3648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-3648: --- Fix Version/s: (was: sometime) 6.1.0 Desire support for client TLS cipher in custom log format - Key: TS-3648 URL: https://issues.apache.org/jira/browse/TS-3648 Project: Traffic Server Issue Type: New Feature Components: Logging Reporter: Eric Sproul Assignee: Eric Schwartz Fix For: 6.1.0 While the TLS cipher stats from TS-2169 are awesome for seeing what ciphers are in active use, I would also like to be able to create a custom log to track cipher by client request. That would enable me, for example, to determine who among my users might be affected by a cipher list change. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3681) Promote TSHrtime APIs to ts.h /apidefs.h
[ https://issues.apache.org/jira/browse/TS-3681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber updated TS-3681: Labels: compatibility (was: ) Promote TSHrtime APIs to ts.h /apidefs.h Key: TS-3681 URL: https://issues.apache.org/jira/browse/TS-3681 Project: Traffic Server Issue Type: Improvement Components: TS API Reporter: Leif Hedstrom Assignee: Leif Hedstrom Labels: compatibility Fix For: 6.0.0 Time to move these from experimental to ts/ts.h / apidefs.h -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3694) Fix function documentation to Log::error
[
https://issues.apache.org/jira/browse/TS-3694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-3694:
---
Assignee: Daniel Xu (was: Bryan Call)
Fix function documentation to Log::error
Key: TS-3694
URL: https://issues.apache.org/jira/browse/TS-3694
Project: Traffic Server
Issue Type: Improvement
Components: Logging
Reporter: Daniel Xu
Assignee: Daniel Xu
Fix For: Docs
The description for this function seems to be out of date. The note directly
contradicts what the function actually does.
{code:title=Log.cc|borderStyle=solid}
/*-
Log::error
Make an entry into the current error log. For convenience, it is given in
both variable argument (format, ...) and stdarg (format, va_list) forms.
Note that Log::error could call Log::va_error after calling va_start
so that va_error handles the statistics update. However, to make
Log::error slightly more efficient this is not the case. The
downside is that one has to be careful to update both functions if
need be.
-*/
int
Log::error(const char *format, ...)
{
va_list ap;
int ret;
va_start(ap, format);
ret = Log::va_error(format, ap);
va_end(ap);
return ret;
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (TS-3694) Fix function documentation to Log::error
[
https://issues.apache.org/jira/browse/TS-3694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call reassigned TS-3694:
--
Assignee: Bryan Call
Fix function documentation to Log::error
Key: TS-3694
URL: https://issues.apache.org/jira/browse/TS-3694
Project: Traffic Server
Issue Type: Improvement
Components: Logging
Reporter: Daniel Xu
Assignee: Bryan Call
Fix For: Docs
The description for this function seems to be out of date. The note directly
contradicts what the function actually does.
{code:title=Log.cc|borderStyle=solid}
/*-
Log::error
Make an entry into the current error log. For convenience, it is given in
both variable argument (format, ...) and stdarg (format, va_list) forms.
Note that Log::error could call Log::va_error after calling va_start
so that va_error handles the statistics update. However, to make
Log::error slightly more efficient this is not the case. The
downside is that one has to be careful to update both functions if
need be.
-*/
int
Log::error(const char *format, ...)
{
va_list ap;
int ret;
va_start(ap, format);
ret = Log::va_error(format, ap);
va_end(ap);
return ret;
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (TS-1985) Eliminate built-in log formats in favor of logs_xml.config
[ https://issues.apache.org/jira/browse/TS-1985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber reassigned TS-1985: --- Assignee: Phil Sorber (was: Crystal Qian) Eliminate built-in log formats in favor of logs_xml.config -- Key: TS-1985 URL: https://issues.apache.org/jira/browse/TS-1985 Project: Traffic Server Issue Type: Improvement Components: Logging Reporter: Leif Hedstrom Assignee: Phil Sorber Labels: incompatible, newbie Fix For: 6.0.0 I have a feeling that the hardcoded (built-in) log-formats was the old way of doing things, and logs_xml.config is the new way. As such, I'd like to propose that we eliminate all the built-in's, and provide all those formats in a default logs_xml.config. One thing that might be necessary to add is an option in the XML config to disable a log file. I don't know if that's easily doable without using XML comments, but would be easy to add and useful. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3642) proxy.config.http.share_server_sessions not working
[ https://issues.apache.org/jira/browse/TS-3642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14588337#comment-14588337 ] Eric Sproul commented on TS-3642: - We are still seeing higher-than-expected origin connection counts with 5.3.0. We currently have explicitly set: * CONFIG proxy.config.http.share_server_sessions INT 1 * CONFIG proxy.config.http.server_session_sharing.pool STRING global proxy.config.http.share_server_sessions not working --- Key: TS-3642 URL: https://issues.apache.org/jira/browse/TS-3642 Project: Traffic Server Issue Type: Bug Components: Configuration Affects Versions: 5.3.0 Reporter: David Carlin Assignee: Alan M. Carroll Fix For: 6.0.0 Testing 5.3.0 and I noticed proxy.config.http.share_server_sessions = 1 no longer works. Saw a 10-15x increase in origin connections; there appears to be some reuse, I am seeing approximately 1.2-1.3 requests per origin connection. Setting proxy.config.http.server_session_sharing.pool = global restored expected behavior (Thanks [~sudheerv]!) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3136) Change default TLS cipher suites
[
https://issues.apache.org/jira/browse/TS-3136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14588193#comment-14588193
]
Thomas Jackson commented on TS-3136:
Nothing noticable-- but TBH both of these are really low in the list of ciphers
we actually see. If we want specific numbers I'd have to wait until I get into
the office. From my perspective RC4 is broken, 3DES is slow. Slow broken :)
Change default TLS cipher suites
Key: TS-3136
URL: https://issues.apache.org/jira/browse/TS-3136
Project: Traffic Server
Issue Type: Improvement
Components: Security, SSL
Reporter: Leif Hedstrom
Assignee: Susan Hinrichs
Labels: compatibility
Fix For: 6.0.0
In TS-3135 [~i.galic] suggested:
{quote}
also, recommendations for a safer ciphersuite:
SSLCipherSuite
ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4
from https://cipherli.st/
{quote}
[~jacksontj] had responded with:
{quote}
[~i.galic] That cipher quite is geared towards security, but doesn't support
quite a few older clients. I'd recommend we use the suite from mozilla
(https://wiki.mozilla.org/Security/Server_Side_TLS#Recommended_Server_Configurations)
which is a good mix of security and compatibility:
{code}
ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA
{code}
{quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3571) Should we optimize (defer) the cqu / cquc stringification on logging?
[ https://issues.apache.org/jira/browse/TS-3571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-3571: --- Fix Version/s: (was: 6.0.0) 6.1.0 Should we optimize (defer) the cqu / cquc stringification on logging? - Key: TS-3571 URL: https://issues.apache.org/jira/browse/TS-3571 Project: Traffic Server Issue Type: Improvement Components: Logging Reporter: Leif Hedstrom Labels: newbie Fix For: 6.1.0 Today, we always calculate the strings for cqu and cquc, regardless if they are used or not. This is not optimal, since it's not unusual to use e.g. cquuc instead. In most places where we allow logging URL strings, we also have a way to defer the stringification until we actually need to marshal the URL. My suggestion is that we do this deferred string creation for cqu and cquuc as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3599) Multiple dest_ip=* directives has unpredictable behavior in ssl_multicert.config
[
https://issues.apache.org/jira/browse/TS-3599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-3599:
---
Fix Version/s: (was: 6.0.0)
6.1.0
Multiple dest_ip=* directives has unpredictable behavior in
ssl_multicert.config
Key: TS-3599
URL: https://issues.apache.org/jira/browse/TS-3599
Project: Traffic Server
Issue Type: Bug
Components: SSL
Reporter: Leif Hedstrom
Fix For: 6.1.0
If I create an ssl_multicert.config with e.g.
{code}
dest_ip=* ssl_key_name=foo.key ssl_cert_name=foo.crt
dest_ip=* ssl_key_name=bar.key ssl_cert_name=bar.crt
{code}
Then even with an SNI enabled client, which uses SNI in the TLS handshake,
ATS seems to arbitrarily pick a cert. This seems nonsensical, I get the
impression that dest_ip=anything would only take effect if there is no SNI
in the handshake?
I understand that more than one dest_ip=* is perhaps not a valid
configuration, but in that case we ought to either error out (fail to start),
or at least produce a really loud warning. Clearly making it fail like this
seems unreasonable :).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3612) Restructure Proxy Client Sessions to support transaction oriented Sessions execute transaction hooks and connection oriented Sessions execute session hooks
[ https://issues.apache.org/jira/browse/TS-3612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-3612: --- Fix Version/s: (was: 6.0.0) 6.1.0 Restructure Proxy Client Sessions to support transaction oriented Sessions execute transaction hooks and connection oriented Sessions execute session hooks --- Key: TS-3612 URL: https://issues.apache.org/jira/browse/TS-3612 Project: Traffic Server Issue Type: Improvement Components: HTTP, HTTP/2, SPDY Reporter: Susan Hinrichs Fix For: 6.1.0 In the current code, transaction and session hooks don't have access to H2 and SPDY session data. This was partially addressed by TS-3578. There was a discussion on the mailing list, and the consensus was that session hooks should be invoked on session-oriented sessions (H2, SPDY, and native HTTP/1.x) and transaction hooks should be invoked on transaction-oriented sessions. http://dev.trafficserver.apache.narkive.com/OX9XK0xn/spdy-h2-and-session-hooks -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3614) ats_pagespeed make fatal error: ts/ts.h
[ https://issues.apache.org/jira/browse/TS-3614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-3614: --- Fix Version/s: (was: 6.0.0) sometime ats_pagespeed make fatal error: ts/ts.h - Key: TS-3614 URL: https://issues.apache.org/jira/browse/TS-3614 Project: Traffic Server Issue Type: Bug Components: Configuration Reporter: Sebastian Pesman Assignee: Otto van der Schaaf Fix For: sometime When running the MAKE command on a git clone of ATS it fails to MAKE the plugin. It's not clear to me which ts.h file it needs. OS: Centos 7 Git: https://git-wip-us.apache.org/repos/asf/trafficserver.git Branch: Master /tmp/trafficserver/plugins/experimental/ats_pagespeed make Errors: In file included from ats_base_fetch.cc:24:0: ats_base_fetch.h:29:19: fatal error: ts/ts.h: No such file or directory #include ts/ts.h ^ compilation terminated. In file included from ats_beacon_intercept.cc:24:0: ats_beacon_intercept.h:27:19: fatal error: ts/ts.h: No such file or directory #include ts/ts.h ^ compilation terminated. In file included from ats_config.cc:24:0: ats_config.h:30:19: fatal error: ts/ts.h: No such file or directory #include ts/ts.h ^ compilation terminated. In file included from ats_header_utils.cc:24:0: ats_header_utils.h:29:19: fatal error: ts/ts.h: No such file or directory #include ts/ts.h ^ compilation terminated. ats_log_message_handler.cc:26:19: fatal error: ts/ts.h: No such file or directory #include ts/ts.h ^ compilation terminated. In file included from ats_message_handler.cc:24:0: ats_message_handler.h:27:19: fatal error: ts/ts.h: No such file or directory #include ts/ts.h ^ compilation terminated. ats_pagespeed.cc:33:19: fatal error: ts/ts.h: No such file or directory #include ts/ts.h ^ compilation terminated. In file included from ats_process_context.cc:30:0: ats_message_handler.h:27:19: fatal error: ts/ts.h: No such file or directory #include ts/ts.h ^ compilation terminated. ats_resource_intercept.cc:24:19: fatal error: ts/ts.h: No such file or directory #include ts/ts.h ^ compilation terminated. In file included from ats_rewrite_driver_factory.cc:29:0: ats_thread_system.h:29:19: fatal error: ts/ts.h: No such file or directory #include ts/ts.h ^ compilation terminated. In file included from ats_rewrite_options.cc:35:0: ats_message_handler.h:27:19: fatal error: ts/ts.h: No such file or directory #include ts/ts.h ^ compilation terminated. make: *** [ats_pagespeed.so] Error 1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3636) Parent Proxy Forward mode ts-full
[ https://issues.apache.org/jira/browse/TS-3636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-3636: --- Fix Version/s: (was: 6.0.0) 6.1.0 Parent Proxy Forward mode ts-full - Key: TS-3636 URL: https://issues.apache.org/jira/browse/TS-3636 Project: Traffic Server Issue Type: Bug Components: Parent Proxy, TProxy Reporter: Faysal Banna Assignee: Alan M. Carroll Fix For: 6.1.0 Hello Guys. today i stumbled upon an issue with parent proxy, and let me describe what is going on. i have my cache working in forward proxy mode tr-full proxy.config.reverse_proxy.enabled 0 proxy.config.url_remap.remap_required 0 proxy.config.http.server_ports 8080:tr-full:tr-pass 8099 and in parent.config i have url_regex=.*distrowatch parent=77.75.92.61:8080 now if i do export http_proxy=127.0.0.1:8099 wget 'http://distrowatch.com' --delete-after i can see that the request was proxied to the parent cache in squid.log as shown below: 1432569647.049 823 127.0.0.1 TCP_REFRESH_MISS/200 157668 GET http://distrowatch.com/ - PARENT_HIT/77.75.92.61 text/html yet if i go as a client forwarded to the server from my laptop i issue wget --delete-after 'http://distrowatch.com' i get in squid.log 1432570157.718 62805 77.75.88.82 TCP_REFRESH_MISS/200 157598 GET http://distrowatch.com/ - DIRECT/distrowatch.com text/html i checked tcpdump on the interface between both caches and i had a result that ATS was sending parent proxies with origin ip addresses same as the client ip addresses . so i did a source-nat (SNAT) via iptables firewall on the interface itself and originated traffic as if originated from ATS itself in diags.log i could always see http parent proxy 77.75.92.61:8080 marked down in my believe parent proxy should not get client address unless asked for. since it should always reply to the ATS server so it should get ATS ip address and not client ip address regardless of being TProxied or not. unless someone can create some variable to enable disable such feature when contacting parent proxies. Regards -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3645) After TS-3033, some traffic_line commands result in requested command failed
[
https://issues.apache.org/jira/browse/TS-3645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-3645:
---
Fix Version/s: (was: 6.1.0)
6.0.0
After TS-3033, some traffic_line commands result in requested command failed
--
Key: TS-3645
URL: https://issues.apache.org/jira/browse/TS-3645
Project: Traffic Server
Issue Type: Bug
Components: Management API
Affects Versions: 5.3.0, 6.0.0
Environment: RHEL 6.x, CentOS 6.x (on x86_64)
Reporter: Dimitry Andric
Fix For: 6.0.0
I recently upgraded from trafficserver 4.x to 5.3.0, and one thing that I
noticed was that certain traffic_line commands started printing requested
command failed. For example:
{noformat}
# trafficserver start
Starting Apache Traffic Server:[ OK ]
# traffic_line --status
Proxy -- on
# traffic_line --shutdown
error: the requested command failed: [11] Invalid parameters passed into
function call.
# traffic_line --startup
error: the requested command failed: [11] Invalid parameters passed into
function call.
{noformat}
Interestingly, even if the --shutdown command gives such an error message,
the diags.log file still shows that the server has shut down:
{noformat}
[May 28 22:03:03.539] Server {0x2abe4251d700} NOTE:
[ProcessManager::processEventQueue] Shutdown msg received, exiting
{noformat}
and the --status command also finds the same:
{noformat}
# traffic_line --status
Proxy -- off
{noformat}
Similar for the --startup command: though it gives the same error message,
the command seems to have actually worked.
I did some bisecting to find where this was introduced, and ended up at
[commit
355c165|https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;a=commit;h=355c165]
(TS-3033: fix PROXY_STATE_GET). Before this particular commit, both
{{traffic_line --shutdown}} and {{traffic_line --startup}} work without
printing any error; after the commit, they both start printing requested
command failed.
If I look at all the work done in TS-3033, and the particular change in
[commit
355c165|https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;a=commit;h=355c165],
I would guess that some parts of the code are disagreeing about the number
of parameters for the PROXY_STATE_GET message.
Alternatively, there may be some sort of issue in the management API and/or
marshalling code, where a PROXY_STATE_GET message with two parameters gets
cut off in some way, possibly because the server is just shutting down at
that point?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3672) API allowing plugins to setup blind tunnel in case of oddities in the client request.
[ https://issues.apache.org/jira/browse/TS-3672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-3672: --- Fix Version/s: (was: 6.0.0) sometime API allowing plugins to setup blind tunnel in case of oddities in the client request. - Key: TS-3672 URL: https://issues.apache.org/jira/browse/TS-3672 Project: Traffic Server Issue Type: New Feature Components: Core, TS API Reporter: Pavel Vazharov Fix For: sometime Hi all, This is not a complete feature request. It's more like couple of questions which can lead to a feature request. We experience several problems (see below) in our installations with ATS. I think that all of them can be handled outside the core if there is an API function which can request 'go to blind tunnel'. I have the following questions related to these cases: 1. Do you think such an API would be useful and should it be added to the core? 2. Do you think that it should 'cover' only the TS_HTTP_READ_REQUEST_HDR_HOOK? (Skip the question if the answer of the above question is NO :)). I mean, there is not much sense (IMHO) the new API to be called in some states, but probably there are other states where it could be useful, such as TS_HTTP_READ_RESPONSE_HDR_HOOK (if the response is broken to get tunneled). On the other hand, creating a blind tunnel on the latter states could be really hard, or nearly impossible, because of the state machine internals. I'm aware of the TSVConnTunnel which works only for SSL connections and can be called only in the first 2-3 states (hooks). 3. I looked at the code and have some idea how such and API can be added in order to be used in TS_HTTP_READ_REQUEST_HDR_HOOK. I tested the change locally. I'm ready to contribute code to the core, if you guys decide that it's ok. I'm also open for discussion. It would be easier for our organization too, if we don't need to patch explicitly. (Skip the question if the answer of the 1st question is NO :)). Here are the problems that we experience, and which I think could be 'fixed' by such an API. 1. The ATS redirects requests from port 80 starting with 'https://' through port 443. Here is one real request from an online trading software: GET https://pda.angelbolt.in/downloads/PDA%20DOWNLOADS/OdinClient/Files/Reg/Win32/EAST-Internet-48.reg HTTP/1.0 Accept: *.*, */* User-Agent: Elucid Software Downloader Referer: pda.angelbolt.in This is a problem for us, because our installations are running in PBR mode and only port 80 gets diverted. The response to the request from port 443 never goes back to the transparent proxy box. We don't control the PBR devices. In addition, diverting the port 443 is not really feasible for us in big scale, because it'll increase the processed traffic with gigabits, just to serve such edge cases. 2. We've seen such disqus API requests which cause problems for the ATS. GET http://some.private.ip/something HTTP/1.1 Host: api-whatever.disqus.com The host field and the host specified in the get path do not match. The ATS can't reach the private API in question. Usually clients have a pretty good reason for sending full, instead of relative URL. 3. It seems that the ATS tries to serve locally proxy related methods, such as CONNECT, DELETE, PURGE, even when running in transparent mode. I think we can handle all of the above cases (and probably more oddities) via a plugin which will request 'go to blind tunnel mode' if it detects something in the client request. The third point could be solved by extending the ip allow rules to have a tunnel action, as well. However, I would like the discussion here to be about the blind tunnel API, unless you think there is a smarter solution for all of the above cases. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3683) Add a tag to log SSL Session/Ticket HIT as well as TCP connection reused
[ https://issues.apache.org/jira/browse/TS-3683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-3683: --- Fix Version/s: (was: 6.0.0) 6.1.0 Add a tag to log SSL Session/Ticket HIT as well as TCP connection reused Key: TS-3683 URL: https://issues.apache.org/jira/browse/TS-3683 Project: Traffic Server Issue Type: Improvement Components: Logging Reporter: François Pesce Fix For: 6.1.0 These tags would be useful for performance metrics collection: %cqtr The TCP reused status; indicates if this request went through an already established connection. %cqssr The SSL session/ticket reused status; indicates if this request hit the SSL session/ticket and avoided a full SSL handshake. both of them would display respectively 0 or 1 , if resp. not reused or reused. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3683) Add a tag to log SSL Session/Ticket HIT as well as TCP connection reused
[ https://issues.apache.org/jira/browse/TS-3683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-3683: --- Assignee: Alan M. Carroll Add a tag to log SSL Session/Ticket HIT as well as TCP connection reused Key: TS-3683 URL: https://issues.apache.org/jira/browse/TS-3683 Project: Traffic Server Issue Type: Improvement Components: Logging Reporter: François Pesce Assignee: Alan M. Carroll Fix For: 6.1.0 These tags would be useful for performance metrics collection: %cqtr The TCP reused status; indicates if this request went through an already established connection. %cqssr The SSL session/ticket reused status; indicates if this request hit the SSL session/ticket and avoided a full SSL handshake. both of them would display respectively 0 or 1 , if resp. not reused or reused. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3136) Change default TLS cipher suites
[
https://issues.apache.org/jira/browse/TS-3136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14588162#comment-14588162
]
Thomas Jackson commented on TS-3136:
[~shinrich] In our testing/experience you can drop RC4 and as long as you
support 3DES clients will move to that. Granted 3DES isn't super secure, but
its not as broken as RC4 :)
Change default TLS cipher suites
Key: TS-3136
URL: https://issues.apache.org/jira/browse/TS-3136
Project: Traffic Server
Issue Type: Improvement
Components: Security, SSL
Reporter: Leif Hedstrom
Assignee: Susan Hinrichs
Labels: compatibility
Fix For: 6.0.0
In TS-3135 [~i.galic] suggested:
{quote}
also, recommendations for a safer ciphersuite:
SSLCipherSuite
ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4
from https://cipherli.st/
{quote}
[~jacksontj] had responded with:
{quote}
[~i.galic] That cipher quite is geared towards security, but doesn't support
quite a few older clients. I'd recommend we use the suite from mozilla
(https://wiki.mozilla.org/Security/Server_Side_TLS#Recommended_Server_Configurations)
which is a good mix of security and compatibility:
{code}
ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA
{code}
{quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3559) ATS should support client side TLS session ticket caching/use.
[ https://issues.apache.org/jira/browse/TS-3559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-3559: --- Fix Version/s: (was: 6.0.0) 6.1.0 ATS should support client side TLS session ticket caching/use. -- Key: TS-3559 URL: https://issues.apache.org/jira/browse/TS-3559 Project: Traffic Server Issue Type: Improvement Components: Security, SSL Reporter: Dave Thompson Assignee: Dave Thompson Fix For: 6.1.0 For TLS connections between ATS and origin server, ATS should support caching of session ticket and associated master secret, etc, for later abbreviated handshake TLS resumption to origin server, reduced round trip, and overall performance improvement. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3593) Segmentation fault.
[
https://issues.apache.org/jira/browse/TS-3593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-3593:
---
Fix Version/s: (was: 6.0.0)
6.1.0
Segmentation fault.
---
Key: TS-3593
URL: https://issues.apache.org/jira/browse/TS-3593
Project: Traffic Server
Issue Type: Bug
Components: Core
Affects Versions: 6.0.0
Reporter: bettydramit
Labels: crash
Fix For: 6.1.0
Master version from git
Build configure
{code}
./configure --enable-layout=Gentoo --libdir=%{_libdir}/trafficserver
--enable-spdy --enable-reclaimable-freelist --enable-interim-cache --
enable-hwloc --with-openssl=/usr/local/ssl
{code}
{code}
Core was generated by `/usr/bin/traffic_server -M --httpport
80:fd=7,443:fd=8:ssl'.
Program terminated with signal 11, Segmentation fault.
#0 HttpTunnel::chain_abort_all (this=0x2abcdc7014a8, p=0x2abcdc7016a0) at
HttpTunnel.cc:1403
1403p-bytes_read = p-read_vio-ndone;
Missing separate debuginfos, use: debuginfo-install
glibc-2.12-1.132.el6_5.2.x86_64 hwloc-1.5-1.el6.x86_64
libattr-2.4.44-7.el6.x86_64 libcap-2.16-5.5.el6.x86_64
libgcc-4.4.7-4.el6.x86_64 libstdc++-4.4.7-4.el6.x86_64
libxml2-2.7.6-14.el6_5.2.x86_64 nss-softokn-freebl-3.14.3-10.el6_5.x86_64
numactl-2.0.7-8.el6.x86_64 pciutils-libs-3.1.10-2.el6.x86_64
pcre-7.8-6.el6.x86_64 spdylay-1.2.5-1.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-29.el6.x86_64
(gdb) bt
#0 HttpTunnel::chain_abort_all (this=0x2abcdc7014a8, p=0x2abcdc7016a0) at
HttpTunnel.cc:1403
#1 0x006099c4 in HttpTunnel::kill_tunnel (this=0x2abcdc7014a8) at
HttpTunnel.cc:524
#2 0x005ce6fa in HttpSM::kill_this (this=0x2abcdc70) at
HttpSM.cc:6568
#3 0x005cef38 in HttpSM::main_handler (this=0x2abcdc70,
event=105, data=0x2abcdc560118) at HttpSM.cc:2623
#4 0x0075ba09 in handleEvent (event=value optimized out,
vc=0x2abcdc56) at ../../iocore/eventsystem/I_Continuation.h:145
#5 read_signal_and_update (event=value optimized out, vc=0x2abcdc56)
at UnixNetVConnection.cc:139
#6 0x0075ddbf in UnixNetVConnection::mainEvent (this=0x2abcdc56,
event=value optimized out, e=value optimized out)
at UnixNetVConnection.cc:1094
#7 0x00755041 in handleEvent (this=0x1db34e0, event=value optimized
out, e=0x2abc6fa8ed20)
at ../../iocore/eventsystem/I_Continuation.h:145
#8 InactivityCop::check_inactivity (this=0x1db34e0, event=value optimized
out, e=0x2abc6fa8ed20) at UnixNet.cc:107
#9 0x0077f435 in handleEvent (this=0x2abc6e470010, e=0x2abc6fa8ed20,
calling_code=2) at I_Continuation.h:145
#10 EThread::process_event (this=0x2abc6e470010, e=0x2abc6fa8ed20,
calling_code=2) at UnixEThread.cc:128
#11 0x0077fd13 in EThread::execute (this=0x2abc6e470010) at
UnixEThread.cc:207
#12 0x0077e87a in spawn_thread_internal (a=0x1daa260) at Thread.cc:85
#13 0x2abc6b6639d1 in start_thread () from /lib64/libpthread.so.0
#14 0x2abc6d302b5d in clone () from /lib64/libc.so.6
(gdb) f 0
#0 HttpTunnel::chain_abort_all (this=0x2abcdc7014a8, p=0x2abcdc7016a0) at
HttpTunnel.cc:1403
1403p-bytes_read = p-read_vio-ndone;
(gdb) l
1398c = c-link.next;
1399 }
1400
1401 if (p-alive) {
1402p-alive = false;
1403p-bytes_read = p-read_vio-ndone;
1404if (p-self_consumer) {
1405 p-self_consumer-alive = false;
1406}
1407p-read_vio = NULL;
(gdb) p p
$1 = (HttpTunnelProducer *) 0x2abcdc7016a0
(gdb) p *p
$2 = {consumer_list = {head = 0x2abcdc7014e0}, self_consumer = 0x0, vc =
0x2abcdc848000, vc_handler = (int (HttpSM::*)(HttpSM *, int,
HttpTunnelProducer *)) 0x5ba7a0 HttpSM::tunnel_handler_server(int,
HttpTunnelProducer*), read_vio = 0x0,
read_buffer = 0x2abcdc57bde0, buffer_start = 0x2abcdc57bdf8, vc_type =
HT_HTTP_SERVER, chunked_handler = {
static DEFAULT_MAX_CHUNK_SIZE = 4096, action =
ChunkedHandler::ACTION_DOCHUNK, chunked_reader = 0x0, dechunked_buffer = 0x0,
dechunked_size = 0, dechunked_reader = 0x0, chunked_buffer = 0x0,
chunked_size = 0, truncation = false, skip_bytes = 132,
state = ChunkedHandler::CHUNK_READ_CHUNK, cur_chunk_size = 0, bytes_left
= 0, last_server_event = 0, running_sum = 0, num_digits = 0,
max_chunk_size = 4096, max_chunk_header =
1000\r\n\000\000\000\000\000\000\000\000\000, max_chunk_header_len = 6},
chunking_action = TCA_PASSTHRU_DECHUNKED_CONTENT, do_chunking = false,
do_dechunking = false, do_chunked_passthru = false,
init_bytes_done = 348, nbytes = -1, ntodo = -1, bytes_read = 0,
handler_state = 0, last_event = 0, num_consumers = 1, alive = false,
read_success = false, flow_control_source = 0x0, name =
[jira] [Updated] (TS-3596) TSHttpTxnPluginTagGet() returns fetchSM over H2
[ https://issues.apache.org/jira/browse/TS-3596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-3596: --- Fix Version/s: (was: 6.0.0) 6.1.0 TSHttpTxnPluginTagGet() returns fetchSM over H2 - Key: TS-3596 URL: https://issues.apache.org/jira/browse/TS-3596 Project: Traffic Server Issue Type: Bug Components: HTTP/2 Reporter: Scott Beardsley Fix For: 6.1.0 This should probably return something else, right? Maybe HTTP2 instead? We would like a way to identify H2 requests from SPDY and/or H1. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3625) Some statistics not being gathered
[ https://issues.apache.org/jira/browse/TS-3625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-3625: --- Fix Version/s: (was: 6.1.0) 7.0.0 Some statistics not being gathered -- Key: TS-3625 URL: https://issues.apache.org/jira/browse/TS-3625 Project: Traffic Server Issue Type: Bug Components: Metrics Reporter: Jon Sime Labels: compatibility Fix For: 7.0.0 The following statistics appear to not have any data collected for them in recent versions of TS, instead only emitting a zero value. The list was put together by examining the stats_over_http output on a production instance which receives enough varied traffic that it should, in theory at least, cause most implemented statistics to go non-zero. proxy.node.cache.contents.num_docs proxy.node.cache_hit_mem_ratio_avg_10s_int_pct proxy.node.cache_hit_mem_ratio_int_pct proxy.node.current_cache_connections proxy.node.dns.lookup_avg_time_ms proxy.node.dns.lookups_per_second proxy.node.dns.total_dns_lookups proxy.node.http.transaction_frac_avg_10s.errors.aborts_int_pct proxy.node.http.transaction_frac_avg_10s.errors.connect_failed_int_pct proxy.node.http.transaction_frac_avg_10s.errors.early_hangups_int_pct proxy.node.http.transaction_frac_avg_10s.errors.empty_hangups_int_pct proxy.node.http.transaction_frac_avg_10s.errors.other_int_pct proxy.node.http.transaction_frac_avg_10s.errors.possible_aborts_int_pct proxy.node.http.transaction_frac_avg_10s.errors.pre_accept_hangups_int_pct proxy.node.http.transaction_frac_avg_10s.hit_fresh_int_pct proxy.node.http.transaction_frac_avg_10s.hit_revalidated_int_pct proxy.node.http.transaction_frac_avg_10s.miss_changed_int_pct proxy.node.http.transaction_frac_avg_10s.miss_client_no_cache_int_pct proxy.node.http.transaction_frac_avg_10s.miss_cold_int_pct proxy.node.http.transaction_frac_avg_10s.miss_not_cacheable_int_pct proxy.node.http.transaction_frac_avg_10s.other.unclassified_int_pct proxy.node.log.bytes_flush_to_disk proxy.node.log.bytes_lost_before_flush_to_disk proxy.node.log.bytes_lost_before_preproc proxy.node.log.bytes_lost_before_sent_to_network proxy.node.log.bytes_lost_before_written_to_disk proxy.node.log.bytes_received_from_network proxy.node.log.bytes_received_from_network_avg_10s proxy.node.log.bytes_sent_to_network proxy.node.log.bytes_sent_to_network_avg_10s proxy.node.log.bytes_written_to_disk proxy.node.log.event_log_access_aggr proxy.node.log.event_log_access_fail proxy.node.log.event_log_access_full proxy.node.log.event_log_access_ok proxy.node.log.event_log_access_skip proxy.node.log.event_log_error_aggr proxy.node.log.event_log_error_fail proxy.node.log.event_log_error_full proxy.node.log.event_log_error_ok proxy.node.log.event_log_error_skip proxy.node.log.num_flush_to_disk proxy.node.log.num_lost_before_flush_to_disk proxy.node.log.num_lost_before_sent_to_network proxy.node.log.num_received_from_network proxy.node.log.num_sent_to_network proxy.process.cache.directory_collision proxy.process.cache.evacuate.active proxy.process.cache.evacuate.failure proxy.process.cache.evacuate.success proxy.process.cache.frags_per_doc.1 proxy.process.cache.frags_per_doc.2 proxy.process.cache.frags_per_doc.3+ proxy.process.cache.gc_bytes_evacuated proxy.process.cache.gc_frags_evacuated proxy.process.cache.hdr_marshal_bytes proxy.process.cache.hdr_marshals proxy.process.cache.lookup.active proxy.process.cache.lookup.failure proxy.process.cache.lookup.success proxy.process.cache.percent_full proxy.process.cache.pread_count proxy.process.cache.read_busy.failure proxy.process.cache.read_busy.success proxy.process.cache.remove.active proxy.process.cache.remove.failure proxy.process.cache.remove.success proxy.process.cache.scan.active proxy.process.cache.scan.failure proxy.process.cache.scan.success proxy.process.cache.volume_0.directory_collision proxy.process.cache.volume_0.evacuate.active proxy.process.cache.volume_0.evacuate.failure proxy.process.cache.volume_0.evacuate.success proxy.process.cache.volume_0.frags_per_doc.1 proxy.process.cache.volume_0.frags_per_doc.2 proxy.process.cache.volume_0.frags_per_doc.3+ proxy.process.cache.volume_0.gc_bytes_evacuated proxy.process.cache.volume_0.gc_frags_evacuated proxy.process.cache.volume_0.hdr_marshal_bytes proxy.process.cache.volume_0.hdr_marshals proxy.process.cache.volume_0.lookup.active proxy.process.cache.volume_0.lookup.failure proxy.process.cache.volume_0.lookup.success proxy.process.cache.volume_0.pread_count proxy.process.cache.volume_0.remove.active proxy.process.cache.volume_0.remove.failure proxy.process.cache.volume_0.remove.success proxy.process.cache.volume_0.scan.active proxy.process.cache.volume_0.scan.failure
[jira] [Updated] (TS-3641) Drupal Auth does not seem to work with HTTP/2
[ https://issues.apache.org/jira/browse/TS-3641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-3641: --- Assignee: Leif Hedstrom (was: Susan Hinrichs) Drupal Auth does not seem to work with HTTP/2 - Key: TS-3641 URL: https://issues.apache.org/jira/browse/TS-3641 Project: Traffic Server Issue Type: Bug Components: HTTP/2 Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 6.0.0 Using latest chrome, when authenticating to a Drupal site behind ATS, it fails to authenticate. It silently seems to just ignore the auth, and moves along unauthenticated. It's possible this is similar to TS-3640, but the fix from that Jira does not resolve the HTTP/2 issues. In fact, this problem exists all the way back to 5.3.0, so the fix here would also be a back port for 5.3.1 (or 5.3.2). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3645) After TS-3033, some traffic_line commands result in requested command failed
[
https://issues.apache.org/jira/browse/TS-3645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-3645:
---
Fix Version/s: (was: 6.0.0)
6.1.0
After TS-3033, some traffic_line commands result in requested command failed
--
Key: TS-3645
URL: https://issues.apache.org/jira/browse/TS-3645
Project: Traffic Server
Issue Type: Bug
Components: Management API
Affects Versions: 5.3.0, 6.0.0
Environment: RHEL 6.x, CentOS 6.x (on x86_64)
Reporter: Dimitry Andric
Fix For: 6.1.0
I recently upgraded from trafficserver 4.x to 5.3.0, and one thing that I
noticed was that certain traffic_line commands started printing requested
command failed. For example:
{noformat}
# trafficserver start
Starting Apache Traffic Server:[ OK ]
# traffic_line --status
Proxy -- on
# traffic_line --shutdown
error: the requested command failed: [11] Invalid parameters passed into
function call.
# traffic_line --startup
error: the requested command failed: [11] Invalid parameters passed into
function call.
{noformat}
Interestingly, even if the --shutdown command gives such an error message,
the diags.log file still shows that the server has shut down:
{noformat}
[May 28 22:03:03.539] Server {0x2abe4251d700} NOTE:
[ProcessManager::processEventQueue] Shutdown msg received, exiting
{noformat}
and the --status command also finds the same:
{noformat}
# traffic_line --status
Proxy -- off
{noformat}
Similar for the --startup command: though it gives the same error message,
the command seems to have actually worked.
I did some bisecting to find where this was introduced, and ended up at
[commit
355c165|https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;a=commit;h=355c165]
(TS-3033: fix PROXY_STATE_GET). Before this particular commit, both
{{traffic_line --shutdown}} and {{traffic_line --startup}} work without
printing any error; after the commit, they both start printing requested
command failed.
If I look at all the work done in TS-3033, and the particular change in
[commit
355c165|https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;a=commit;h=355c165],
I would guess that some parts of the code are disagreeing about the number
of parameters for the PROXY_STATE_GET message.
Alternatively, there may be some sort of issue in the management API and/or
marshalling code, where a PROXY_STATE_GET message with two parameters gets
cut off in some way, possibly because the server is just shutting down at
that point?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3646) chm log field and TCP_MEM_HIT are the same feature
[ https://issues.apache.org/jira/browse/TS-3646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber updated TS-3646: Assignee: Jon Sime chm log field and TCP_MEM_HIT are the same feature Key: TS-3646 URL: https://issues.apache.org/jira/browse/TS-3646 Project: Traffic Server Issue Type: Improvement Components: Logging Affects Versions: 5.3.0 Reporter: Stephane Bagneris Assignee: Jon Sime Fix For: Docs The documented chm log field feature which will differentiate between RAM_HIT and DISK_HIT as already been implemented with the addition of TCP_MEM_HIT in the crc filed. Having both feature is redundant and confusing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3658) ASAN triggers when using the escalate.so plugin
[
https://issues.apache.org/jira/browse/TS-3658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-3658:
---
Fix Version/s: (was: 6.0.0)
6.1.0
ASAN triggers when using the escalate.so plugin
---
Key: TS-3658
URL: https://issues.apache.org/jira/browse/TS-3658
Project: Traffic Server
Issue Type: Bug
Components: Core, Plugins, TS API
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
Fix For: 6.1.0
{code}
==12883==ERROR: AddressSanitizer: heap-buffer-overflow on address
0x61df4480 at pc 0x7f00bd8b5e18 bp 0x7f00b8ac0a20 sp 0x7f00b8ac0a10
READ of size 1 at 0x61df4480 thread T4 ([ET_NET 3])
#0 0x7f00bd8b5e17 in ink_strlcpy(char*, char const*, unsigned long)
../../../../lib/ts/ink_string.cc:188
#1 0x6a967a in HttpSM::redirect_request(char const*, int)
../../../../proxy/http/HttpSM.cc:7474
#2 0x6be974 in HttpSM::do_redirect() ../../../../proxy/http/HttpSM.cc:7346
#3 0x6d065f in HttpSM::set_next_state()
../../../../proxy/http/HttpSM.cc:7041
#4 0x6c0021 in HttpSM::state_api_callout(int, void*)
../../../../proxy/http/HttpSM.cc:1415
#5 0x6d4c2a in HttpSM::state_api_callback(int, void*)
../../../../proxy/http/HttpSM.cc:1224
#6 0x564a7f in TSHttpTxnReenable ../../../proxy/InkAPI.cc:5621
#7 0x7f00ade09f84 in EscalateResponse
../../../../../plugins/experimental/escalate/escalate.cc:132
#8 0x6bfc26 in HttpSM::state_api_callout(int, void*)
../../../../proxy/http/HttpSM.cc:1333
#9 0x6c21df in HttpSM::state_read_server_response_header(int, void*)
../../../../proxy/http/HttpSM.cc:1817
#10 0x6d5050 in HttpSM::main_handler(int, void*)
../../../../proxy/http/HttpSM.cc:2524
#11 0xc0b6b5 in Continuation::handleEvent(int, void*)
../../../../iocore/eventsystem/I_Continuation.h:145
#12 0xc0b6b5 in read_signal_and_update
../../../../iocore/net/UnixNetVConnection.cc:139
#13 0xc0b6b5 in read_from_net
../../../../iocore/net/UnixNetVConnection.cc:352
#14 0xbe225c in NetHandler::mainNetEvent(int, Event*)
../../../../iocore/net/UnixNet.cc:551
#15 0xc8e7f9 in Continuation::handleEvent(int, void*)
../../../../iocore/eventsystem/I_Continuation.h:145
#16 0xc8e7f9 in EThread::process_event(Event*, int)
../../../../iocore/eventsystem/UnixEThread.cc:128
#17 0xc8e7f9 in EThread::execute()
../../../../iocore/eventsystem/UnixEThread.cc:252
#18 0xc8a588 in spawn_thread_internal
../../../../iocore/eventsystem/Thread.cc:85
#19 0x7f00bd41a529 in start_thread (/lib64/libpthread.so.0+0x3813e07529)
#20 0x381370022c in __clone (/lib64/libc.so.6+0x381370022c)
0x61df4480 is located 0 bytes to the right of 2048-byte region
[0x61df3c80,0x61df4480)
allocated by thread T4 ([ET_NET 3]) here:
#0 0x7f00bdb367c7 in malloc (/lib64/libasan.so.1+0x577c7)
#1 0x7f00bd8ab695 in ats_malloc ../../../../lib/ts/ink_memory.cc:50
#2 0x7f00bd8ab837 in ats_memalign ../../../../lib/ts/ink_memory.cc:89
#3 0x7f00bd8ac090 in ink_freelist_new ../../../../lib/ts/ink_queue.cc:243
#4 0x8de60d in new_HdrStrHeap ../../../../proxy/hdrs/HdrHeap.cc:151
#5 0x8de60d in HdrHeap::allocate_str(int)
../../../../proxy/hdrs/HdrHeap.cc:267
#6 0x8e263d in HdrHeap::duplicate_str(char const*, int)
../../../../proxy/hdrs/HdrHeap.cc:318
#7 0x8fc741 in mime_str_u16_set(HdrHeap*, char const*, int, char const**,
unsigned short*, bool) ../../../../proxy/hdrs/MIME.cc:2806
#8 0x91944f in url_scheme_set ../../../../proxy/hdrs/URL.cc:412
#9 0x91944f in url_parse_scheme ../../../../proxy/hdrs/URL.cc:1109
#10 0x91944f in url_parse(HdrHeap*, URLImpl*, char const**, char const*,
bool) ../../../../proxy/hdrs/URL.cc:1139
#11 0x6a9e13 in URL::parse(char const**, char const*)
../../../../proxy/hdrs/URL.h:724
#12 0x6a9e13 in URL::parse(char const*, int)
../../../../proxy/hdrs/URL.h:738
#13 0x6a9e13 in HttpSM::redirect_request(char const*, int)
../../../../proxy/http/HttpSM.cc:7419
#14 0x6be974 in HttpSM::do_redirect()
../../../../proxy/http/HttpSM.cc:7346
#15 0x6d065f in HttpSM::set_next_state()
../../../../proxy/http/HttpSM.cc:7041
#16 0x6c0021 in HttpSM::state_api_callout(int, void*)
../../../../proxy/http/HttpSM.cc:1415
#17 0x6d4c2a in HttpSM::state_api_callback(int, void*)
../../../../proxy/http/HttpSM.cc:1224
#18 0x564a7f in TSHttpTxnReenable ../../../proxy/InkAPI.cc:5621
#19 0x7f00ade09f84 in EscalateResponse
../../../../../plugins/experimental/escalate/escalate.cc:132
#20 0x6bfc26 in HttpSM::state_api_callout(int, void*)
../../../../proxy/http/HttpSM.cc:1333
#21 0x6c21df in HttpSM::state_read_server_response_header(int, void*)
../../../../proxy/http/HttpSM.cc:1817
#22
[jira] [Updated] (TS-3673) forgot 2 include files
[ https://issues.apache.org/jira/browse/TS-3673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-3673: --- Assignee: Phil Sorber forgot 2 include files -- Key: TS-3673 URL: https://issues.apache.org/jira/browse/TS-3673 Project: Traffic Server Issue Type: Bug Components: TS API Reporter: Oknet Xu Assignee: Phil Sorber Fix For: 6.0.0 file lib/ts/test_memchr.cc add include string.h for strlen() add include inittypes.h for uintptr_t here is the patch: --- a/lib/ts/test_memchr.cc +++ b/lib/ts/test_memchr.cc @@ -22,6 +22,8 @@ */ #include stdio.h +#include inttypes.h +#include string.h // // fast memchr -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3693) Move 100-continue logic to read client header for intercept plugins
[ https://issues.apache.org/jira/browse/TS-3693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-3693: --- Fix Version/s: 6.1.0 Move 100-continue logic to read client header for intercept plugins --- Key: TS-3693 URL: https://issues.apache.org/jira/browse/TS-3693 Project: Traffic Server Issue Type: Improvement Components: HTTP Reporter: Bryan Call Fix For: 6.1.0 From https://github.com/apache/trafficserver/pull/216 : Currently, ATS handles Expect: 100-continue header in HttpSM::state_send_server_request_header. In intercept plugin case, ATS may have no chance to run into this logic, it handles the header in a later point - HttpSM::state_send_server_request_header. I did not take this into account when I wrote the first patch. Now we have an intercept plugin use case in yahoo, and I think we need to move the handle logic some earlier, right after finish parsing the client request header. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3694) Fix function documentation to Log::error
[
https://issues.apache.org/jira/browse/TS-3694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-3694:
---
Fix Version/s: Docs
Fix function documentation to Log::error
Key: TS-3694
URL: https://issues.apache.org/jira/browse/TS-3694
Project: Traffic Server
Issue Type: Improvement
Components: Logging
Reporter: Daniel Xu
Fix For: Docs
The description for this function seems to be out of date. The note directly
contradicts what the function actually does.
{code:title=Log.cc|borderStyle=solid}
/*-
Log::error
Make an entry into the current error log. For convenience, it is given in
both variable argument (format, ...) and stdarg (format, va_list) forms.
Note that Log::error could call Log::va_error after calling va_start
so that va_error handles the statistics update. However, to make
Log::error slightly more efficient this is not the case. The
downside is that one has to be careful to update both functions if
need be.
-*/
int
Log::error(const char *format, ...)
{
va_list ap;
int ret;
va_start(ap, format);
ret = Log::va_error(format, ap);
va_end(ap);
return ret;
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3563) Support cond expansions in string values in header_rewrite plugin
[
https://issues.apache.org/jira/browse/TS-3563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-3563:
---
Fix Version/s: (was: 6.0.0)
6.1.0
Support cond expansions in string values in header_rewrite plugin
-
Key: TS-3563
URL: https://issues.apache.org/jira/browse/TS-3563
Project: Traffic Server
Issue Type: New Feature
Components: Plugins
Affects Versions: 5.3.0
Reporter: Sudheer Vinukonda
Fix For: 6.1.0
There's a requirement to support expanding the cond expressions of headers
using header_rewrite plugin.
For example, one may want to concat to headers like the below:
{{set-header Vary '%{HEADER:Vary}, %{User-Agent}' }}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3567) Need a way (tool?) to collect orphaned log files from clients to the log collation server
[ https://issues.apache.org/jira/browse/TS-3567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-3567: --- Fix Version/s: (was: 6.0.0) sometime Need a way (tool?) to collect orphaned log files from clients to the log collation server - Key: TS-3567 URL: https://issues.apache.org/jira/browse/TS-3567 Project: Traffic Server Issue Type: Bug Components: Logging Reporter: Leif Hedstrom Fix For: sometime As it is today, once you have an orphaned log file, it just sits there, until you manually remove it. There's also no way to replay it into the collation server. I think at a minimum, we should 1) Replay the log automatically when connectivity to collation server is reestablished. 2) Remove any collected orphaned logs In addition, I feel that orphaned logs should be rotated under the same rules / configs as normal access / error logs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3630) Fails to build with GCC 5 on Mac OS 10.10.3
[ https://issues.apache.org/jira/browse/TS-3630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-3630: --- Fix Version/s: (was: 6.0.0) sometime Fails to build with GCC 5 on Mac OS 10.10.3 --- Key: TS-3630 URL: https://issues.apache.org/jira/browse/TS-3630 Project: Traffic Server Issue Type: Bug Components: Build Reporter: alex dunn Assignee: Leif Hedstrom Fix For: sometime Builds fine with Clang, but GCC produces a bunch of undefined symbol errors. Full build logs + system config: https://gist.github.com/dunn/e97fdb5f12baa8d3e097#file-03-make-L201 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-3695) Need to have a broader design discussion of follow redirect issues
Susan Hinrichs created TS-3695: -- Summary: Need to have a broader design discussion of follow redirect issues Key: TS-3695 URL: https://issues.apache.org/jira/browse/TS-3695 Project: Traffic Server Issue Type: Improvement Components: HTTP Reporter: Susan Hinrichs We have recently encountered issues with the follow redirect feature. This is a useful, but somewhat non-standard feature. To avoid fixing and unfixing things, we need to have a broader consensus on the expected behavior of the follow redirect feature if various scenarios. Using this issue, the link bugs in this area. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3645) After TS-3033, some traffic_line commands result in requested command failed
[
https://issues.apache.org/jira/browse/TS-3645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-3645:
---
Assignee: (was: Bryan Call)
After TS-3033, some traffic_line commands result in requested command failed
--
Key: TS-3645
URL: https://issues.apache.org/jira/browse/TS-3645
Project: Traffic Server
Issue Type: Bug
Components: Management API
Affects Versions: 5.3.0, 6.0.0
Environment: RHEL 6.x, CentOS 6.x (on x86_64)
Reporter: Dimitry Andric
Fix For: 6.0.0
I recently upgraded from trafficserver 4.x to 5.3.0, and one thing that I
noticed was that certain traffic_line commands started printing requested
command failed. For example:
{noformat}
# trafficserver start
Starting Apache Traffic Server:[ OK ]
# traffic_line --status
Proxy -- on
# traffic_line --shutdown
error: the requested command failed: [11] Invalid parameters passed into
function call.
# traffic_line --startup
error: the requested command failed: [11] Invalid parameters passed into
function call.
{noformat}
Interestingly, even if the --shutdown command gives such an error message,
the diags.log file still shows that the server has shut down:
{noformat}
[May 28 22:03:03.539] Server {0x2abe4251d700} NOTE:
[ProcessManager::processEventQueue] Shutdown msg received, exiting
{noformat}
and the --status command also finds the same:
{noformat}
# traffic_line --status
Proxy -- off
{noformat}
Similar for the --startup command: though it gives the same error message,
the command seems to have actually worked.
I did some bisecting to find where this was introduced, and ended up at
[commit
355c165|https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;a=commit;h=355c165]
(TS-3033: fix PROXY_STATE_GET). Before this particular commit, both
{{traffic_line --shutdown}} and {{traffic_line --startup}} work without
printing any error; after the commit, they both start printing requested
command failed.
If I look at all the work done in TS-3033, and the particular change in
[commit
355c165|https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;a=commit;h=355c165],
I would guess that some parts of the code are disagreeing about the number
of parameters for the PROXY_STATE_GET message.
Alternatively, there may be some sort of issue in the management API and/or
marshalling code, where a PROXY_STATE_GET message with two parameters gets
cut off in some way, possibly because the server is just shutting down at
that point?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3647) Add support for changing transaction overrideable config vars to CPP API
[
https://issues.apache.org/jira/browse/TS-3647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-3647:
---
Fix Version/s: (was: sometime)
6.1.0
Add support for changing transaction overrideable config vars to CPP API
Key: TS-3647
URL: https://issues.apache.org/jira/browse/TS-3647
Project: Traffic Server
Issue Type: Improvement
Components: CPP API
Reporter: Alan M. Carroll
Assignee: Syeda Persia Aziz
Labels: newbie++
Fix For: 6.1.0
The CPP API should support the equivalent of the following C API functions.
{code}
TSHttpTxnConfigIntSet
TSHttpTxnConfigIntGet
TSHttpTxnConfigFloatSet
TSHttpTxnConfigFloatGet
TSHttpTxnConfigStringSet
TSHttpTxnConfigStringGet
TSHttpTxnConfigFind
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3648) Desire support for client TLS cipher in custom log format
[ https://issues.apache.org/jira/browse/TS-3648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-3648: --- Assignee: Eric Schwartz Desire support for client TLS cipher in custom log format - Key: TS-3648 URL: https://issues.apache.org/jira/browse/TS-3648 Project: Traffic Server Issue Type: New Feature Components: Logging Reporter: Eric Sproul Assignee: Eric Schwartz Fix For: 6.1.0 While the TLS cipher stats from TS-2169 are awesome for seeing what ciphers are in active use, I would also like to be able to create a custom log to track cipher by client request. That would enable me, for example, to determine who among my users might be affected by a cipher list change. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TS-3660) Segmentation fault (Address not mapped to object [(nil)])
[ https://issues.apache.org/jira/browse/TS-3660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call resolved TS-3660. Resolution: Duplicate Segmentation fault (Address not mapped to object [(nil)]) -- Key: TS-3660 URL: https://issues.apache.org/jira/browse/TS-3660 Project: Traffic Server Issue Type: Bug Components: Cache Affects Versions: 5.3.0 Reporter: daemon Labels: crash Fix For: 6.0.0 [E. Mgmt] log == [TrafficManager] using root directory '/xxx/trafficserver' traffic_server: using root directory '/xxx/trafficserver' traffic_server: Segmentation fault (Address not mapped to object [(nil)]) traffic_server - STACK TRACE: //trafficserver/bin/traffic_server(_Z19crash_logger_invokeiP9siginfo_tPv+0x8e)[0x4a816e] /lib64/libpthread.so.0(+0xf130)[0x2b8e58e84130] trafficserver version: [root@EACNxM003 trafficserver]# /xxx/trafficserver/bin/traffic_line -V Apache Traffic Server - traffic_line - 5.3.0 - (build # 060212 on Jun 2 2015 at 12:17:30) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-3627) Count tx and rx bytes for WebSocket
[ https://issues.apache.org/jira/browse/TS-3627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Geffon reassigned TS-3627: Assignee: Brian Geffon Count tx and rx bytes for WebSocket --- Key: TS-3627 URL: https://issues.apache.org/jira/browse/TS-3627 Project: Traffic Server Issue Type: New Feature Components: Metrics Reporter: bettydramit Assignee: Brian Geffon Fix For: sometime How to count rx and tx per map websocket (ws and wss)? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3627) Count tx and rx bytes for WebSocket
[ https://issues.apache.org/jira/browse/TS-3627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14588300#comment-14588300 ] Brian Geffon commented on TS-3627: -- Yah I'll take it. Count tx and rx bytes for WebSocket --- Key: TS-3627 URL: https://issues.apache.org/jira/browse/TS-3627 Project: Traffic Server Issue Type: New Feature Components: Metrics Reporter: bettydramit Fix For: sometime How to count rx and tx per map websocket (ws and wss)? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3681) Promote TSHrtime APIs to ts.h /apidefs.h
[ https://issues.apache.org/jira/browse/TS-3681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14588306#comment-14588306 ] Bryan Call commented on TS-3681: Where is the patch [~zwoop]? Are you going to land this for 6.0.0? Promote TSHrtime APIs to ts.h /apidefs.h Key: TS-3681 URL: https://issues.apache.org/jira/browse/TS-3681 Project: Traffic Server Issue Type: Improvement Components: TS API Reporter: Leif Hedstrom Assignee: Leif Hedstrom Labels: compatibility Fix For: 6.0.0 Time to move these from experimental to ts/ts.h / apidefs.h -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3691) traffic_crashlog messages when running traffic_server -R 1
[
https://issues.apache.org/jira/browse/TS-3691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-3691:
---
Assignee: Leif Hedstrom
traffic_crashlog messages when running traffic_server -R 1
--
Key: TS-3691
URL: https://issues.apache.org/jira/browse/TS-3691
Project: Traffic Server
Issue Type: Bug
Components: Core
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
Fix For: 6.0.0
When I run the regressions (-R 1), I get the following output:
{code}
REGRESSION_RESULT PARENTSELECTION: PASSED
REGRESSION_TEST DONE: PASSED
root@loki 132/0 # [Jun 14 22:31:48.574] {0x2b3658a84200} NOTE: crashlog
started, target=18881, debug=false syslog=true, uid=0 euid=0
[connect] ERROR (main_socket_fd 6): No such file or directory
[Jun 14 22:31:48.575] {0x2b3658a84200} WARNING: failed to intialize
management API: [5] Error establishing socket connection.
[Jun 14 22:31:48.575] {0x2b3658a84200} WARNING: received 0 of 128 expected
signal info bytes
[Jun 14 22:31:48.575] {0x2b3658a84200} WARNING: received 0 of 936 expected
thread context bytes
[Jun 14 22:31:48.575] {0x2b3658a84200} NOTE: logging to 0x22e7c20
[Jun 14 22:31:48.575] {0x2b3658a84200} NOTE: readlink failed with No such
file or directory
[connect] ERROR (main_socket_fd 7): No such file or directory
[connect] ERROR (main_socket_fd 7): No such file or directory
[Jun 14 22:31:48.575] {0x2b3658a84200} ERROR: wrote crash log to
/opt/ats/var/log/trafficserver/crash-2015-06-14-223148.log
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3695) Need to have a broader design discussion of follow redirect issues
[ https://issues.apache.org/jira/browse/TS-3695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-3695: --- Fix Version/s: sometime Need to have a broader design discussion of follow redirect issues -- Key: TS-3695 URL: https://issues.apache.org/jira/browse/TS-3695 Project: Traffic Server Issue Type: Improvement Components: HTTP Reporter: Susan Hinrichs Fix For: sometime We have recently encountered issues with the follow redirect feature. This is a useful, but somewhat non-standard feature. To avoid fixing and unfixing things, we need to have a broader consensus on the expected behavior of the follow redirect feature if various scenarios. Using this issue, the link bugs in this area. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-3586) milestones/slow log data do not have visibility to internal redirect follow
[ https://issues.apache.org/jira/browse/TS-3586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheer Vinukonda reassigned TS-3586: - Assignee: Sudheer Vinukonda milestones/slow log data do not have visibility to internal redirect follow --- Key: TS-3586 URL: https://issues.apache.org/jira/browse/TS-3586 Project: Traffic Server Issue Type: Improvement Components: HTTP Reporter: Sudheer Vinukonda Assignee: Sudheer Vinukonda Fix For: 6.0.0 milestones/slow log data do not have visibility to internal redirect follow. It is still under discussion on how best to fit the data (if at all), and the impact the change would have on the slow log API, log tags, metrics, slow log format etc. For the time being, added the *redirection_tries* to the slow log to indicate how many internal redirect follow events occurred on the TXN. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3619) ats_pagespeed make - no rule to make target psol
[ https://issues.apache.org/jira/browse/TS-3619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-3619: --- Fix Version/s: (was: 6.0.0) sometime ats_pagespeed make - no rule to make target psol Key: TS-3619 URL: https://issues.apache.org/jira/browse/TS-3619 Project: Traffic Server Issue Type: Bug Components: Configuration Reporter: Sebastian Pesman Assignee: Otto van der Schaaf Fix For: sometime When running make on a fresh clone of ats_pagespeed on Centos 7 the following error appears: make: *** No rule to make target `psol', needed by `all'. Stop. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-3625) Some statistics not being gathered
[ https://issues.apache.org/jira/browse/TS-3625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call reassigned TS-3625: -- Assignee: Bryan Call Some statistics not being gathered -- Key: TS-3625 URL: https://issues.apache.org/jira/browse/TS-3625 Project: Traffic Server Issue Type: Bug Components: Metrics Reporter: Jon Sime Assignee: Bryan Call Labels: compatibility Fix For: 6.0.0 The following statistics appear to not have any data collected for them in recent versions of TS, instead only emitting a zero value. The list was put together by examining the stats_over_http output on a production instance which receives enough varied traffic that it should, in theory at least, cause most implemented statistics to go non-zero. proxy.node.cache.contents.num_docs proxy.node.cache_hit_mem_ratio_avg_10s_int_pct proxy.node.cache_hit_mem_ratio_int_pct proxy.node.current_cache_connections proxy.node.dns.lookup_avg_time_ms proxy.node.dns.lookups_per_second proxy.node.dns.total_dns_lookups proxy.node.http.transaction_frac_avg_10s.errors.aborts_int_pct proxy.node.http.transaction_frac_avg_10s.errors.connect_failed_int_pct proxy.node.http.transaction_frac_avg_10s.errors.early_hangups_int_pct proxy.node.http.transaction_frac_avg_10s.errors.empty_hangups_int_pct proxy.node.http.transaction_frac_avg_10s.errors.other_int_pct proxy.node.http.transaction_frac_avg_10s.errors.possible_aborts_int_pct proxy.node.http.transaction_frac_avg_10s.errors.pre_accept_hangups_int_pct proxy.node.http.transaction_frac_avg_10s.hit_fresh_int_pct proxy.node.http.transaction_frac_avg_10s.hit_revalidated_int_pct proxy.node.http.transaction_frac_avg_10s.miss_changed_int_pct proxy.node.http.transaction_frac_avg_10s.miss_client_no_cache_int_pct proxy.node.http.transaction_frac_avg_10s.miss_cold_int_pct proxy.node.http.transaction_frac_avg_10s.miss_not_cacheable_int_pct proxy.node.http.transaction_frac_avg_10s.other.unclassified_int_pct proxy.node.log.bytes_flush_to_disk proxy.node.log.bytes_lost_before_flush_to_disk proxy.node.log.bytes_lost_before_preproc proxy.node.log.bytes_lost_before_sent_to_network proxy.node.log.bytes_lost_before_written_to_disk proxy.node.log.bytes_received_from_network proxy.node.log.bytes_received_from_network_avg_10s proxy.node.log.bytes_sent_to_network proxy.node.log.bytes_sent_to_network_avg_10s proxy.node.log.bytes_written_to_disk proxy.node.log.event_log_access_aggr proxy.node.log.event_log_access_fail proxy.node.log.event_log_access_full proxy.node.log.event_log_access_ok proxy.node.log.event_log_access_skip proxy.node.log.event_log_error_aggr proxy.node.log.event_log_error_fail proxy.node.log.event_log_error_full proxy.node.log.event_log_error_ok proxy.node.log.event_log_error_skip proxy.node.log.num_flush_to_disk proxy.node.log.num_lost_before_flush_to_disk proxy.node.log.num_lost_before_sent_to_network proxy.node.log.num_received_from_network proxy.node.log.num_sent_to_network proxy.process.cache.directory_collision proxy.process.cache.evacuate.active proxy.process.cache.evacuate.failure proxy.process.cache.evacuate.success proxy.process.cache.frags_per_doc.1 proxy.process.cache.frags_per_doc.2 proxy.process.cache.frags_per_doc.3+ proxy.process.cache.gc_bytes_evacuated proxy.process.cache.gc_frags_evacuated proxy.process.cache.hdr_marshal_bytes proxy.process.cache.hdr_marshals proxy.process.cache.lookup.active proxy.process.cache.lookup.failure proxy.process.cache.lookup.success proxy.process.cache.percent_full proxy.process.cache.pread_count proxy.process.cache.read_busy.failure proxy.process.cache.read_busy.success proxy.process.cache.remove.active proxy.process.cache.remove.failure proxy.process.cache.remove.success proxy.process.cache.scan.active proxy.process.cache.scan.failure proxy.process.cache.scan.success proxy.process.cache.volume_0.directory_collision proxy.process.cache.volume_0.evacuate.active proxy.process.cache.volume_0.evacuate.failure proxy.process.cache.volume_0.evacuate.success proxy.process.cache.volume_0.frags_per_doc.1 proxy.process.cache.volume_0.frags_per_doc.2 proxy.process.cache.volume_0.frags_per_doc.3+ proxy.process.cache.volume_0.gc_bytes_evacuated proxy.process.cache.volume_0.gc_frags_evacuated proxy.process.cache.volume_0.hdr_marshal_bytes proxy.process.cache.volume_0.hdr_marshals proxy.process.cache.volume_0.lookup.active proxy.process.cache.volume_0.lookup.failure proxy.process.cache.volume_0.lookup.success proxy.process.cache.volume_0.pread_count proxy.process.cache.volume_0.remove.active proxy.process.cache.volume_0.remove.failure proxy.process.cache.volume_0.remove.success proxy.process.cache.volume_0.scan.active proxy.process.cache.volume_0.scan.failure
[jira] [Updated] (TS-3647) Add support for changing transaction overrideable config vars to CPP API
[
https://issues.apache.org/jira/browse/TS-3647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Sorber updated TS-3647:
Fix Version/s: (was: 6.0.0)
sometime
Add support for changing transaction overrideable config vars to CPP API
Key: TS-3647
URL: https://issues.apache.org/jira/browse/TS-3647
Project: Traffic Server
Issue Type: Improvement
Components: CPP API
Reporter: Alan M. Carroll
Assignee: Syeda Persia Aziz
Labels: newbie++
Fix For: sometime
The CPP API should support the equivalent of the following C API functions.
{code}
TSHttpTxnConfigIntSet
TSHttpTxnConfigIntGet
TSHttpTxnConfigFloatSet
TSHttpTxnConfigFloatGet
TSHttpTxnConfigStringSet
TSHttpTxnConfigStringGet
TSHttpTxnConfigFind
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3656) Activating follow redirection in send server response hook does not work for post
[ https://issues.apache.org/jira/browse/TS-3656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14588272#comment-14588272 ] Bryan Call commented on TS-3656: Please commit this change for 6.0.0. Activating follow redirection in send server response hook does not work for post - Key: TS-3656 URL: https://issues.apache.org/jira/browse/TS-3656 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: Susan Hinrichs Assignee: Susan Hinrichs Fix For: 6.0.0 If you have a plugin on the TS_HTTP_SEND_RESPONSE_HDR_HOOK, calls TSHttpTxnFollowRedirect(txn, 1), redirecting a POST request will fail. In the not so bad case, the POST request will be redirected to the new location, but the POST data will be lost. In the more bad case, ATS will crash. The issue is that the post_redirect buffers are freed early on. One could delay the post_redirect deallocation until later in the transaction. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3694) Fix function documentation to Log::error
[
https://issues.apache.org/jira/browse/TS-3694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-3694:
---
Assignee: Daniel Xu
Fix function documentation to Log::error
Key: TS-3694
URL: https://issues.apache.org/jira/browse/TS-3694
Project: Traffic Server
Issue Type: Improvement
Components: Logging
Reporter: Daniel Xu
Assignee: Daniel Xu
Fix For: Docs
The description for this function seems to be out of date. The note directly
contradicts what the function actually does.
{code:title=Log.cc|borderStyle=solid}
/*-
Log::error
Make an entry into the current error log. For convenience, it is given in
both variable argument (format, ...) and stdarg (format, va_list) forms.
Note that Log::error could call Log::va_error after calling va_start
so that va_error handles the statistics update. However, to make
Log::error slightly more efficient this is not the case. The
downside is that one has to be careful to update both functions if
need be.
-*/
int
Log::error(const char *format, ...)
{
va_list ap;
int ret;
va_start(ap, format);
ret = Log::va_error(format, ap);
va_end(ap);
return ret;
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3611) Segmentation fault: Address not mapped to object
[
https://issues.apache.org/jira/browse/TS-3611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-3611:
---
Fix Version/s: (was: 6.0.0)
6.1.0
Segmentation fault: Address not mapped to object
Key: TS-3611
URL: https://issues.apache.org/jira/browse/TS-3611
Project: Traffic Server
Issue Type: Bug
Affects Versions: 5.3.0
Reporter: Nikolai Gorchilov
Labels: crash
Fix For: 6.1.0
Experienced the following crash while running ATS 5.3.0 on custom Linux
distro:
{noformat}
traffic_server: Segmentation fault (Address not mapped to object [0x10])
traffic_server - STACK TRACE:
/z/bin/traffic_server(crash_logger_invoke(int, siginfo_t*,
void*)+0x8e)[0x4ad5fe]
/lib64/libpthread.so.0(+0x105f0)[0x2b63a09b55f0]
/z/bin/traffic_server(HostDBProcessor::getbyname_imm(Continuation*, void
(Continuation::*)(HostDBInfo*), char const*, int, HostDBProcessor::Options
const)+0x72)[0x68c652]
/z/bin/traffic_server(HttpSM::do_hostdb_lookup()+0xb8)[0x5b2f48]
/z/bin/traffic_server(HttpSM::set_next_state()+0xdb5)[0x5c1815]
/z/bin/traffic_server(HttpSM::state_send_server_request_header(int,
void*)+0x15a)[0x5bd5da]
/z/bin/traffic_server(HttpSM::main_handler(int, void*)+0xbd)[0x5c282d]
/z/bin/traffic_server[0x749be6]
/z/bin/traffic_server(NetHandler::mainNetEvent(int, Event*)+0x1f2)[0x73c742]
/z/bin/traffic_server(EThread::execute()+0xa4a)[0x76ad4a]
/z/bin/traffic_server[0x7699ba]
/lib64/libpthread.so.0(+0x7294)[0x2b63a09ac294]
/lib64/libc.so.6(clone+0x6d)[0x2b63a16d471d]
{noformat}
UPDATE: Few hours later, another server, same crash reason, different
call-stack:
{noformat}
traffic_server: Segmentation fault (Address not mapped to object
[0x2adc4759bff0])
traffic_server - STACK TRACE:
/z/bin/traffic_server(crash_logger_invoke(int, siginfo*,
void*)+0x99)[0x4b0e49]
/lib64/libpthread.so.0(+0x10630)[0x2ad84e658630]
/lib64/libc.so.6(+0x903de)[0x2ad84f5273de]
/z/bin/traffic_server(Vol::aggWrite(int, void*)+0x715)[0x6ff6a5]
/z/bin/traffic_server(Vol::evacuateDocReadDone(int, Event*)+0x3fa)[0x70092a]
/z/bin/traffic_server(AIOCallbackInternal::io_complete(int,
void*)+0x3d)[0x6812fd]
/z/bin/traffic_server(EThread::process_event(Event*, int)+0x10f)[0x75e77f]
/z/bin/traffic_server(EThread::execute()+0x6ef)[0x75f28f]
/z/bin/traffic_server[0x75db0a]
/lib64/libpthread.so.0(+0x72d4)[0x2ad84e64f2d4]
/lib64/libc.so.6(clone+0x6d)[0x2ad84f57e74d]
{noformat}
Here're the relevant configure options of my build:
{noformat}
./configure \
--with-xml=libxml2 \
--disable-static \
--disable-spdy \
--enable-interim-cache \
--enable-tproxy \
--enable-hwloc \
--enable-experimental-plugins \
--enable-example-plugins
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3642) proxy.config.http.share_server_sessions not working
[ https://issues.apache.org/jira/browse/TS-3642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber updated TS-3642: Backport to Version: (was: 5.3.1) proxy.config.http.share_server_sessions not working --- Key: TS-3642 URL: https://issues.apache.org/jira/browse/TS-3642 Project: Traffic Server Issue Type: Bug Components: Configuration Affects Versions: 5.3.0 Reporter: David Carlin Assignee: Alan M. Carroll Fix For: 6.0.0 Testing 5.3.0 and I noticed proxy.config.http.share_server_sessions = 1 no longer works. Saw a 10-15x increase in origin connections; there appears to be some reuse, I am seeing approximately 1.2-1.3 requests per origin connection. Setting proxy.config.http.server_session_sharing.pool = global restored expected behavior (Thanks [~sudheerv]!) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-3645) After TS-3033, some traffic_line commands result in requested command failed
[
https://issues.apache.org/jira/browse/TS-3645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call reassigned TS-3645:
--
Assignee: Bryan Call
After TS-3033, some traffic_line commands result in requested command failed
--
Key: TS-3645
URL: https://issues.apache.org/jira/browse/TS-3645
Project: Traffic Server
Issue Type: Bug
Components: Management API
Affects Versions: 5.3.0, 6.0.0
Environment: RHEL 6.x, CentOS 6.x (on x86_64)
Reporter: Dimitry Andric
Assignee: Bryan Call
Fix For: 6.0.0
I recently upgraded from trafficserver 4.x to 5.3.0, and one thing that I
noticed was that certain traffic_line commands started printing requested
command failed. For example:
{noformat}
# trafficserver start
Starting Apache Traffic Server:[ OK ]
# traffic_line --status
Proxy -- on
# traffic_line --shutdown
error: the requested command failed: [11] Invalid parameters passed into
function call.
# traffic_line --startup
error: the requested command failed: [11] Invalid parameters passed into
function call.
{noformat}
Interestingly, even if the --shutdown command gives such an error message,
the diags.log file still shows that the server has shut down:
{noformat}
[May 28 22:03:03.539] Server {0x2abe4251d700} NOTE:
[ProcessManager::processEventQueue] Shutdown msg received, exiting
{noformat}
and the --status command also finds the same:
{noformat}
# traffic_line --status
Proxy -- off
{noformat}
Similar for the --startup command: though it gives the same error message,
the command seems to have actually worked.
I did some bisecting to find where this was introduced, and ended up at
[commit
355c165|https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;a=commit;h=355c165]
(TS-3033: fix PROXY_STATE_GET). Before this particular commit, both
{{traffic_line --shutdown}} and {{traffic_line --startup}} work without
printing any error; after the commit, they both start printing requested
command failed.
If I look at all the work done in TS-3033, and the particular change in
[commit
355c165|https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;a=commit;h=355c165],
I would guess that some parts of the code are disagreeing about the number
of parameters for the PROXY_STATE_GET message.
Alternatively, there may be some sort of issue in the management API and/or
marshalling code, where a PROXY_STATE_GET message with two parameters gets
cut off in some way, possibly because the server is just shutting down at
that point?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3654) ASAN heap-use-after-free in cache-hosting (regression)
[
https://issues.apache.org/jira/browse/TS-3654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-3654:
---
Assignee: Alan M. Carroll
ASAN heap-use-after-free in cache-hosting (regression)
--
Key: TS-3654
URL: https://issues.apache.org/jira/browse/TS-3654
Project: Traffic Server
Issue Type: Improvement
Components: Cache
Reporter: Leif Hedstrom
Assignee: Alan M. Carroll
Fix For: 6.1.0
{code}
RPRINT Cache_vol: 1 128 Megabyte Volumes
RPRINT Cache_vol: Not enough space for 10 volume
RPRINT Cache_vol: Random Volumes after clearing the disks
RPRINT Cache_vol: volume=1 scheme=http size=128
RPRINT Cache_vol: Random Volumes without clearing the disks
RPRINT Cache_vol: volume=1 scheme=rtsp size=128
=
==3733==ERROR: AddressSanitizer: heap-use-after-free on address
0x604a2960 at pc 0xa7ce83 bp 0x7f3c7f946980 sp 0x7f3c7f946970
READ of size 8 at 0x604a2960 thread T3 ([ET_NET 2])
#0 0xa7ce82 in cplist_update ../../../../iocore/cache/Cache.cc:3230
#1 0xa7ce82 in cplist_reconfigure() ../../../../iocore/cache/Cache.cc:3374
#2 0xac619e in execute_and_verify(RegressionTest*)
../../../../iocore/cache/CacheHosting.cc:994
#3 0xac75f8 in RegressionTest_Cache_vol(RegressionTest*, int, int*)
../../../../iocore/cache/CacheHosting.cc:840
#4 0x7f3c8480b4d2 in start_test ../../../../lib/ts/Regression.cc:77
#5 0x7f3c8480b4d2 in RegressionTest::run_some()
../../../../lib/ts/Regression.cc:125
#6 0x7f3c8480b9b6 in RegressionTest::check_status()
../../../../lib/ts/Regression.cc:140
#7 0x57b5b4 in RegressionCont::mainEvent(int, Event*)
../../../proxy/Main.cc:1220
#8 0xc8b86e in Continuation::handleEvent(int, void*)
../../../../iocore/eventsystem/I_Continuation.h:145
#9 0xc8b86e in EThread::process_event(Event*, int)
../../../../iocore/eventsystem/UnixEThread.cc:128
#10 0xc8da67 in EThread::execute()
../../../../iocore/eventsystem/UnixEThread.cc:207
#11 0xc8a488 in spawn_thread_internal
../../../../iocore/eventsystem/Thread.cc:85
#12 0x7f3c84392529 in start_thread (/lib64/libpthread.so.0+0x3813e07529)
#13 0x381370022c in __clone (/lib64/libc.so.6+0x381370022c)
0x604a2960 is located 16 bytes inside of 40-byte region
[0x604a2950,0x604a2978)
freed by thread T3 ([ET_NET 2]) here:
#0 0x7f3c84aaf64f in operator delete(void*) (/lib64/libasan.so.1+0x5864f)
#1 0xabbd16 in CacheDisk::delete_volume(int)
../../../../iocore/cache/CacheDisk.cc:330
#2 0xa7bfe0 in cplist_update ../../../../iocore/cache/Cache.cc:3212
#3 0xa7bfe0 in cplist_reconfigure() ../../../../iocore/cache/Cache.cc:3374
#4 0xac619e in execute_and_verify(RegressionTest*)
../../../../iocore/cache/CacheHosting.cc:994
#5 0xac75f8 in RegressionTest_Cache_vol(RegressionTest*, int, int*)
../../../../iocore/cache/CacheHosting.cc:840
#6 0x7f3c8480b4d2 in start_test ../../../../lib/ts/Regression.cc:77
#7 0x7f3c8480b4d2 in RegressionTest::run_some()
../../../../lib/ts/Regression.cc:125
#8 0x7f3c8480b9b6 in RegressionTest::check_status()
../../../../lib/ts/Regression.cc:140
#9 0x57b5b4 in RegressionCont::mainEvent(int, Event*)
../../../proxy/Main.cc:1220
#10 0xc8b86e in Continuation::handleEvent(int, void*)
../../../../iocore/eventsystem/I_Continuation.h:145
#11 0xc8b86e in EThread::process_event(Event*, int)
../../../../iocore/eventsystem/UnixEThread.cc:128
#12 0xc8da67 in EThread::execute()
../../../../iocore/eventsystem/UnixEThread.cc:207
#13 0xc8a488 in spawn_thread_internal
../../../../iocore/eventsystem/Thread.cc:85
#14 0x7f3c84392529 in start_thread (/lib64/libpthread.so.0+0x3813e07529)
previously allocated by thread T3 ([ET_NET 2]) here:
#0 0x7f3c84aaf14f in operator new(unsigned long)
(/lib64/libasan.so.1+0x5814f)
#1 0xaba5ca in CacheDisk::create_volume(int, long, int)
../../../../iocore/cache/CacheDisk.cc:296
#2 0xa74f81 in create_volume ../../../../iocore/cache/Cache.cc:3551
#3 0xa7ca20 in cplist_reconfigure() ../../../../iocore/cache/Cache.cc:3405
#4 0xac619e in execute_and_verify(RegressionTest*)
../../../../iocore/cache/CacheHosting.cc:994
#5 0xac75f8 in RegressionTest_Cache_vol(RegressionTest*, int, int*)
../../../../iocore/cache/CacheHosting.cc:840
#6 0x7f3c8480b4d2 in start_test ../../../../lib/ts/Regression.cc:77
#7 0x7f3c8480b4d2 in RegressionTest::run_some()
../../../../lib/ts/Regression.cc:125
#8 0x7f3c8480b9b6 in RegressionTest::check_status()
../../../../lib/ts/Regression.cc:140
#9 0x57b5b4 in RegressionCont::mainEvent(int, Event*)
../../../proxy/Main.cc:1220
#10 0xc8b86e in
[jira] [Updated] (TS-3685) traffic_manager can't bind to port 80 sometimes.
[
https://issues.apache.org/jira/browse/TS-3685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-3685:
---
Fix Version/s: (was: 6.0.0)
6.1.0
traffic_manager can't bind to port 80 sometimes.
Key: TS-3685
URL: https://issues.apache.org/jira/browse/TS-3685
Project: Traffic Server
Issue Type: Bug
Components: Manager
Reporter: Sudheer Vinukonda
Assignee: Sudheer Vinukonda
Fix For: 6.1.0
During new install/updates sometimes, when ATS is restarted too quickly
multiple times, we occasionally end up with the below error, causing ATS not
to come up:
{code}
[Jun 11 14:46:24.852] Manager {0x7fa0e2b217e0} NOTE:
[LocalManager::listenForProxy] Listening on port: 80
[Jun 11 14:46:24.852] Manager {0x7fa0e2b217e0} NOTE:
[LocalManager::listenForProxy] Listening on port: 443
[Jun 11 14:46:24.852] Manager {0x7fa0e2b217e0} ERROR: [bindProxyPort] Unable
to bind socket: 80 : Address already in use
{code}
This is quite annoying and inconvenient since it blocks ATS from coming up
(sometimes for very long) until a reboot or some other deep clean up is
performed.
Would like to add the socket option *SO_REUSEPORT* to the socket doing the
proxy port binding.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3686) Implement Lua scriptlets, as discussed at the Austin 2015 Summit
[ https://issues.apache.org/jira/browse/TS-3686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber updated TS-3686: Labels: C (was: ) Implement Lua scriptlets, as discussed at the Austin 2015 Summit -- Key: TS-3686 URL: https://issues.apache.org/jira/browse/TS-3686 Project: Traffic Server Issue Type: New Feature Components: Configuration, Lua Reporter: Leif Hedstrom Labels: C Fix For: 6.2.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TS-1985) Eliminate built-in log formats in favor of logs_xml.config
[ https://issues.apache.org/jira/browse/TS-1985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber resolved TS-1985. - Resolution: Fixed Eliminate built-in log formats in favor of logs_xml.config -- Key: TS-1985 URL: https://issues.apache.org/jira/browse/TS-1985 Project: Traffic Server Issue Type: Improvement Components: Logging Reporter: Leif Hedstrom Assignee: Phil Sorber Labels: incompatible, newbie Fix For: 6.0.0 I have a feeling that the hardcoded (built-in) log-formats was the old way of doing things, and logs_xml.config is the new way. As such, I'd like to propose that we eliminate all the built-in's, and provide all those formats in a default logs_xml.config. One thing that might be necessary to add is an option in the XML config to disable a log file. I don't know if that's easily doable without using XML comments, but would be easy to add and useful. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3580) cache generation ID configuration
[ https://issues.apache.org/jira/browse/TS-3580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14588523#comment-14588523 ] ASF subversion and git services commented on TS-3580: - Commit 87bed9b390af30a6b6d4078adba885871e508a36 in trafficserver's branch refs/heads/master from [~psudaemon] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=87bed9b ] TS-3580: clang-format cache generation ID configuration - Key: TS-3580 URL: https://issues.apache.org/jira/browse/TS-3580 Project: Traffic Server Issue Type: New Feature Components: Cache, Configuration Reporter: James Peach Assignee: James Peach Fix For: 6.0.0 It's common to want to purge the cache online, or to purge specific tenants in a multi-tenant cache. One reasonably straight forward implementation of this is to allow operators to specify a cache generation ID (a 64 bit integer that is hashed into the cache key). This is a global overridable configuration, so you can set it globally or for a specific remap rule. Note that it is a bit of a sharp tool, since if you lose or cannot propagate the correct generation ID you will take a cache miss. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3541) Eliminate interim cache
[ https://issues.apache.org/jira/browse/TS-3541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14588510#comment-14588510 ] ASF subversion and git services commented on TS-3541: - Commit dc6e1c196861b95427b59ebf02aa84ac0f1c56fa in trafficserver's branch refs/heads/master from [~psudaemon] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=dc6e1c1 ] TS-3541: clang-format Eliminate interim cache --- Key: TS-3541 URL: https://issues.apache.org/jira/browse/TS-3541 Project: Traffic Server Issue Type: Improvement Components: Cache Reporter: Leif Hedstrom Assignee: Leif Hedstrom Labels: compatibility Fix For: 6.0.0 This feature is poorly supported, and causes grief for cache development due to how it #ifdef’s with the system. There are plans for a new system that would make the concept of cache hierarchies generic. In the mean time, the suggestion is that if you need this, you use one of 1) Assigning content to volumes and disks via our existing configs. 2) Use Linux’s bcache feature, which comes with Linux 3.10 or later. I suspect e.g. ZFS has something similar. 3) Use a third party system to implement the hybrid device (e.g. flash cache or EnhanceIO. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3673) Remove ink_memchr completely
[ https://issues.apache.org/jira/browse/TS-3673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber updated TS-3673: Summary: Remove ink_memchr completely (was: forgot 2 include files) Remove ink_memchr completely Key: TS-3673 URL: https://issues.apache.org/jira/browse/TS-3673 Project: Traffic Server Issue Type: Bug Components: TS API Reporter: Oknet Xu Assignee: Phil Sorber Fix For: 6.0.0 file lib/ts/test_memchr.cc add include string.h for strlen() add include inittypes.h for uintptr_t here is the patch: --- a/lib/ts/test_memchr.cc +++ b/lib/ts/test_memchr.cc @@ -22,6 +22,8 @@ */ #include stdio.h +#include inttypes.h +#include string.h // // fast memchr -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3673) Remove ink_memchr completely
[ https://issues.apache.org/jira/browse/TS-3673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14588447#comment-14588447 ] ASF subversion and git services commented on TS-3673: - Commit fc8113b8c15167f6254298cb14b66d7128a03668 in trafficserver's branch refs/heads/master from [~psudaemon] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=fc8113b ] TS-3673: Remove ink_memchr and friends Remove ink_memchr completely Key: TS-3673 URL: https://issues.apache.org/jira/browse/TS-3673 Project: Traffic Server Issue Type: Bug Components: TS API Reporter: Oknet Xu Assignee: Phil Sorber Fix For: 6.0.0 file lib/ts/test_memchr.cc add include string.h for strlen() add include inittypes.h for uintptr_t here is the patch: --- a/lib/ts/test_memchr.cc +++ b/lib/ts/test_memchr.cc @@ -22,6 +22,8 @@ */ #include stdio.h +#include inttypes.h +#include string.h // // fast memchr -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3266) core dump in UnixNetProcessor::connect_re_internal
[
https://issues.apache.org/jira/browse/TS-3266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14588448#comment-14588448
]
Susan Hinrichs commented on TS-3266:
I think this is due to an issue of using multiple locks at different points to
protect the UnixNetVConnection::read.vio data structure
In the crash in SSLNetVConnection:net_read_io (frame #13), the function has
successfully acquired the lock from the what this-read.vio.mutex was pointing
at at the time. Looking at the mutex pointer values in the variable lock, this
corresponds to the value of nh-mutex. At the point of the crash
this-read,vio,mutex has the same value as the HttpSM-mutex in frame 6.
I'm guessing that another thread has acquired the HttpSM lock and updated the
read.vio data. Since almost everywhere, the read.vio seems to be protected by
the HttpSM mutex, not the NetHandler mutex.
Looking more broadly at the state of the cores. It appears that ATS has
completed a SSL handshake with the Origin server. Then the origin server sends
a EOS, which is the event being processed at the time of the core.
This is the second attempt to connect to the server.
(HttpSM::t_state.current.attempts == 2). Presumably the first attempt failed,
and we are now launching into our third attempt (or perhaps we are launching
into our second attempt). This explains the server_entry == NULL that Sudheer
noticed. The server_entry is set to NULL as we go up the stack to clean up the
failed connection attempt.
At first I blamed the cases where we pass NULL into the continuation for the
do_io_read, but I no longer think that is the case. If the continuation is
NULL, the netVC-mutex is used. And at this point, the netvc-mutex looks like
the HttpSM mutex not the net handler mutex. I cannot find the scenario where
the net handler's mutex is ever used in setting up a read vio. Still looking.
core dump in UnixNetProcessor::connect_re_internal
--
Key: TS-3266
URL: https://issues.apache.org/jira/browse/TS-3266
Project: Traffic Server
Issue Type: Bug
Components: Core
Affects Versions: 5.2.0, 5.3.0
Reporter: Sudheer Vinukonda
Assignee: Susan Hinrichs
Labels: crash
Attachments: ts-3266.diff
See a new core dump in v5.2.0 after running stable for over 48 hours. Below
is the bt and some gdb info.
{code}
(gdb) bt
#0 0x00773056 in EThread::is_event_type (this=0x0, et=2) at
UnixEThread.cc:121
#1 0x00750cfe in UnixNetProcessor::connect_re_internal
(this=0x1032fc0, cont=0x2aad4590d080, target=0x2aad4590d728,
opt=0x2aac8b367600) at UnixNetProcessor.cc:247
#2 0x0052b498 in NetProcessor::connect_re (this=0x1032fc0,
cont=0x2aad4590d080, addr=0x2aad4590d728, opts=0x2aac8b367600) at
../iocore/net/P_UnixNetProcessor.h:85
#3 0x005e64e5 in HttpSM::do_http_server_open (this=0x2aad4590d080,
raw=false) at HttpSM.cc:4796
#4 0x005edec7 in HttpSM::set_next_state (this=0x2aad4590d080) at
HttpSM.cc:7141
#5 0x005ed2f2 in HttpSM::call_transact_and_set_next_state
(this=0x2aad4590d080, f=0x607320
HttpTransact::HandleResponse(HttpTransact::State*)) at HttpSM.cc:6961
#6 0x005e7b72 in HttpSM::handle_server_setup_error
(this=0x2aad4590d080, event=104, data=0x2aade42edae8) at HttpSM.cc:5308
#7 0x005dc57c in HttpSM::state_send_server_request_header
(this=0x2aad4590d080, event=104, data=0x2aade42edae8) at HttpSM.cc:1989
#8 0x005de6a2 in HttpSM::main_handler (this=0x2aad4590d080,
event=104, data=0x2aade42edae8) at HttpSM.cc:2570
#9 0x00502eae in Continuation::handleEvent (this=0x2aad4590d080,
event=104, data=0x2aade42edae8) at ../iocore/eventsystem/I_Continuation.h:146
#10 0x007524c3 in read_signal_and_update (event=104,
vc=0x2aade42ed9d0) at UnixNetVConnection.cc:138
#11 0x0075261e in read_signal_done (event=104, nh=0x2aac89a53ad0,
vc=0x2aade42ed9d0) at UnixNetVConnection.cc:169
#12 0x00754cd4 in UnixNetVConnection::readSignalDone
(this=0x2aade42ed9d0, event=104, nh=0x2aac89a53ad0) at
UnixNetVConnection.cc:922
#13 0x0073e088 in SSLNetVConnection::net_read_io
(this=0x2aade42ed9d0, nh=0x2aac89a53ad0, lthread=0x2aac89a50010) at
SSLNetVConnection.cc:596
#14 0x0074c50d in NetHandler::mainNetEvent (this=0x2aac89a53ad0,
event=5, e=0x282fb30) at UnixNet.cc:399
#15 0x00502eae in Continuation::handleEvent (this=0x2aac89a53ad0,
event=5, data=0x282fb30) at ../iocore/eventsystem/I_Continuation.h:146
#16 0x00773172 in EThread::process_event (this=0x2aac89a50010,
e=0x282fb30, calling_code=5) at UnixEThread.cc:144
#17 0x0077367c in EThread::execute (this=0x2aac89a50010) at
UnixEThread.cc:268
#18 0x0077272d in
[jira] [Updated] (TS-3660) Segmentation fault (Address not mapped to object [(nil)])
[ https://issues.apache.org/jira/browse/TS-3660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-3660: --- Fix Version/s: (was: 6.0.0) Segmentation fault (Address not mapped to object [(nil)]) -- Key: TS-3660 URL: https://issues.apache.org/jira/browse/TS-3660 Project: Traffic Server Issue Type: Bug Components: Cache Affects Versions: 5.3.0 Reporter: daemon Labels: crash [E. Mgmt] log == [TrafficManager] using root directory '/xxx/trafficserver' traffic_server: using root directory '/xxx/trafficserver' traffic_server: Segmentation fault (Address not mapped to object [(nil)]) traffic_server - STACK TRACE: //trafficserver/bin/traffic_server(_Z19crash_logger_invokeiP9siginfo_tPv+0x8e)[0x4a816e] /lib64/libpthread.so.0(+0xf130)[0x2b8e58e84130] trafficserver version: [root@EACNxM003 trafficserver]# /xxx/trafficserver/bin/traffic_line -V Apache Traffic Server - traffic_line - 5.3.0 - (build # 060212 on Jun 2 2015 at 12:17:30) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (TS-3660) Segmentation fault (Address not mapped to object [(nil)])
[ https://issues.apache.org/jira/browse/TS-3660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call closed TS-3660. -- Segmentation fault (Address not mapped to object [(nil)]) -- Key: TS-3660 URL: https://issues.apache.org/jira/browse/TS-3660 Project: Traffic Server Issue Type: Bug Components: Cache Affects Versions: 5.3.0 Reporter: daemon Labels: crash [E. Mgmt] log == [TrafficManager] using root directory '/xxx/trafficserver' traffic_server: using root directory '/xxx/trafficserver' traffic_server: Segmentation fault (Address not mapped to object [(nil)]) traffic_server - STACK TRACE: //trafficserver/bin/traffic_server(_Z19crash_logger_invokeiP9siginfo_tPv+0x8e)[0x4a816e] /lib64/libpthread.so.0(+0xf130)[0x2b8e58e84130] trafficserver version: [root@EACNxM003 trafficserver]# /xxx/trafficserver/bin/traffic_line -V Apache Traffic Server - traffic_line - 5.3.0 - (build # 060212 on Jun 2 2015 at 12:17:30) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3660) Segmentation fault (Address not mapped to object [(nil)])
[ https://issues.apache.org/jira/browse/TS-3660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14588445#comment-14588445 ] Bryan Call commented on TS-3660: We need more lines of the stack trace to determine where the server is coring. If you are able to get more information on the stack trace please reopen. Segmentation fault (Address not mapped to object [(nil)]) -- Key: TS-3660 URL: https://issues.apache.org/jira/browse/TS-3660 Project: Traffic Server Issue Type: Bug Components: Cache Affects Versions: 5.3.0 Reporter: daemon Labels: crash [E. Mgmt] log == [TrafficManager] using root directory '/xxx/trafficserver' traffic_server: using root directory '/xxx/trafficserver' traffic_server: Segmentation fault (Address not mapped to object [(nil)]) traffic_server - STACK TRACE: //trafficserver/bin/traffic_server(_Z19crash_logger_invokeiP9siginfo_tPv+0x8e)[0x4a816e] /lib64/libpthread.so.0(+0xf130)[0x2b8e58e84130] trafficserver version: [root@EACNxM003 trafficserver]# /xxx/trafficserver/bin/traffic_line -V Apache Traffic Server - traffic_line - 5.3.0 - (build # 060212 on Jun 2 2015 at 12:17:30) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-1985) Eliminate built-in log formats in favor of logs_xml.config
[ https://issues.apache.org/jira/browse/TS-1985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14588496#comment-14588496 ] ASF subversion and git services commented on TS-1985: - Commit 9236bb738db2cdcab6174a619f25c89190aa0e3a in trafficserver's branch refs/heads/master from [~psudaemon] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=9236bb7 ] TS-1985: clang-format Eliminate built-in log formats in favor of logs_xml.config -- Key: TS-1985 URL: https://issues.apache.org/jira/browse/TS-1985 Project: Traffic Server Issue Type: Improvement Components: Logging Reporter: Leif Hedstrom Assignee: Phil Sorber Labels: incompatible, newbie Fix For: 6.0.0 I have a feeling that the hardcoded (built-in) log-formats was the old way of doing things, and logs_xml.config is the new way. As such, I'd like to propose that we eliminate all the built-in's, and provide all those formats in a default logs_xml.config. One thing that might be necessary to add is an option in the XML config to disable a log file. I don't know if that's easily doable without using XML comments, but would be easy to add and useful. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-1985) Eliminate built-in log formats in favor of logs_xml.config
[ https://issues.apache.org/jira/browse/TS-1985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14588495#comment-14588495 ] ASF subversion and git services commented on TS-1985: - Commit 5c2b032fb9f8f05ae7be1794a3103140ffe7d07e in trafficserver's branch refs/heads/master from [~cqian] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=5c2b032 ] TS-1985: Removed hard-coded logging formats; now configurable in log .xml. Eliminate built-in log formats in favor of logs_xml.config -- Key: TS-1985 URL: https://issues.apache.org/jira/browse/TS-1985 Project: Traffic Server Issue Type: Improvement Components: Logging Reporter: Leif Hedstrom Assignee: Phil Sorber Labels: incompatible, newbie Fix For: 6.0.0 I have a feeling that the hardcoded (built-in) log-formats was the old way of doing things, and logs_xml.config is the new way. As such, I'd like to propose that we eliminate all the built-in's, and provide all those formats in a default logs_xml.config. One thing that might be necessary to add is an option in the XML config to disable a log file. I don't know if that's easily doable without using XML comments, but would be easy to add and useful. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TS-3651) Eliminate proxy.config.http.share_server_sessions
[ https://issues.apache.org/jira/browse/TS-3651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll resolved TS-3651. - Resolution: Fixed Eliminate proxy.config.http.share_server_sessions - Key: TS-3651 URL: https://issues.apache.org/jira/browse/TS-3651 Project: Traffic Server Issue Type: Improvement Components: Configuration Reporter: Leif Hedstrom Assignee: Alan M. Carroll Priority: Critical Labels: Incompatible Fix For: 6.0.0 We deprecated proxy.config.http.share_server_sessions in v5.x, in favor of a set of more powerful configuration options. As such, it's time to remove the old configuration for 6.0.0. This is inline with our normal practice of 1) Deprecate something in version n 2) Remove that something in version n + 1. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TS-3650) Configuration variables should track their source
[
https://issues.apache.org/jira/browse/TS-3650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll resolved TS-3650.
-
Resolution: Fixed
Configuration variables should track their source
-
Key: TS-3650
URL: https://issues.apache.org/jira/browse/TS-3650
Project: Traffic Server
Issue Type: Improvement
Components: Configuration
Reporter: Alan M. Carroll
Assignee: Alan M. Carroll
Fix For: 6.0.0
A configuration variable can get its value from a variety of sources. It
would be useful to be able to programmatically determine that source. At a
minimum the ability to determine if a variable was set explicitly in a
configuration file vs. using a built in default value would be very useful.
In addition this information should be made available to the administrator
via {{traffic_ctl}} to aid in debugging.
The proposed values are
* {{DEFAULT}} - built in default, hard wired.
* {{FILE}} - read from a configuration file.
* {{API}} - set via an API of some sort ({{traffic_line}} etc.)
* {{CLUSTER}} - set via cluster configuration
* {{ENV}} - set from an environment variable
In addition the value {{INVALID}} will be defined to use for the internal
API, primarily as a value to return if the requested variable doesn't exist
(in which case none of the previous values are reasonable).
Update: Based on feedback the current values are
* {{DEFAULT}} - built in default, hard wired.
* {{EXPLICIT}} - set by the administrator
* {{ENV}} - set from an environment variable
* {{NULL}} - value does not exist, therefore has no source.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3650) Configuration variables should track their source
[
https://issues.apache.org/jira/browse/TS-3650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14588809#comment-14588809
]
ASF subversion and git services commented on TS-3650:
-
Commit 182506526c713b51e73b5f69f2376c708af594cc in trafficserver's branch
refs/heads/master from [~amc]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=1825065 ]
TS-3650: Track configuration variable source.
Configuration variables should track their source
-
Key: TS-3650
URL: https://issues.apache.org/jira/browse/TS-3650
Project: Traffic Server
Issue Type: Improvement
Components: Configuration
Reporter: Alan M. Carroll
Assignee: Alan M. Carroll
Fix For: 6.0.0
A configuration variable can get its value from a variety of sources. It
would be useful to be able to programmatically determine that source. At a
minimum the ability to determine if a variable was set explicitly in a
configuration file vs. using a built in default value would be very useful.
In addition this information should be made available to the administrator
via {{traffic_ctl}} to aid in debugging.
The proposed values are
* {{DEFAULT}} - built in default, hard wired.
* {{FILE}} - read from a configuration file.
* {{API}} - set via an API of some sort ({{traffic_line}} etc.)
* {{CLUSTER}} - set via cluster configuration
* {{ENV}} - set from an environment variable
In addition the value {{INVALID}} will be defined to use for the internal
API, primarily as a value to return if the requested variable doesn't exist
(in which case none of the previous values are reasonable).
Update: Based on feedback the current values are
* {{DEFAULT}} - built in default, hard wired.
* {{EXPLICIT}} - set by the administrator
* {{ENV}} - set from an environment variable
* {{NULL}} - value does not exist, therefore has no source.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3697) Fix frame type check for http/2
[ https://issues.apache.org/jira/browse/TS-3697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-3697: --- Fix Version/s: 6.0.0 Fix frame type check for http/2 --- Key: TS-3697 URL: https://issues.apache.org/jira/browse/TS-3697 Project: Traffic Server Issue Type: Bug Components: HTTP/2 Reporter: Bryan Call Assignee: Bryan Call Fix For: 6.0.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-3697) Fix frame type check for http/2
[ https://issues.apache.org/jira/browse/TS-3697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call reassigned TS-3697: -- Assignee: Bryan Call Fix frame type check for http/2 --- Key: TS-3697 URL: https://issues.apache.org/jira/browse/TS-3697 Project: Traffic Server Issue Type: Bug Components: HTTP/2 Reporter: Bryan Call Assignee: Bryan Call Fix For: 6.0.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3697) Fix frame type check for http/2 is invalid
[ https://issues.apache.org/jira/browse/TS-3697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-3697: --- Summary: Fix frame type check for http/2 is invalid (was: Fix frame type check for http/2) Fix frame type check for http/2 is invalid -- Key: TS-3697 URL: https://issues.apache.org/jira/browse/TS-3697 Project: Traffic Server Issue Type: Bug Components: HTTP/2 Reporter: Bryan Call Assignee: Bryan Call Fix For: 6.0.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3561) Use TSMutexDestroy in a couple of plugins
[ https://issues.apache.org/jira/browse/TS-3561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14588779#comment-14588779 ] ASF subversion and git services commented on TS-3561: - Commit fedf96e21dc9b8ba032c90c00c6271c2774acf23 in trafficserver's branch refs/heads/master from [~amc] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=fedf96e ] TS-3561: Remove share_server_sessions configuration value. Use TSMutexDestroy in a couple of plugins - Key: TS-3561 URL: https://issues.apache.org/jira/browse/TS-3561 Project: Traffic Server Issue Type: Bug Components: Plugins Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 6.0.0 In at least background_fetch and cache_promote, we don't destroy the mutex on config destruction. This was intentional, since the API didn't use to exist, but now it does. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-3696) Bad range check in HdrHeap
[
https://issues.apache.org/jira/browse/TS-3696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom reassigned TS-3696:
-
Assignee: Leif Hedstrom
Bad range check in HdrHeap
--
Key: TS-3696
URL: https://issues.apache.org/jira/browse/TS-3696
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
Fix For: 6.0.0
gcc 5.1 complains with
{code}
../../../proxy/hdrs/HdrHeap.cc: In member function 'void
HdrHeap::inherit_string_heaps(const HdrHeap*)':
../../../proxy/hdrs/HdrHeap.cc:978:23: error: array subscript is above array
bounds [-Werror=array-bounds]
if (m_ronly_heap[z].m_heap_start == h_start) {
^
cc1plus: all warnings being treated as errors
Makefile:677: recipe for target 'HdrHeap.o' failed
make[1]: *** [HdrHeap.o] Error 1
{code}
There's a check in the code to make sure *index is within the boundaries, but
it is done too late.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3696) Bad range check in HdrHeap
[
https://issues.apache.org/jira/browse/TS-3696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-3696:
--
Fix Version/s: 6.0.0
Bad range check in HdrHeap
--
Key: TS-3696
URL: https://issues.apache.org/jira/browse/TS-3696
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Reporter: Leif Hedstrom
Fix For: 6.0.0
gcc 5.1 complains with
{code}
../../../proxy/hdrs/HdrHeap.cc: In member function 'void
HdrHeap::inherit_string_heaps(const HdrHeap*)':
../../../proxy/hdrs/HdrHeap.cc:978:23: error: array subscript is above array
bounds [-Werror=array-bounds]
if (m_ronly_heap[z].m_heap_start == h_start) {
^
cc1plus: all warnings being treated as errors
Makefile:677: recipe for target 'HdrHeap.o' failed
make[1]: *** [HdrHeap.o] Error 1
{code}
There's a check in the code to make sure *index is within the boundaries, but
it is done too late.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3696) Bad range check in HdrHeap
[
https://issues.apache.org/jira/browse/TS-3696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-3696:
--
Priority: Blocker (was: Major)
Bad range check in HdrHeap
--
Key: TS-3696
URL: https://issues.apache.org/jira/browse/TS-3696
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
Priority: Blocker
Fix For: 6.0.0
gcc 5.1 complains with
{code}
../../../proxy/hdrs/HdrHeap.cc: In member function 'void
HdrHeap::inherit_string_heaps(const HdrHeap*)':
../../../proxy/hdrs/HdrHeap.cc:978:23: error: array subscript is above array
bounds [-Werror=array-bounds]
if (m_ronly_heap[z].m_heap_start == h_start) {
^
cc1plus: all warnings being treated as errors
Makefile:677: recipe for target 'HdrHeap.o' failed
make[1]: *** [HdrHeap.o] Error 1
{code}
There's a check in the code to make sure *index is within the boundaries, but
it is done too late.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3696) Bad range check in HdrHeap
[
https://issues.apache.org/jira/browse/TS-3696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14588859#comment-14588859
]
ASF subversion and git services commented on TS-3696:
-
Commit df0b90c5c787378e642dcaf80a8c2cdaad10930a in trafficserver's branch
refs/heads/master from [~zwoop]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=df0b90c ]
TS-3696 Fix range check in HdrHeap::attach_str_heap()
Bad range check in HdrHeap
--
Key: TS-3696
URL: https://issues.apache.org/jira/browse/TS-3696
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
Priority: Blocker
Fix For: 6.0.0
gcc 5.1 complains with
{code}
../../../proxy/hdrs/HdrHeap.cc: In member function 'void
HdrHeap::inherit_string_heaps(const HdrHeap*)':
../../../proxy/hdrs/HdrHeap.cc:978:23: error: array subscript is above array
bounds [-Werror=array-bounds]
if (m_ronly_heap[z].m_heap_start == h_start) {
^
cc1plus: all warnings being treated as errors
Makefile:677: recipe for target 'HdrHeap.o' failed
make[1]: *** [HdrHeap.o] Error 1
{code}
There's a check in the code to make sure *index is within the boundaries, but
it is done too late.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
