[jira] [Updated] (TS-1405) apply time-wheel scheduler about event system
[ https://issues.apache.org/jira/browse/TS-1405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen updated TS-1405: - Attachment: (was: TS-1405.patch) > apply time-wheel scheduler about event system > -- > > Key: TS-1405 > URL: https://issues.apache.org/jira/browse/TS-1405 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Affects Versions: 3.2.0 >Reporter: Bin Chen >Assignee: Bin Chen > Fix For: 3.3.1 > > Attachments: linux_time_wheel.patch, linux_time_wheel_v2.patch, > linux_time_wheel_v3.patch, linux_time_wheel_v4.patch > > > when have more and more event in event system scheduler, it's worse. This is > the reason why we use inactivecop to handler keepalive. the new scheduler is > time-wheel. It's have better time complexity(O(1)) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1405) apply time-wheel scheduler about event system
[ https://issues.apache.org/jira/browse/TS-1405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen updated TS-1405: - Attachment: (was: time_wheel_v4.patch) > apply time-wheel scheduler about event system > -- > > Key: TS-1405 > URL: https://issues.apache.org/jira/browse/TS-1405 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Affects Versions: 3.2.0 >Reporter: Bin Chen >Assignee: Bin Chen > Fix For: 3.3.1 > > Attachments: linux_time_wheel.patch, linux_time_wheel_v2.patch, > linux_time_wheel_v3.patch, linux_time_wheel_v4.patch > > > when have more and more event in event system scheduler, it's worse. This is > the reason why we use inactivecop to handler keepalive. the new scheduler is > time-wheel. It's have better time complexity(O(1)) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1405) apply time-wheel scheduler about event system
[ https://issues.apache.org/jira/browse/TS-1405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen updated TS-1405: - Attachment: linux_time_wheel_v4.patch rename TS-1405 to linux_time_wheel_v4.patch. it's last version > apply time-wheel scheduler about event system > -- > > Key: TS-1405 > URL: https://issues.apache.org/jira/browse/TS-1405 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Affects Versions: 3.2.0 >Reporter: Bin Chen >Assignee: Bin Chen > Fix For: 3.3.1 > > Attachments: linux_time_wheel.patch, linux_time_wheel_v2.patch, > linux_time_wheel_v3.patch, linux_time_wheel_v4.patch > > > when have more and more event in event system scheduler, it's worse. This is > the reason why we use inactivecop to handler keepalive. the new scheduler is > time-wheel. It's have better time complexity(O(1)) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1405) apply time-wheel scheduler about event system
[ https://issues.apache.org/jira/browse/TS-1405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13586722#comment-13586722 ] John Plevyak commented on TS-1405: -- Let me take a last look. The race condition bug in the last version was rather subtle. john > apply time-wheel scheduler about event system > -- > > Key: TS-1405 > URL: https://issues.apache.org/jira/browse/TS-1405 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Affects Versions: 3.2.0 >Reporter: Bin Chen >Assignee: Bin Chen > Fix For: 3.3.1 > > Attachments: linux_time_wheel.patch, linux_time_wheel_v2.patch, > linux_time_wheel_v3.patch, time_wheel_v4.patch, TS-1405.patch > > > when have more and more event in event system scheduler, it's worse. This is > the reason why we use inactivecop to handler keepalive. the new scheduler is > time-wheel. It's have better time complexity(O(1)) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1645) increase the file stat resolution on config files
[ https://issues.apache.org/jira/browse/TS-1645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13586564#comment-13586564 ] ASF subversion and git services commented on TS-1645: - Commit 5d7fb725d4bc0e3f66d476198a69b2ded0a5c15e in branch refs/heads/master from [~kopely] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=5d7fb72 ] TS-1645: increase the file stat resolution on config files > increase the file stat resolution on config files > - > > Key: TS-1645 > URL: https://issues.apache.org/jira/browse/TS-1645 > Project: Traffic Server > Issue Type: Bug > Components: Management >Reporter: Yakov Kopel >Assignee: James Peach > Fix For: 3.3.1 > > Attachments: stat_1.diff, stat_2.diff > > > today the check of "file has been changed" is done by "stat" with resolution > of seconds. > I'm adding a patch to increase the resolution to neno-seconds. this is > supported in part of file systems and kernels, but done no harm to others > (the nanoseconds just be 0). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1557) ua_begin_write stat is never set ATS
[ https://issues.apache.org/jira/browse/TS-1557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13586537#comment-13586537 ] ASF subversion and git services commented on TS-1557: - Commit 44aae027eb3a6879b8f8add1f79fed7170aae5ce in branch refs/heads/master from [~psudaemon] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=44aae02 ] TS-1557: update ua_begin_write Author: Aidan McGurn > ua_begin_write stat is never set ATS > > > Key: TS-1557 > URL: https://issues.apache.org/jira/browse/TS-1557 > Project: Traffic Server > Issue Type: Bug > Components: Stats >Affects Versions: 3.2.0 > Environment: RHEL6.2 >Reporter: Aidan McGurn >Assignee: Phil Sorber > Fix For: 3.3.1 > > Attachments: INTD-1512-Stats.patch > > > The ua_begin_write (and probably others related to this) which we use to > determine latencies due to proxy intervention is never set in the TS - > i've attached a patch of approximately where it should be around the > send_header_response phase - > This is related to this bug i think: > https://issues.apache.org/jira/browse/TS-1504 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1584) Exposing client SSL certificate verification result in plugin API
[ https://issues.apache.org/jira/browse/TS-1584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13586534#comment-13586534 ] James Peach commented on TS-1584: - Yes. > Exposing client SSL certificate verification result in plugin API > -- > > Key: TS-1584 > URL: https://issues.apache.org/jira/browse/TS-1584 > Project: Traffic Server > Issue Type: Improvement > Components: SSL, TS API >Affects Versions: 3.3.4 >Reporter: Thach Tran >Assignee: James Peach >Priority: Minor > Labels: patch > Fix For: 3.3.2 > > Attachments: > 0001-Exposing-client-ssl-certificate-verification-result-.patch, > 0001-TS-1584-Retaining-some-info-from-client-certificate-.patch > > > I'm writing an authentication plugin for traffic server and would like to > implement the following logic: > * If the client supplies valid certificate over ssl, allow the transaction > to proceed with no further authentication. > * Otherwise challenge the client with username/password authentication. > Currently if I turn on client certificate checking in TS > (proxy.config.ssl.client.certification_level > 0), the result of the client > certificate verification happens at the SSLNetVConnection level and plugin > hooks have no knowledge of this. This makes implementing the aforementioned > logic not possible. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1584) Exposing client SSL certificate verification result in plugin API
[ https://issues.apache.org/jira/browse/TS-1584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-1584: Fix Version/s: (was: 3.3.1) 3.3.2 > Exposing client SSL certificate verification result in plugin API > -- > > Key: TS-1584 > URL: https://issues.apache.org/jira/browse/TS-1584 > Project: Traffic Server > Issue Type: Improvement > Components: SSL, TS API >Affects Versions: 3.3.4 >Reporter: Thach Tran >Assignee: James Peach >Priority: Minor > Labels: patch > Fix For: 3.3.2 > > Attachments: > 0001-Exposing-client-ssl-certificate-verification-result-.patch, > 0001-TS-1584-Retaining-some-info-from-client-certificate-.patch > > > I'm writing an authentication plugin for traffic server and would like to > implement the following logic: > * If the client supplies valid certificate over ssl, allow the transaction > to proceed with no further authentication. > * Otherwise challenge the client with username/password authentication. > Currently if I turn on client certificate checking in TS > (proxy.config.ssl.client.certification_level > 0), the result of the client > certificate verification happens at the SSLNetVConnection level and plugin > hooks have no knowledge of this. This makes implementing the aforementioned > logic not possible. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-1583) Visibility of hash_map unclear to GCC 4.7 when -std=c++11
[
https://issues.apache.org/jira/browse/TS-1583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach reassigned TS-1583:
---
Assignee: Alan M. Carroll (was: James Peach)
Sounds like Alan wants this bug.
> Visibility of hash_map unclear to GCC 4.7 when -std=c++11
> -
>
> Key: TS-1583
> URL: https://issues.apache.org/jira/browse/TS-1583
> Project: Traffic Server
> Issue Type: Bug
> Components: Build
>Affects Versions: 3.3.0
> Environment: Fedora 17 64bit - gcc 4.7
>Reporter: Luca Rea
>Assignee: Alan M. Carroll
> Fix For: 3.3.1
>
> Attachments: ts-1583.patch
>
>
> master trunk
> {noformat}
> make[2]: Entering directory `/home/luca/trafficserver/proxy'
> CXXlogstats.o
> logstats.cc:349:74: error: template argument 3 is invalid
> logstats.cc:349:89: error: invalid type in declaration before ‘;’ token
> logstats.cc:350:59: error: template argument 2 is invalid
> logstats.cc:350:70: error: invalid type in declaration before ‘;’ token
> logstats.cc:359:80: error: template argument 3 is invalid
> logstats.cc: In member function ‘void UrlLru::add_stat(const char*, int64_t,
> int, int, int, int)’:
> logstats.cc:402:23: error: expected initializer before ‘h’
> logstats.cc:404:9: error: ‘h’ was not declared in this scope
> logstats.cc:404:20: error: request for member ‘end’ in
> ‘((UrlLru*)this)->UrlLru::_hash’, which is of non-class type ‘UrlLru::LruHash
> {aka int}’
> logstats.cc:461:21: error: request for member ‘find’ in
> ‘((UrlLru*)this)->UrlLru::_hash’, which is of non-class type ‘UrlLru::LruHash
> {aka int}’
> logstats.cc:462:26: error: request for member ‘end’ in
> ‘((UrlLru*)this)->UrlLru::_hash’, which is of non-class type ‘UrlLru::LruHash
> {aka int}’
> logstats.cc:463:19: error: request for member ‘erase’ in
> ‘((UrlLru*)this)->UrlLru::_hash’, which is of non-class type ‘UrlLru::LruHash
> {aka int}’
> logstats.cc:522:18: error: assignment of read-only location ‘*(u +
> ((sizetype)((long unsigned int)((UrlLru*)this)->UrlLru::_hash)))’
> logstats.cc:522:18: error: cannot convert ‘std::list::iterator {aka
> std::_List_iterator}’ to ‘const char’ in assignment
> logstats.cc: In member function ‘void UrlLru::_init()’:
> logstats.cc:536:13: error: request for member ‘resize’ in
> ‘((UrlLru*)this)->UrlLru::_hash’, which is of non-class type ‘UrlLru::LruHash
> {aka int}’
> logstats.cc: In function ‘int parse_log_buff(LogBufferHeader*, bool)’:
> logstats.cc:1183:27: error: expected initializer before ‘o_iter’
> logstats.cc:1347:43: error: request for member ‘find’ in ‘* origin_set’,
> which is of non-class type ‘OriginSet {aka int}’
> logstats.cc:1347:68: error: request for member ‘end’ in ‘* origin_set’, which
> is of non-class type ‘OriginSet {aka int}’
> logstats.cc:1348:15: error: ‘o_iter’ was not declared in this scope
> logstats.cc:1348:32: error: request for member ‘find’ in ‘origins’, which is
> of non-class type ‘OriginStorage {aka int}’
> logstats.cc:1349:27: error: request for member ‘end’ in ‘origins’, which is
> of non-class type ‘OriginStorage {aka int}’
> logstats.cc:1356:39: error: invalid conversion from ‘OriginStats*’ to ‘char’
> [-fpermissive]
> logstats.cc: In function ‘void my_exit(const ExitStatus&)’:
> logstats.cc:2132:16: error: request for member ‘empty’ in ‘origins’, which is
> of non-class type ‘OriginStorage {aka int}’
> logstats.cc:2134:25: error: invalid use of qualified-name ‘::iterator’
> logstats.cc:2134:34: error: expected ‘;’ before ‘i’
> logstats.cc:2134:34: error: ‘i’ was not declared in this scope
> logstats.cc:2134:46: error: request for member ‘begin’ in ‘origins’, which is
> of non-class type ‘OriginStorage {aka int}’
> logstats.cc:2134:68: error: request for member ‘end’ in ‘origins’, which is
> of non-class type ‘OriginStorage {aka int}’
> logstats.cc:2134:73: error: expected ‘)’ before ‘;’ token
> logstats.cc:2134:75: error: ‘i’ was not declared in this scope
> logstats.cc:2134:78: error: expected ‘;’ before ‘)’ token
> logstats.cc: In function ‘int main(int, char**)’:
> logstats.cc:2295:21: error: request for member ‘insert’ in ‘* origin_set’,
> which is of non-class type ‘OriginSet {aka int}’
> logstats.cc:2330:25: error: request for member ‘insert’ in ‘* origin_set’,
> which is of non-class type ‘OriginSet {aka int}’
> make[2]: *** [logstats.o] Error 1
> make[2]: Leaving directory `/home/luca/trafficserver/proxy'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/home/luca/trafficserver/proxy'
> make: *** [all-recursive] Error 1
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1432) API is missing TSMutexDestroy
[ https://issues.apache.org/jira/browse/TS-1432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13586515#comment-13586515 ] James Peach commented on TS-1432: - Yes, this lack makes mutexes impossible to use. We should add it. > API is missing TSMutexDestroy > - > > Key: TS-1432 > URL: https://issues.apache.org/jira/browse/TS-1432 > Project: Traffic Server > Issue Type: Improvement > Components: TS API >Affects Versions: 3.3.3 >Reporter: Brian Geffon >Assignee: Brian Geffon > Fix For: 3.3.1 > > > pthread_mutex_destory on a TSMutex would cause a leak, this API is really > necessary. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-1557) ua_begin_write stat is never set ATS
[ https://issues.apache.org/jira/browse/TS-1557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber reassigned TS-1557: --- Assignee: Phil Sorber (was: Bin Chen) > ua_begin_write stat is never set ATS > > > Key: TS-1557 > URL: https://issues.apache.org/jira/browse/TS-1557 > Project: Traffic Server > Issue Type: Bug > Components: Stats >Affects Versions: 3.2.0 > Environment: RHEL6.2 >Reporter: Aidan McGurn >Assignee: Phil Sorber > Fix For: 3.3.1 > > Attachments: INTD-1512-Stats.patch > > > The ua_begin_write (and probably others related to this) which we use to > determine latencies due to proxy intervention is never set in the TS - > i've attached a patch of approximately where it should be around the > send_header_response phase - > This is related to this bug i think: > https://issues.apache.org/jira/browse/TS-1504 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1438) Cache inspector should add trailing slash to CI URL
[
https://issues.apache.org/jira/browse/TS-1438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1438:
--
Fix Version/s: (was: 3.3.1)
3.3.2
Daniel, moving this out to 3.3.3, please provide a patch.
> Cache inspector should add trailing slash to CI URL
> ---
>
> Key: TS-1438
> URL: https://issues.apache.org/jira/browse/TS-1438
> Project: Traffic Server
> Issue Type: Bug
> Components: Web UI
>Affects Versions: 3.3.0
> Environment: FreeBSD 9.0
>Reporter: Daniel Gruno
>Priority: Trivial
> Labels: cache, inspector, webui
> Fix For: 3.3.2
>
> Original Estimate: 168h
> Remaining Estimate: 168h
>
> When setting up the Cache Inspector as described by the docs
> (http://trafficserver.apache.org/docs/trunk/admin/configuring-cache/index.en.html
> ), an URL snafooey occurs.
> In remap.config I have set:
> map http://dallas.awesomelysecure.org/myCI http://{cache} @action=allow
> When accessing /myCI, I do get the cache inspector, but because it fails to
> add a trailing slash, the links are all broken, pointing to f.x. /lookup_url
> instead of /myCI/lookup_url.
> This could be solved by checking if a trailing slash exists, and if not,
> issuing a 301 redirect to /myCI/.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1409) Add webdav methods to ip allow/quick filter
[ https://issues.apache.org/jira/browse/TS-1409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-1409: --- Assignee: Bryan Call > Add webdav methods to ip allow/quick filter > --- > > Key: TS-1409 > URL: https://issues.apache.org/jira/browse/TS-1409 > Project: Traffic Server > Issue Type: Bug > Components: Security >Affects Versions: 3.2.0 >Reporter: Bryan Call >Assignee: Bryan Call > Fix For: 3.3.1 > > > I know of PROPFIND and REPORT should be added. There might need to be more > added. > HTTP Extensions for Distributed Authoring -- WEBDAV > http://www.ietf.org/rfc/rfc2518.txt -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1405) apply time-wheel scheduler about event system
[ https://issues.apache.org/jira/browse/TS-1405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13586492#comment-13586492 ] James Peach commented on TS-1405: - This sounds promising; what do we need to do to land this? > apply time-wheel scheduler about event system > -- > > Key: TS-1405 > URL: https://issues.apache.org/jira/browse/TS-1405 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Affects Versions: 3.2.0 >Reporter: Bin Chen >Assignee: Bin Chen > Fix For: 3.3.1 > > Attachments: linux_time_wheel.patch, linux_time_wheel_v2.patch, > linux_time_wheel_v3.patch, time_wheel_v4.patch, TS-1405.patch > > > when have more and more event in event system scheduler, it's worse. This is > the reason why we use inactivecop to handler keepalive. the new scheduler is > time-wheel. It's have better time complexity(O(1)) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1320) Reading from SSL origin can starve sending data to client
[ https://issues.apache.org/jira/browse/TS-1320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13586489#comment-13586489 ] ASF subversion and git services commented on TS-1320: - Commit 47913b8e106b984e4a2f10784b20479635570f73 in branch refs/heads/master from [~zwoop] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=47913b8 ] Added TS-1320 to CHANGES. > Reading from SSL origin can starve sending data to client > - > > Key: TS-1320 > URL: https://issues.apache.org/jira/browse/TS-1320 > Project: Traffic Server > Issue Type: Bug > Components: Network >Affects Versions: 3.0.4 >Reporter: William Bardwell >Assignee: Leif Hedstrom >Priority: Minor > Fix For: 3.3.1 > > > When we had a fast connection doing SSL to an origin server, and a slower > connection to the client, and not very much CPU, the SSL VConn code would > start to spin reading data from the origin server, and not breaking out of > the loop at all to send data to the client. As a result the throughput to > the client would drop to zero and ATS would get a bit bigger. So my proposed > patch is to have the SSL VConn code not stay in its loop when it has some > data that it has read, this matches how non-SSL network VConn's work. My one > concern with this is that there might have been a good reason for that > looping, and that this might slow down cases when things are working properly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1320) Reading from SSL origin can starve sending data to client
[ https://issues.apache.org/jira/browse/TS-1320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13586490#comment-13586490 ] ASF subversion and git services commented on TS-1320: - Commit a7dec953238d644c43b08c75a06f5b7bbc4b1019 in branch refs/heads/master from Leif Hedstrom [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=a7dec95 ] TS-1320 Reading from SSL origin can starve sending data to client > Reading from SSL origin can starve sending data to client > - > > Key: TS-1320 > URL: https://issues.apache.org/jira/browse/TS-1320 > Project: Traffic Server > Issue Type: Bug > Components: Network >Affects Versions: 3.0.4 >Reporter: William Bardwell >Assignee: Leif Hedstrom >Priority: Minor > Fix For: 3.3.1 > > > When we had a fast connection doing SSL to an origin server, and a slower > connection to the client, and not very much CPU, the SSL VConn code would > start to spin reading data from the origin server, and not breaking out of > the loop at all to send data to the client. As a result the throughput to > the client would drop to zero and ATS would get a bit bigger. So my proposed > patch is to have the SSL VConn code not stay in its loop when it has some > data that it has read, this matches how non-SSL network VConn's work. My one > concern with this is that there might have been a good reason for that > looping, and that this might slow down cases when things are working properly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1320) Reading from SSL origin can starve sending data to client
[
https://issues.apache.org/jira/browse/TS-1320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13586477#comment-13586477
]
Leif Hedstrom commented on TS-1320:
---
Does this look right? Rebased on current master, and changed the while()
slightly:
{code}
diff --git a/iocore/net/SSLNetVConnection.cc b/iocore/net/SSLNetVConnection.cc
index 1af06d4..ee57ad9 100644
--- a/iocore/net/SSLNetVConnection.cc
+++ b/iocore/net/SSLNetVConnection.cc
@@ -258,11 +258,11 @@ SSLNetVConnection::net_read_io(NetHandler *nh, EThread
*lthread)
if (ret == SSL_READ_READY || ret == SSL_READ_ERROR_NONE) {
bytes += r;
}
-
- } while (ret == SSL_READ_READY || ret == SSL_READ_ERROR_NONE);
+ink_debug_assert(bytes >= 0);
+ } while ((ret == SSL_READ_READY && bytes == 0) || ret ==
SSL_READ_ERROR_NONE);
if (bytes > 0) {
-if (ret == SSL_READ_WOULD_BLOCK) {
+if (ret == SSL_READ_WOULD_BLOCK || ret == SSL_READ_READY) {
if (readSignalAndUpdate(VC_EVENT_READ_READY) != EVENT_CONT) {
Debug("ssl", "ssl_read_from_net, readSignal != EVENT_CONT");
return;
@@ -273,8 +273,8 @@ SSLNetVConnection::net_read_io(NetHandler *nh, EThread
*lthread)
switch (ret) {
case SSL_READ_ERROR_NONE:
case SSL_READ_READY:
-// how did we exit the while loop above? should never happen.
-ink_debug_assert(false);
+readReschedule(nh);
+return;
break;
case SSL_WRITE_WOULD_BLOCK:
case SSL_READ_WOULD_BLOCK:
{code}
> Reading from SSL origin can starve sending data to client
> -
>
> Key: TS-1320
> URL: https://issues.apache.org/jira/browse/TS-1320
> Project: Traffic Server
> Issue Type: Bug
> Components: Network
>Affects Versions: 3.0.4
>Reporter: William Bardwell
>Assignee: Leif Hedstrom
>Priority: Minor
> Fix For: 3.3.1
>
>
> When we had a fast connection doing SSL to an origin server, and a slower
> connection to the client, and not very much CPU, the SSL VConn code would
> start to spin reading data from the origin server, and not breaking out of
> the loop at all to send data to the client. As a result the throughput to
> the client would drop to zero and ATS would get a bit bigger. So my proposed
> patch is to have the SSL VConn code not stay in its loop when it has some
> data that it has read, this matches how non-SSL network VConn's work. My one
> concern with this is that there might have been a good reason for that
> looping, and that this might slow down cases when things are working properly.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1330) Logging related segfault in 3.2.0
[
https://issues.apache.org/jira/browse/TS-1330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-1330:
---
Assignee: Leif Hedstrom
> Logging related segfault in 3.2.0
> -
>
> Key: TS-1330
> URL: https://issues.apache.org/jira/browse/TS-1330
> Project: Traffic Server
> Issue Type: Bug
> Components: Logging
>Affects Versions: 3.2.0
> Environment: ATS 3.2.0 on RHEL 6.2 64-bit
>Reporter: David Carlin
>Assignee: Leif Hedstrom
> Fix For: 3.3.1
>
>
> I observed the following crash once on one of our ATS boxes - possibly
> related to TS-1240
> Jul 2 13:56:56 l2 traffic_server[25853]: {0x2b0a391e1700} ERROR:
> [SSL_NetVConnection::ssl_read_from_net] SSL_ERROR_SYSCALL, underlying IO
> error: Connection reset by peer
> Jul 2 13:59:56 l2 kernel: [ET_NET 1][25855]: segfault at c ip
> 0058e083 sp 2b0a2982b740 error 6
> Jul 2 13:59:56 l2 kernel: [ET_NET 3][25857]: segfault at 84 ip
> 0058e083 sp 2b0a29a31740 error 6 in traffic_server[40+34]
> Jul 2 13:59:56 l2 kernel: in traffic_server[40+34]
> Jul 2 14:02:59 l2 traffic_cop[25901]: (test) read timeout [18 ]
> Jul 2 14:02:59 l2 traffic_cop[25901]: server heartbeat failed [1]
> Jul 2 14:03:08 l2 traffic_manager[25826]: {0x7f3f088607e0} FATAL:
> [LocalManager::pollMgmtProcessServer] Error in read (errno: 104)
> Jul 2 14:03:09 l2 traffic_manager[25826]: {0x7f3f088607e0} FATAL: (last
> system error 104: Connection reset by peer)
> Jul 2 14:03:09 l2 traffic_cop[25901]: cannot find traffic_server [1]
> Jul 2 14:03:09 l2 traffic_manager[25826]: {0x7f3f088607e0} ERROR:
> [LocalManager::sendMgmtMsgToProcesses] Error writing message
> Jul 2 14:03:09 l2 traffic_manager[25826]: {0x7f3f088607e0} ERROR: (last
> system error 32: Broken pipe)
> Jul 2 14:03:12 l2 traffic_cop[25901]: cop received child status signal
> [25826 35584]
> Jul 2 14:03:12 l2 traffic_cop[25901]: traffic_manager not running, making
> sure traffic_server is dead
> Jul 2 14:03:12 l2 traffic_cop[25901]: spawning traffic_manager
> Jul 2 14:03:13 l2 traffic_manager[18267]: NOTE: --- Manager Starting ---
> Jul 2 14:03:13 l2 traffic_manager[18267]: NOTE: Manager Version: Apache
> Traffic Server - traffic_manager - 3.2.0 - (build # 52518 on Jun 25 2012 at
> 18:22:12)
> Jul 2 14:03:13 l2 traffic_manager[18267]: {0x7fe63de3f7e0} STATUS: opened
> /home/y/logs/trafficserver/manager.log
> Jul 2 14:03:15 l2 traffic_server[18322]: NOTE: --- Server Starting ---
> Jul 2 14:03:15 l2 traffic_server[18322]: NOTE: Server Version: Apache
> Traffic Server - traffic_server - 3.2.0 - (build # 52518 on Jun 25 2012 at
> 18:22:31)
> Jul 2 14:03:15 l2 traffic_server[18322]: {0x2b77573ab860} STATUS: opened
> /home/y/logs/trafficserver/diags.log
> Jul 2 14:03:15 l2 traffic_server[18322]: {0x2b77573ab860} ERROR: Cannot
> insert duplicate!
> Jul 2 14:03:22 l2 traffic_cop[25901]: server heartbeat succeeded
> [Jul 2 13:56:56.304] Server {0x2b0a391e1700} ERROR:
> [SSL_NetVConnection::ssl_read_from_net] SSL_ERROR_SYSCALL, underlying IO
> error: Connection reset by peer
> NOTE: Traffic Server received Sig 11: Segmentation fault
> NOTE: Traffic Server received Sig 11: Segmentation fault
> /home/y/bin/traffic_server - STACK TRACE:
> /home/y/bin/traffic_server - STACK TRACE:
> /lib64/libpthread.so.0[0x3b54e0f4a0]
> /lib64/libpthread.so.0[0x3b54e0f4a0]
> /home/y/bin/traffic_server(_ZN9LogBuffer14checkout_writeEPmm+0x153)[0x58e083]
> /home/y/bin/traffic_server(_ZN9LogObject15_checkout_writeEPmm+0xa8)[0x5a64c8]
> /home/y/bin/traffic_server(_ZN9LogObject3logEP9LogAccessPc+0x2f0)[0x5a7e30]
> /home/y/bin/traffic_server(_ZN9LogBuffer14checkout_writeEPmm+0x153)[0x58e083]
> /home/y/bin/traffic_server(_ZN9LogObject15_checkout_writeEPmm+0xa8)[0x5a64c8]
> /home/y/bin/traffic_server(_ZN9LogObject3logEP9LogAccessPc+0x2f0)[0x5a7e30]
> /home/y/bin/traffic_server(_ZN3Log6accessEP9LogAccess+0x146)[0x58f506]
> /home/y/bin/traffic_server(_ZN6HttpSM12update_statsEv+0x630)[0x526c50]
> /home/y/bin/traffic_server(_ZN3Log6accessEP9LogAccess+0x146)[0x58f506]
> /home/y/bin/traffic_server(_ZN6HttpSM9kill_thisEv+0x928)[0x52b548]
> /home/y/bin/traffic_server(_ZN6HttpSM12update_statsEv+0x630)[0x526c50]
> /home/y/bin/traffic_server(_ZN6HttpSM9kill_thisEv+0x928)[0x52b548]
> /home/y/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0x198)[0x52b868]
> /home/y/bin/traffic_server(_ZN10HttpTunnel12main_handlerEiPv+0xde)[0x56c3ee]
> /home/y/bin/traffic_server[0x6736a1]
> /home/y/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0x198)[0x52b868]
> /home/y/bin/traffic_server(_Z15write_to_net_ioP10NetHandlerP18UnixNetVConnectionP7EThread+0x847)[0x675517]
> /home/y/bin/traffic_server[0x672f81]
> /home/y/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x286)[0x66df96]
> /home/y/bin
[jira] [Assigned] (TS-1356) ability to set thread affinity to a cpu
[ https://issues.apache.org/jira/browse/TS-1356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach reassigned TS-1356: --- Assignee: Bryan Call Over to Bryan. > ability to set thread affinity to a cpu > --- > > Key: TS-1356 > URL: https://issues.apache.org/jira/browse/TS-1356 > Project: Traffic Server > Issue Type: New Feature > Components: Core >Affects Versions: 3.2.0 >Reporter: Bryan Call >Assignee: Bryan Call >Priority: Minor > Fix For: 3.3.1 > > > Use libnuma to set thread affinity to cpus -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-1320) Reading from SSL origin can starve sending data to client
[ https://issues.apache.org/jira/browse/TS-1320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-1320: - Assignee: Leif Hedstrom > Reading from SSL origin can starve sending data to client > - > > Key: TS-1320 > URL: https://issues.apache.org/jira/browse/TS-1320 > Project: Traffic Server > Issue Type: Bug > Components: Network >Affects Versions: 3.0.4 >Reporter: William Bardwell >Assignee: Leif Hedstrom >Priority: Minor > Fix For: 3.3.1 > > > When we had a fast connection doing SSL to an origin server, and a slower > connection to the client, and not very much CPU, the SSL VConn code would > start to spin reading data from the origin server, and not breaking out of > the loop at all to send data to the client. As a result the throughput to > the client would drop to zero and ATS would get a bit bigger. So my proposed > patch is to have the SSL VConn code not stay in its loop when it has some > data that it has read, this matches how non-SSL network VConn's work. My one > concern with this is that there might have been a good reason for that > looping, and that this might slow down cases when things are working properly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1316) ATS connection refused once cache direntries exhausted
[
https://issues.apache.org/jira/browse/TS-1316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1316:
--
Fix Version/s: (was: 3.3.1)
3.3.2
Moving out for now, we need to make sure that it treats running out of dirents
as if the cache was full and start evicting the oldest entries.
> ATS connection refused once cache direntries exhausted
> --
>
> Key: TS-1316
> URL: https://issues.apache.org/jira/browse/TS-1316
> Project: Traffic Server
> Issue Type: Bug
> Components: Cache
>Affects Versions: 3.2.0
> Environment: RHEL 6.2 x86_64
>Reporter: David Carlin
> Fix For: 3.3.2
>
>
> We had a pair of ATS 3.2.0 boxes that stopped passing traffic simultaneously.
> Here are the traffic.out msgs we saw on both boxes:
> [Jun 22 05:53:27.637] Server {0x2b6b6d9da700} WARNING: cache directory
> overflow on '/dev/dm-4' segment 36, purging...
> [Jun 22 05:56:05.542] Server {0x2b6b6d2d3700} WARNING: cache directory
> overflow on '/dev/dm-4' segment 85, purging...
> [Jun 22 05:56:07.434] Server {0x2b6b6d4d5700} WARNING: cache directory
> overflow on '/dev/dm-4' segment 71, purging...
> [Jun 22 05:58:24.743] Server {0x2b6b6d8d9700} WARNING: cache directory
> overflow on '/dev/dm-4' segment 33, purging...
> Those messages went on for a couple minutes, then traffic apparently ceased -
> our monitoring system saw connection refused for port 80 on ATS from then on.
> The connection refused state went on for many hours until ATS was restarted.
> There were no traffic_cop msgs in /var/log/messages indicating that the
> heartbeat failed.
> Here are the relevant ATS settings/stats:
> proxy.process.cache.bytes_total = 190690320384
> proxy.process.cache.direntries.total = 5817752
> proxy.config.cache.min_average_object_size = 32768
> We previously came up with proxy.config.cache.min_average_object_size by
> waiting for the cache to fill and dividing proxy.process.cache.bytes_used by
> proxy.process.cache.direntries.used - which equals about 34KB.
> We're assuming ATS ran out of direntries and it didn't handle this situation
> gracefully. As a possible workaround, I'm going to lower
> proxy.config.cache.min_average_object_size to 24KB.
> Thanks to Bryan Call for helping me troubleshoot this!
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1311) Range hit in cluster will crash server
[
https://issues.apache.org/jira/browse/TS-1311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1311:
--
Fix Version/s: (was: 3.3.1)
3.3.2
Moving out.
> Range hit in cluster will crash server
> --
>
> Key: TS-1311
> URL: https://issues.apache.org/jira/browse/TS-1311
> Project: Traffic Server
> Issue Type: Bug
> Components: Clustering, HTTP, Network
>Affects Versions: 3.3.0, 3.2.0
> Environment: cluster type 1, and range request hit, where the content
> is on the other hosts.
>Reporter: Zhao Yongming
> Fix For: 3.3.2
>
>
> with the changes in TS-475, the single ranged request will be handled by
> tunnel and pread. while this will crash in cluster env:
> {code}
> NOTE: Traffic Server received Sig 11: Segmentation fault
> /usr/bin/traffic_server - STACK TRACE:
> /lib64/libpthread.so.0[0x309f00f4a0]
> /usr/bin/traffic_server(HttpTunnel::consumer_handler(int,
> HttpTunnelConsumer*)+0x188)[0x555668]
> /usr/bin/traffic_server(HttpTunnel::main_handler(int, void*)+0x11d)[0x5554cd]
> /usr/bin/traffic_server[0x63fdab]
> /usr/bin/traffic_server(write_to_net_io(NetHandler*, UnixNetVConnection*,
> EThread*)+0x353)[0x643a13]
> /usr/bin/traffic_server(NetHandler::mainNetEvent(int, Event*)+0x2fe)[0x63befe]
> /usr/bin/traffic_server(EThread::process_event(Event*, int)+0xb4)[0x660a74]
> /usr/bin/traffic_server(EThread::execute()+0x4c3)[0x661403]
> /usr/bin/traffic_server[0x65fd82]
> /lib64/libpthread.so.0[0x309f0077f1]
> /lib64/libc.so.6(clone+0x6d)[0x309ece570d]
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1301) Expose the internal milestone timers via TSAPI
[
https://issues.apache.org/jira/browse/TS-1301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13586423#comment-13586423
]
Leif Hedstrom commented on TS-1301:
---
I will write a fucking man page.
> Expose the internal milestone timers via TSAPI
> --
>
> Key: TS-1301
> URL: https://issues.apache.org/jira/browse/TS-1301
> Project: Traffic Server
> Issue Type: New Feature
> Components: TS API
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 3.3.1
>
>
> I'm suggesting an API like:
> {code}
> tsapi TSHRTime TSHttpTxnMilestoneGet(TSHttpTxn txnp,
> TSMilestonesType milestone);
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1300) TSUrlStringGet appears to return incorrect URL for transparent HTTP requests
[ https://issues.apache.org/jira/browse/TS-1300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1300: -- Fix Version/s: (was: 3.3.1) 3.3.2 > TSUrlStringGet appears to return incorrect URL for transparent HTTP requests > > > Key: TS-1300 > URL: https://issues.apache.org/jira/browse/TS-1300 > Project: Traffic Server > Issue Type: Bug > Components: TS API >Affects Versions: 3.0.2 > Environment: Centos 6.2 >Reporter: Domhnall Wildy >Assignee: Alan M. Carroll > Fix For: 3.3.2 > > > We have a plugin that uses the TSUrlStringGet method to retrieve the request > URL. When running TS as a non-transparent proxy the value returned by > TSUrlStringGet is the full URL for example: > http://www.somewebsite.com/something.html > However if I send requests transparently the value returned is: > http:///something.html > So it looks as if the host is ignored when the URL string is initially > created. I just wanted to check here to see if this could be an issue? Or > could the usage of the method be incorrect? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1298) http_parser_parse_req appears inconsistent
[ https://issues.apache.org/jira/browse/TS-1298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1298: -- Fix Version/s: (was: 3.3.1) 3.3.2 > http_parser_parse_req appears inconsistent > -- > > Key: TS-1298 > URL: https://issues.apache.org/jira/browse/TS-1298 > Project: Traffic Server > Issue Type: Bug >Affects Versions: 3.0.2 >Reporter: Aidan McGurn > Fix For: 3.3.2 > > > when using IPT setup i test as follows: > 1. telnet 80 from client machine //this will be routed via ATS as > IPT env > 2. write "test" in telnet window and hit return > 3. i *correctly* get a PARSE ERROR inside HTTP.cc/http_parser_parse_req > 1051if (!method_start || !method_end) > (gdb) > 1052 return PARSE_ERROR; > (gdb) p method_end > $4 = 0x0 > (gdb) p method_start > $5 = 0x12741000 "test\r\n" > However of i repeat step 2, with "test 2" method_end gets set and i end up > with a PARSE_DONE and it thinks *INCORRECTLY* therefore this is a HTTP > request. > Assume this is a bug and we are missing validation here or is this making > assumption the request is correct HTTP header format? > thanks for any assistance, > /aidan -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1290) the init script patch in RPM
[ https://issues.apache.org/jira/browse/TS-1290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1290: -- Fix Version/s: (was: 3.3.1) 3.3.2 > the init script patch in RPM > > > Key: TS-1290 > URL: https://issues.apache.org/jira/browse/TS-1290 > Project: Traffic Server > Issue Type: Improvement > Components: Portability >Affects Versions: 3.3.0 >Reporter: Zhao Yongming >Assignee: Zhao Yongming >Priority: Minor > Fix For: 3.3.2 > > > we have a patch in the RPM, should we put it in the git master? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1187) TSMimeHdrFieldNameSet does not work for headers read from the client or origin server (but does work for headers added by traffic server)
[ https://issues.apache.org/jira/browse/TS-1187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13586402#comment-13586402 ] James Peach commented on TS-1187: - And if it doesn't set the header, it should return ERROR. > TSMimeHdrFieldNameSet does not work for headers read from the client or > origin server (but does work for headers added by traffic server) > - > > Key: TS-1187 > URL: https://issues.apache.org/jira/browse/TS-1187 > Project: Traffic Server > Issue Type: Bug > Components: MIME >Affects Versions: 3.0.2 > Environment: Redhat linux with plugin that wants to rename a header > read from the client. >Reporter: Alistair Stevenson > Labels: api-change > Fix For: sometime > > > TSMimeHdrFieldNameSet does not work for headers read from the client or > origin server (but does work for headers added by traffic server) > The name appears set (and the function returns SUCCESS) but when the data is > sent to the origin Server it is corrupted at the point where the header is > set. i.e the header name is sent but the header is corrupted after this. > I am having to create a new header and copy the values and then destroy the > original header which is not as efficient. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-1285) dir entries stats sounds broken
[
https://issues.apache.org/jira/browse/TS-1285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom resolved TS-1285.
---
Resolution: Fixed
Fix Version/s: (was: 3.3.1)
I can't reproduce this, if this is still an issue, please reopen.
> dir entries stats sounds broken
> ---
>
> Key: TS-1285
> URL: https://issues.apache.org/jira/browse/TS-1285
> Project: Traffic Server
> Issue Type: Bug
> Components: Cache
>Affects Versions: 3.1.4
>Reporter: Zhao Yongming
>
> the issue is report from our 3.0.x codes, maybe we can see from the git
> master too.
> the .used is great than .total, which should not happen in any way :D
> {code}
> [yonghao@cache161 ~]$ links -dump http://localhost:8080/stat/ |grep diren
> proxy.process.cache.direntries.total=290736856
> proxy.process.cache.direntries.used=654103062
> proxy.process.cache.volume_1.direntries.total=8713860
> proxy.process.cache.volume_1.direntries.used=0
> proxy.process.cache.volume_2.direntries.total=20349264
> proxy.process.cache.volume_2.direntries.used=0
> proxy.process.cache.volume_255.direntries.total=261673732
> proxy.process.cache.volume_255.direntries.used=654103062
> [yonghao@cache161 ~]$
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1290) the init script patch in RPM
[ https://issues.apache.org/jira/browse/TS-1290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13586397#comment-13586397 ] James Peach commented on TS-1290: - Where is this patch? > the init script patch in RPM > > > Key: TS-1290 > URL: https://issues.apache.org/jira/browse/TS-1290 > Project: Traffic Server > Issue Type: Improvement > Components: Portability >Affects Versions: 3.3.0 >Reporter: Zhao Yongming >Assignee: Zhao Yongming >Priority: Minor > Fix For: 3.3.1 > > > we have a patch in the RPM, should we put it in the git master? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1263) owner of mgmtapisocket can change if not compiling with libcap
[ https://issues.apache.org/jira/browse/TS-1263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1263: -- Fix Version/s: (was: 3.3.1) sometime Assignee: (was: Bryan Call) Moving out. > owner of mgmtapisocket can change if not compiling with libcap > -- > > Key: TS-1263 > URL: https://issues.apache.org/jira/browse/TS-1263 > Project: Traffic Server > Issue Type: Bug > Components: Management >Affects Versions: 3.1.3 >Reporter: Bryan Call > Fix For: sometime > > > Sometimes the ownership of mgmtapisocket is nobody and sometimes it is root. > This is only seen if you don't link with libcap. > The thread that creates the unix-socket (mgmtapisocket) is created before ATS > binds its ports. There is a race between seteuid() called from > restoreRootPriv() before we bind() the sockets and the creation of the > unix-socket in the "web agent thread". > If ATS binds the ports before the thread is created that creates > mgmtapisocket then the proper ownership of mgmtapisocket happens (owned by > nobody). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1155) POST requests that are chunked encoding hang when going forward to origin over SSL
[ https://issues.apache.org/jira/browse/TS-1155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13586383#comment-13586383 ] ASF subversion and git services commented on TS-1155: - Commit 93e14b254b5a2a834f708cff71fa8dd7223791d3 in branch refs/heads/master from James Peach [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=93e14b2 ] TS-1155: POST requests that are chunked encoding hang when going forward to origin over SSL > POST requests that are chunked encoding hang when going forward to origin > over SSL > -- > > Key: TS-1155 > URL: https://issues.apache.org/jira/browse/TS-1155 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Affects Versions: 3.0.2 >Reporter: William Bardwell >Assignee: James Peach > Fix For: 3.3.1 > > > If you make a chunked encoded POST request, e.g.: > curl -H "Transfer-Encoding: chunked" -d@/etc/ca-certificates.conf > http://example.com/cgi-bin/cgi.pl > Where ATS is going forward to the origin over SSL, it junk hangs for a little > while and ends up returning a 502 response. > The problem seems to be code at proxy/http/HttpTransact.cc:5273 which only > checks for chunked encoding when the scheme is http. Just removing the extra > scheme check makes it work for me. > I don't know why it has that check, especially since it is checking for http > or https right before that. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1255) Add more overridable records.config configurations
[
https://issues.apache.org/jira/browse/TS-1255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1255:
--
Fix Version/s: (was: 3.3.1)
3.3.2
> Add more overridable records.config configurations
> --
>
> Key: TS-1255
> URL: https://issues.apache.org/jira/browse/TS-1255
> Project: Traffic Server
> Issue Type: Improvement
> Components: TS API
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 3.3.2
>
>
> We should examine at least the following configs, and see which ones can (or
> can not) be moved to be overridable:
> {code}
> MgmtInt server_max_connections;
> MgmtInt origin_min_keep_alive_connections; // TODO: This one really ought
> to be overridable, but difficult right now.
> char *proxy_request_via_string;
> int proxy_request_via_string_len;
> char *proxy_response_via_string;
> int proxy_response_via_string_len;
> MgmtInt origin_server_pipeline;
> MgmtInt user_agent_pipeline;
> MgmtInt transaction_active_timeout_in;
> MgmtInt accept_no_activity_timeout;
> MgmtInt background_fill_active_timeout;
> MgmtFloat background_fill_threshold;
> MgmtInt parent_connect_attempts;
> MgmtInt per_parent_connect_attempts;
> MgmtInt parent_connect_timeout;
> MgmtByte insert_age_in_response;
> MgmtByte avoid_content_spoofing;
> MgmtByte enable_http_stats;
> MgmtInt max_cache_open_write_retries;
> MgmtByte cache_enable_default_vary_headers;
> MgmtByte cache_when_to_add_no_cache_to_msie_requests;
> MgmtByte cache_range_lookup;
> MgmtInt request_hdr_max_size;
> MgmtInt response_hdr_max_size;
> MgmtByte push_method_enabled;
> MgmtByte referer_filter_enabled;
> MgmtByte referer_format_redirect;
> MgmtByte accept_encoding_filter_enabled;
> // WTF!!! Bool ???
> /// Accept connections on foreign addresses.
> bool client_transparency_enabled;
> /// Use client address to connect to origin server.
> bool server_transparency_enabled;
> MgmtByte negative_revalidating_enabled;
> MgmtInt negative_revalidating_lifetime;
> MgmtByte ignore_accept_mismatch;
> MgmtByte ignore_accept_language_mismatch;
> MgmtByte ignore_accept_encoding_mismatch;
> MgmtByte ignore_accept_charset_mismatch;
>
> // Optimize gzip alternates //
>
> MgmtByte normalize_ae_gzip;
> {code}
> Marking this for v3.3.0, it'd be nice to get into 3.2, but I rather have us
> just get 3.1.4/3.2 done sooner rather than later.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1187) TSMimeHdrFieldNameSet does not work for headers read from the client or origin server (but does work for headers added by traffic server)
[ https://issues.apache.org/jira/browse/TS-1187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1187: -- Fix Version/s: (was: 3.3.1) sometime > TSMimeHdrFieldNameSet does not work for headers read from the client or > origin server (but does work for headers added by traffic server) > - > > Key: TS-1187 > URL: https://issues.apache.org/jira/browse/TS-1187 > Project: Traffic Server > Issue Type: Bug > Components: MIME >Affects Versions: 3.0.2 > Environment: Redhat linux with plugin that wants to rename a header > read from the client. >Reporter: Alistair Stevenson > Labels: api-change > Fix For: sometime > > > TSMimeHdrFieldNameSet does not work for headers read from the client or > origin server (but does work for headers added by traffic server) > The name appears set (and the function returns SUCCESS) but when the data is > sent to the origin Server it is corrupted at the point where the header is > set. i.e the header name is sent but the header is corrupted after this. > I am having to create a new header and copy the values and then destroy the > original header which is not as efficient. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1187) TSMimeHdrFieldNameSet does not work for headers read from the client or origin server (but does work for headers added by traffic server)
[ https://issues.apache.org/jira/browse/TS-1187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13586379#comment-13586379 ] Leif Hedstrom commented on TS-1187: --- It sounds like what you want is a TSMimeHdrFieldRename(), I'm moving this out for now. As James points out, it is odd that it works for some headers, but not others. > TSMimeHdrFieldNameSet does not work for headers read from the client or > origin server (but does work for headers added by traffic server) > - > > Key: TS-1187 > URL: https://issues.apache.org/jira/browse/TS-1187 > Project: Traffic Server > Issue Type: Bug > Components: MIME >Affects Versions: 3.0.2 > Environment: Redhat linux with plugin that wants to rename a header > read from the client. >Reporter: Alistair Stevenson > Labels: api-change > Fix For: 3.3.1 > > > TSMimeHdrFieldNameSet does not work for headers read from the client or > origin server (but does work for headers added by traffic server) > The name appears set (and the function returns SUCCESS) but when the data is > sent to the origin Server it is corrupted at the point where the header is > set. i.e the header name is sent but the header is corrupted after this. > I am having to create a new header and copy the values and then destroy the > original header which is not as efficient. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-1155) POST requests that are chunked encoding hang when going forward to origin over SSL
[ https://issues.apache.org/jira/browse/TS-1155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-1155: - Assignee: James Peach > POST requests that are chunked encoding hang when going forward to origin > over SSL > -- > > Key: TS-1155 > URL: https://issues.apache.org/jira/browse/TS-1155 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Affects Versions: 3.0.2 >Reporter: William Bardwell >Assignee: James Peach > Fix For: 3.3.1 > > > If you make a chunked encoded POST request, e.g.: > curl -H "Transfer-Encoding: chunked" -d@/etc/ca-certificates.conf > http://example.com/cgi-bin/cgi.pl > Where ATS is going forward to the origin over SSL, it junk hangs for a little > while and ends up returning a 502 response. > The problem seems to be code at proxy/http/HttpTransact.cc:5273 which only > checks for chunked encoding when the scheme is http. Just removing the extra > scheme check makes it work for me. > I don't know why it has that check, especially since it is checking for http > or https right before that. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1118) Modify how we manage the cache key / MD5 / lookup_url in the CacheSM / HttpSM.
[ https://issues.apache.org/jira/browse/TS-1118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1118: -- Fix Version/s: (was: 3.3.1) 3.3.2 > Modify how we manage the cache key / MD5 / lookup_url in the CacheSM / HttpSM. > -- > > Key: TS-1118 > URL: https://issues.apache.org/jira/browse/TS-1118 > Project: Traffic Server > Issue Type: New Feature > Components: Core >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom > Fix For: 3.3.2 > > > I'd like to make the core simpler, and more efficient, dealing with the cache > keys. We have APIs today to modify the cache URL (lookup_url), but it's > incredibly inefficient. I'll post more details on my ideas here when I have > it all written down. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1106) redirect map generates multiple Via: header entries.
[
https://issues.apache.org/jira/browse/TS-1106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1106:
--
Fix Version/s: (was: 3.3.1)
3.3.2
Assignee: Leif Hedstrom
> redirect map generates multiple Via: header entries.
>
>
> Key: TS-1106
> URL: https://issues.apache.org/jira/browse/TS-1106
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
>Affects Versions: 3.1.2
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 3.3.2
>
>
> It seems using the redirect rule in remap.config, ends up duplicating the
> entry in the Via: header, e.g.
> {code}
> Via: http/1.1 kramer.ogre.com (ApacheTrafficServer/3.1.3-unstable [u c s f p
> eS:tNc i p s ]), http/1.1 kramer.ogre.com
> (ApacheTrafficServer/3.1.3-unstable [u c s f p eS:tNc i p s ])
> {code}
> I'm not sure why this happens, if it's duplicating it, or if it's going
> through the SM twice. I know i'm not proxying twice through the box.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1086) Returning 304 response to unconditional request
[ https://issues.apache.org/jira/browse/TS-1086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1086: -- Fix Version/s: (was: 3.3.1) 3.3.2 Moving this out to 3.3.2. > Returning 304 response to unconditional request > --- > > Key: TS-1086 > URL: https://issues.apache.org/jira/browse/TS-1086 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Affects Versions: 3.0.1 > Environment: Observed on Amazon/ec2 build, which is 3.0.1 on > redhat-like linux. >Reporter: Nick Kew > Fix For: 3.3.2 > > > ab is reporting HTTP 304 responses to a small number of unconditional > requests in a test run: > GET /testfile.html HTTP/1.0^M > Host: localhost^M > User-Agent: ApacheBench/2.3^M > Accept: */*^M > ^M > HTTP/1.0 304 Not Modified^M > Date: Mon, 21 Nov 2011 14:23:48 GMT^M > Server: ATS/3.0.1^M > ETag: "5e24-24cd-4b23b69f6e89c"^M > Cache-Control: max-age=60^M > Age: 2^M > ^M > I presume what's happening is that trafficserver is sending a conditional > request with If-Modified-Since to the origin server, and then returning the > origin's 304 response to the client's unconditional request. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1058) Intercept an HTTP client's request
[
https://issues.apache.org/jira/browse/TS-1058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13586361#comment-13586361
]
James Peach commented on TS-1058:
-
Yakov, we discussed this bug and I think we understand this issue.
Fundamentally, you need a more convenient API to set the response body. I think
that the right approach is to fix TSHttpTxnSetHttpRetBody() so that it can be
used in a global plugin. Then you would not have to use TSHttpTxnErrorBodySet()
and the problem of closing the connection would not arise.
I suggest TSHttpTxnSetHttpResponseBody(TSHttpTxn txnp, char* buf, int
buflength, char* mimetype), which is consistent with the signature of
TSHttpTxnErrorBodySet().
> Intercept an HTTP client's request
> --
>
> Key: TS-1058
> URL: https://issues.apache.org/jira/browse/TS-1058
> Project: Traffic Server
> Issue Type: Bug
> Components: TS API
>Affects Versions: 3.1.1
>Reporter: Yakov Kopel
>Assignee: Leif Hedstrom
> Labels: patch
> Fix For: 3.3.1
>
> Attachments: patch.diff
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> I want that the trafficserver will give the client the response instead of
> the server.
> The trafficserver offers the INKHttpTxnIntercept api to do so, but it is not
> so convenience to use it.
> I want to use the regular flow of the trafficserver, and its regular parsing
> commands.
> The trafficserver's plugins examples also aren't using the
> INKHttpTxnIntercept , but they rather using the "rasing error" method, and
> then they response the request at the response hook.
> So, this is whta i did.
> On the global-hook at the TS_EVENT_HTTP_READ_REQUEST_HDR i raised
> TS_EVENT_HTTP_ERROR.
> I also added TS_HTTP_SEND_RESPONSE_HDR_HOOK and there i returned http
> response with the KEEP-ALIVE header.
> The problem is that the trafficserver is closing the connection although i
> added to the response the KEEP-ALIVE header.
>
> When the Trafficserver is trying to send response to the client, it terminate
> the session after it.
> Although I added the "KEEP-ALIVE" mime field - it didn't work.
> The debug dump is looking like this:
> [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http) [4]
> [&HttpSM::state_api_callback, HTTP_API_CONTINUE]
> [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http) [4]
> [&HttpSM::state_api_callout, HTTP_API_CONTINUE]
> [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_redirect)
> [HttpSM::do_redirect]
> [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_redirect)
> [HttpTunnel::deallocate_postdata_copy_buffers]
> [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_tunnel) [4]
> adding producer 'internal msg'
> [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_tunnel) [4]
> adding consumer 'user agent'
> [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_tunnel)
> tunnel_run started, p_arg is NULL
> [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_tunnel) [4]
> consumer_handler [user agent VC_EVENT_WRITE_COMPLETE]
> [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http) [4]
> [&HttpSM::tunnel_handler_ua, VC_EVENT_WRITE_COMPLETE]
> [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_cs) [4] session
> closed
> [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_cs) [4] session
> destroy
> [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http) [4]
> [HttpSM::main_handler, HTTP_TUNNEL_EVENT_DONE]
> [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http) [4]
> [&HttpSM::tunnel_handler, HTTP_TUNNEL_EVENT_DONE]
> [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_redirect)
> [HttpTunnel::deallocate_postdata_copy_buffers]
> [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http) [4] calling
> plugin on hook TS_HTTP_TXN_CLOSE_HOOK at hook 0x3B97610
> The Solution:
> I'm adding a patch of functino that rasing the internal flag of KEEP-ALIVE,
> so the trafficserver will realy believe us that we want to keep this
> connection alive :)
> Example for the usage of the new function:
> // Tell the trafficserver to not close this connection (keep-alive)
> TSHttpTxnCloseAfterResponse(txnp, 0);
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1058) Intercept an HTTP client's request
[
https://issues.apache.org/jira/browse/TS-1058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach updated TS-1058:
Fix Version/s: (was: 3.3.1)
3.3.2
> Intercept an HTTP client's request
> --
>
> Key: TS-1058
> URL: https://issues.apache.org/jira/browse/TS-1058
> Project: Traffic Server
> Issue Type: Bug
> Components: TS API
>Affects Versions: 3.1.1
>Reporter: Yakov Kopel
>Assignee: Leif Hedstrom
> Labels: patch
> Fix For: 3.3.2
>
> Attachments: patch.diff
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> I want that the trafficserver will give the client the response instead of
> the server.
> The trafficserver offers the INKHttpTxnIntercept api to do so, but it is not
> so convenience to use it.
> I want to use the regular flow of the trafficserver, and its regular parsing
> commands.
> The trafficserver's plugins examples also aren't using the
> INKHttpTxnIntercept , but they rather using the "rasing error" method, and
> then they response the request at the response hook.
> So, this is whta i did.
> On the global-hook at the TS_EVENT_HTTP_READ_REQUEST_HDR i raised
> TS_EVENT_HTTP_ERROR.
> I also added TS_HTTP_SEND_RESPONSE_HDR_HOOK and there i returned http
> response with the KEEP-ALIVE header.
> The problem is that the trafficserver is closing the connection although i
> added to the response the KEEP-ALIVE header.
>
> When the Trafficserver is trying to send response to the client, it terminate
> the session after it.
> Although I added the "KEEP-ALIVE" mime field - it didn't work.
> The debug dump is looking like this:
> [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http) [4]
> [&HttpSM::state_api_callback, HTTP_API_CONTINUE]
> [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http) [4]
> [&HttpSM::state_api_callout, HTTP_API_CONTINUE]
> [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_redirect)
> [HttpSM::do_redirect]
> [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_redirect)
> [HttpTunnel::deallocate_postdata_copy_buffers]
> [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_tunnel) [4]
> adding producer 'internal msg'
> [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_tunnel) [4]
> adding consumer 'user agent'
> [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_tunnel)
> tunnel_run started, p_arg is NULL
> [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_tunnel) [4]
> consumer_handler [user agent VC_EVENT_WRITE_COMPLETE]
> [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http) [4]
> [&HttpSM::tunnel_handler_ua, VC_EVENT_WRITE_COMPLETE]
> [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_cs) [4] session
> closed
> [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_cs) [4] session
> destroy
> [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http) [4]
> [HttpSM::main_handler, HTTP_TUNNEL_EVENT_DONE]
> [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http) [4]
> [&HttpSM::tunnel_handler, HTTP_TUNNEL_EVENT_DONE]
> [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_redirect)
> [HttpTunnel::deallocate_postdata_copy_buffers]
> [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http) [4] calling
> plugin on hook TS_HTTP_TXN_CLOSE_HOOK at hook 0x3B97610
> The Solution:
> I'm adding a patch of functino that rasing the internal flag of KEEP-ALIVE,
> so the trafficserver will realy believe us that we want to keep this
> connection alive :)
> Example for the usage of the new function:
> // Tell the trafficserver to not close this connection (keep-alive)
> TSHttpTxnCloseAfterResponse(txnp, 0);
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-935) Should EVENT_INTERNAL really be the same as TS_EVENT_TIMEOUT
[ https://issues.apache.org/jira/browse/TS-935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13586347#comment-13586347 ] Brian Geffon commented on TS-935: - It's a bug, TSContCall with TS_EVENT_IMMEDIATE will cause a segfault because the event count goes negative. I'll look at it tomorrow when I'm up in portland. > Should EVENT_INTERNAL really be the same as TS_EVENT_TIMEOUT > > > Key: TS-935 > URL: https://issues.apache.org/jira/browse/TS-935 > Project: Traffic Server > Issue Type: Bug > Components: TS API >Affects Versions: 3.0.1 >Reporter: Brian Geffon >Assignee: Brian Geffon > Fix For: 3.3.3 > > > When trying to use TSContCall with event = TS_EVENT_TIMEOUT I stumbled upon > the fact that the API will decrement the event count for EVENT_INTERNAL or > EVENT_IMMEDIATE (see INKContInternal::handle_event_count), but shouldn't we > be able to do a TSContCall with TS_EVENT_IMMEDIAITE or TS_EVENT_TIMEOUT > because as of now doing so would cause m_event_count to become -1 or > shouldn't these defined values be something different? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-980) change client_session schedule from global to thread local, and reduce the try_locks in UnixNetVConnection::reenable
[
https://issues.apache.org/jira/browse/TS-980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-980:
-
Fix Version/s: (was: 3.3.1)
3.3.2
Weijin, you and I need to sit down and discuss this, and figure out what to do
here :).
> change client_session schedule from global to thread local, and reduce the
> try_locks in UnixNetVConnection::reenable
> -
>
> Key: TS-980
> URL: https://issues.apache.org/jira/browse/TS-980
> Project: Traffic Server
> Issue Type: Improvement
> Components: Network, Performance
>Affects Versions: 3.1.0, 3.0.0
> Environment: all
>Reporter: weijin
>Assignee: weijin
> Fix For: 3.3.2
>
> Attachments: ts-980.diff
>
>
> I did some performance test on ats last days(disable cache, set share_server
> session 2, pure proxy mode), I did see significant improvement on low load,
> but it dropped rapidly when load is high. meanwhile, some stability problems
> happened. Through gdb, I found the client_session`s mutex can be acquired by
> two or more threads, I believe some schedules happened during the sm
> life_time. May be we need do some work to find these eventProcessor.schedules
> and change them to thread schedules.
> UnixVConnecton::reenable {
> if (nh->mutex->thread_holding == t) {
> // put into ready_list
> } else {
>MUTEX_TRY_LOCK(lock, nh->mutex, t);
>if (!lock) {
> // put into enable_list;
>} else {
> // put into ready_list;
>}
> }
> remove UnixNetVConnection::reenable try_lock operations, 3 reasons
> 1. try_lock operation means obj allocation and deallocation operation.
> frequently
> 2. try_lock hardly can lock the net-handler`s mutex.(net-handler is schedule
> by as soon as possible)
> 3. try_lock should not acquire the net-handler`s mutex. That may lead more
> net io latency if it is an epoll event need to be processed in other threads.
> If it is not an epoll event(time event), I don`t think putting vc in
> ready_list has any advantage than in enable_list.
> may be we can change reenale function like this:
> UnixVConnecton::reenable {
> if (nh->mutex->thread_holding == t) {
> // put into ready_list;
> } else {
> // put into enable_list;
> }
> my buddies, any advice?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-977) RecCore usage cleanup
[
https://issues.apache.org/jira/browse/TS-977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13586330#comment-13586330
]
James Peach commented on TS-977:
ming_zym: can you please commit these patches?
> RecCore usage cleanup
> -
>
> Key: TS-977
> URL: https://issues.apache.org/jira/browse/TS-977
> Project: Traffic Server
> Issue Type: Task
> Components: Cleanup
>Reporter: Zhao Yongming
>Assignee: Zhao Yongming
>Priority: Minor
> Fix For: 3.3.1
>
> Attachments:
> 0001-RecCore-refine-P_RecCore.i-and-rename-it-to-P_RecCor.patch,
> 0002-RecCore-remove-unnecessary-IOCORE_-wrapper-on-RecCor.patch,
> 0003-TS-977-Fix-RecMessageSend-regression.patch
>
>
> in RecCore.*
> {code}
> int RecGetRecordInt(const char *name, RecInt * rec_int, bool lock = true);
> //-
> // RecGetRecordXXX
> //-
> int
> RecGetRecordInt(const char *name, RecInt *rec_int, bool lock)
> {
> int err;
> RecData data;
> if ((err = RecGetRecord_Xmalloc(name, RECD_INT, &data, lock)) ==
> REC_ERR_OKAY)
> *rec_int = data.rec_int;
> return err;
> }
> {code}
> and there is something heavy used:
> {code}
> //-
> // Backwards Compatibility Items (REC_ prefix)
> //-
> #define REC_ReadConfigInt32(_var,_config_var_name) do { \
> RecInt tmp = 0; \
> RecGetRecordInt(_config_var_name, (RecInt*) &tmp); \
> _var = (int32_t)tmp; \
> } while (0)
> #define REC_ReadConfigInteger(_var,_config_var_name) do { \
> RecInt tmp = 0; \
> RecGetRecordInt(_config_var_name, &tmp); \
> _var = tmp; \
> } while (0)
> {code}
> and a real case, the REC_ReadConfigInteger is renamed to
> IOCORE_ReadConfigInteger:
> {code}
> RecInt cache_config_threads_per_disk = 12;
> #define IOCORE_ReadConfigIntegerREC_ReadConfigInteger
> IOCORE_ReadConfigInteger(cache_config_threads_per_disk,
> "proxy.config.cache.threads_per_disk");
> {code}
> my question is, why it is so complex in all these renaming? why not just:
> {code}
> RecGetRecordInt("proxy.config.cache.threads_per_disk",
> &cache_config_threads_per_disk);
> {code}
> brief talk with Leif, we may need to cleanup the use of REC_*. make it a
> small task here
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-935) Should EVENT_INTERNAL really be the same as TS_EVENT_TIMEOUT
[ https://issues.apache.org/jira/browse/TS-935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-935: - Fix Version/s: (was: 3.3.1) 3.3.3 Wtf Brian, what does this mean? Should we fix it? > Should EVENT_INTERNAL really be the same as TS_EVENT_TIMEOUT > > > Key: TS-935 > URL: https://issues.apache.org/jira/browse/TS-935 > Project: Traffic Server > Issue Type: Bug > Components: TS API >Affects Versions: 3.0.1 >Reporter: Brian Geffon >Assignee: Brian Geffon > Fix For: 3.3.3 > > > When trying to use TSContCall with event = TS_EVENT_TIMEOUT I stumbled upon > the fact that the API will decrement the event count for EVENT_INTERNAL or > EVENT_IMMEDIATE (see INKContInternal::handle_event_count), but shouldn't we > be able to do a TSContCall with TS_EVENT_IMMEDIAITE or TS_EVENT_TIMEOUT > because as of now doing so would cause m_event_count to become -1 or > shouldn't these defined values be something different? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-871) Subversion (1.7) with serf fails with ATS in forward and reverse proxy mode
[
https://issues.apache.org/jira/browse/TS-871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13586324#comment-13586324
]
Leif Hedstrom commented on TS-871:
--
If fixing the payload issues doesn't resolve all the Subversion problems,
please move this bug out to 3.3.2 or 3.3.3. Last I tested, fixing the payload
issue was not quite enough.
> Subversion (1.7) with serf fails with ATS in forward and reverse proxy mode
> ---
>
> Key: TS-871
> URL: https://issues.apache.org/jira/browse/TS-871
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
>Affects Versions: 3.0.0
>Reporter: Igor Galić
>Assignee: Bryan Call
> Fix For: 3.3.1
>
> Attachments: ats_Thttp.debug.notime.txt, ats_Thttp.debug.txt,
> revats_Thttp.debug.notime.txt, revats_Thttp.debug.txt, serf_proxy.cap,
> serf_revproxy.cap, stats.diff, TS-871-20121107.diff, TS-871.diff
>
>
> When accessing a remote subversion repository via http or https with svn 1.7,
> it will currently timeout:
> {noformat}
> igalic@tynix ~/src/asf % svn co
> http://svn.apache.org/repos/asf/trafficserver/plugins/stats_over_http/
> svn: E020014: Unable to connect to a repository at URL
> 'http://svn.apache.org/repos/asf/trafficserver/plugins/stats_over_http'
> svn: E020014: Unspecified error message: 504 Connection Timed Out
> 1 igalic@tynix ~/src/asf %
> {noformat}
> I have started traffic_server -Thttp and captured the output, which I'm
> attaching.
> There's also a capture from the network.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-871) Subversion (1.7) with serf fails with ATS in forward and reverse proxy mode
[
https://issues.apache.org/jira/browse/TS-871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-871:
-
Assignee: Bryan Call (was: Leif Hedstrom)
Also see TS-1627. To test this, edit .subversion/servers, and add e.g.
[global]
http-proxy-host = localhost
http-proxy-port = 80
> Subversion (1.7) with serf fails with ATS in forward and reverse proxy mode
> ---
>
> Key: TS-871
> URL: https://issues.apache.org/jira/browse/TS-871
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
>Affects Versions: 3.0.0
>Reporter: Igor Galić
>Assignee: Bryan Call
> Fix For: 3.3.1
>
> Attachments: ats_Thttp.debug.notime.txt, ats_Thttp.debug.txt,
> revats_Thttp.debug.notime.txt, revats_Thttp.debug.txt, serf_proxy.cap,
> serf_revproxy.cap, stats.diff, TS-871-20121107.diff, TS-871.diff
>
>
> When accessing a remote subversion repository via http or https with svn 1.7,
> it will currently timeout:
> {noformat}
> igalic@tynix ~/src/asf % svn co
> http://svn.apache.org/repos/asf/trafficserver/plugins/stats_over_http/
> svn: E020014: Unable to connect to a repository at URL
> 'http://svn.apache.org/repos/asf/trafficserver/plugins/stats_over_http'
> svn: E020014: Unspecified error message: 504 Connection Timed Out
> 1 igalic@tynix ~/src/asf %
> {noformat}
> I have started traffic_server -Thttp and captured the output, which I'm
> attaching.
> There's also a capture from the network.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1627) Support requests with payload
[ https://issues.apache.org/jira/browse/TS-1627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1627: -- Assignee: Bryan Call (was: Leif Hedstrom) Also see bug TS-871. > Support requests with payload > - > > Key: TS-1627 > URL: https://issues.apache.org/jira/browse/TS-1627 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Affects Versions: 3.3.0 >Reporter: Uri Shachar >Assignee: Bryan Call > Fix For: 3.3.1 > > Attachments: get_with_payload.patch, requests_with_content.patch > > > From what I understand from RFC 2616, these requests should be legal. ATS > currently accepts these requests, but drops the body when passing them onward > to the upstream. > Most discussion that I could find on the web say that this is legal -- > although what the upstream can actually do with the payload isn't clear > http://lists.w3.org/Archives/Public/ietf-http-wg/2006AprJun/0096.html > http://tech.groups.yahoo.com/group/rest-discuss/message/9957 > http://stackoverflow.com/questions/978061/http-get-with-request-body > http://dret.typepad.com/dretblog/2007/10/http-get-with-m.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1604) Request body gets stripped from DELETE
[ https://issues.apache.org/jira/browse/TS-1604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-1604: Summary: Request body gets stripped from DELETE (was: Request body gets stripped from ) > Request body gets stripped from DELETE > -- > > Key: TS-1604 > URL: https://issues.apache.org/jira/browse/TS-1604 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Affects Versions: 3.2.0 >Reporter: Mathias Biilmann Christensen > > Traffic Server strips the request body from DELETE requests, while leaving > the Content-Length header intact. > Ideally Traffic Server should preserve the request body if a Content-Length > header is present. There's nothing explicitly forbidding request bodys for > DELETE requests in the HTTP spec. > If the body is stripped, the Content-Length header should be removed as well, > otherwise backend servers might hang while waiting for the request body. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-866) Need way to clear contents of a cache entry
[ https://issues.apache.org/jira/browse/TS-866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-866: - Fix Version/s: (was: 3.3.1) sometime Assignee: William Bardwell Moving this out to later, and assigning to you William :). It sounds like it needs a little more work. > Need way to clear contents of a cache entry > --- > > Key: TS-866 > URL: https://issues.apache.org/jira/browse/TS-866 > Project: Traffic Server > Issue Type: New Feature > Components: Cache >Affects Versions: 3.0.0 >Reporter: William Bardwell >Assignee: William Bardwell >Priority: Minor > Fix For: sometime > > Attachments: cache_erase.diff > > > I needed a way to clear a cache entry off of disk, not just forget about it. > The worry was about if you got content on a server that was illegal or a > privacy violation of some sort, we wanted a way to be able to tell customers > that after this step there was no way that TS could serve the content again. > The normal cache remove just clears the directory entry, but theoretically a > bug could allow that data out in some way. This was not intended to prevent > forensic analysis of the hardware being able to recover the data. And bugs > in low level drivers or the kernel could theoretically allow data to survive > due to block remapping or mis-management of disk caches. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-718) can not reuse SSL connections on RHEL5/CentOS5
[
https://issues.apache.org/jira/browse/TS-718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom resolved TS-718.
--
Resolution: Cannot Reproduce
Fix Version/s: (was: 3.3.1)
Please reopen this if you can reproduce this.
> can not reuse SSL connections on RHEL5/CentOS5
> --
>
> Key: TS-718
> URL: https://issues.apache.org/jira/browse/TS-718
> Project: Traffic Server
> Issue Type: Bug
> Components: SSL
>Affects Versions: 2.1.7
> Environment: RHEL5 system with TS 2.1.6 2.1.7
> compared with Apache httpd
>Reporter: Zhao Yongming
>Assignee: qianshi
> Attachments: TS-718.patch, TS-718-v2.patch
>
>
> when with apache httpd default mod_ssl:
> {noformat}
> [root@ts1 httpd]# echo | openssl s_client -reconnect -connect localhost:443
> 2>&1
> CONNECTED(0003)
> depth=0
> /C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ts1.test.cnz.alimama.com/emailAddress=r...@ts1.test.cnz.alimama.com
> verify error:num=18:self signed certificate
> verify return:1
> depth=0
> /C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ts1.test.cnz.alimama.com/emailAddress=r...@ts1.test.cnz.alimama.com
> verify return:1
> ---
> Certificate chain
> 0
> s:/C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ts1.test.cnz.alimama.com/emailAddress=r...@ts1.test.cnz.alimama.com
>
> i:/C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ts1.test.cnz.alimama.com/emailAddress=r...@ts1.test.cnz.alimama.com
> ---
> Server certificate
> -BEGIN CERTIFICATE-
> MIIDSzCCArSgAwIBAgICUWcwDQYJKoZIhvcNAQEFBQAwgcExCzAJBgNVBAYTAi0t
> MRIwEAYDVQQIDAlTb21lU3RhdGUxETAPBgNVBAcMCFNvbWVDaXR5MRkwFwYDVQQK
> DBBTb21lT3JnYW5pemF0aW9uMR8wHQYDVQQLDBZTb21lT3JnYW5pemF0aW9uYWxV
> bml0MSEwHwYDVQQDDBh0czEudGVzdC5jbnouYWxpbWFtYS5jb20xLDAqBgkqhkiG
> 9w0BCQEWHXJvb3RAdHMxLnRlc3QuY256LmFsaW1hbWEuY29tMB4XDTExMDMyNDEw
> Mjk1MVoXDTEyMDMyMzEwMjk1MVowgcExCzAJBgNVBAYTAi0tMRIwEAYDVQQIDAlT
> b21lU3RhdGUxETAPBgNVBAcMCFNvbWVDaXR5MRkwFwYDVQQKDBBTb21lT3JnYW5p
> emF0aW9uMR8wHQYDVQQLDBZTb21lT3JnYW5pemF0aW9uYWxVbml0MSEwHwYDVQQD
> DBh0czEudGVzdC5jbnouYWxpbWFtYS5jb20xLDAqBgkqhkiG9w0BCQEWHXJvb3RA
> dHMxLnRlc3QuY256LmFsaW1hbWEuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB
> iQKBgQDg0xr6MMfTUooenmxTyXiaSiHMfrkbGGhjgE0slP1iWfBf62Qal1daSSb8
> hSSFCZI78RWAp/bcadHGPo43xDWBmohLyTnlWksKKcbSJ9atdijC2L2CJNXiWgKC
> cu+2jOTLAw0YJVOufuJmm8QaqmHl4y3UGE626VDN8lPGBCrQcwIDAQABo1AwTjAd
> BgNVHQ4EFgQUIAfaVLkaRWgWp+zxPtp0bWfbbsgwHwYDVR0jBBgwFoAUIAfaVLka
> RWgWp+zxPtp0bWfbbsgwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQUFAAOBgQA1
> qYMZB0MuCQz2yCAx25C3+UtoZuxdmQxekmOPjtRAm2CRccW7r0ne57BcVU79Qk2s
> 6KTU4fO7lJ1tz49ZkX5zts5WuqsWDSb4cfyDb3ybubcZwUu+eSkqVkx/7GAuVgcl
> weoLXdgpQ779T45SovOR212BXQpYI0piMDNIB9p0mA==
> -END CERTIFICATE-
> subject=/C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ts1.test.cnz.alimama.com/emailAddress=r...@ts1.test.cnz.alimama.com
> issuer=/C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ts1.test.cnz.alimama.com/emailAddress=r...@ts1.test.cnz.alimama.com
> ---
> No client certificate CA names sent
> ---
> SSL handshake has read 1418 bytes and written 319 bytes
> ---
> New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
> Server public key is 1024 bit
> Secure Renegotiation IS supported
> Compression: NONE
> Expansion: NONE
> SSL-Session:
> Protocol : TLSv1
> Cipher: DHE-RSA-AES256-SHA
> Session-ID:
> 8A72957E09AF60AD3807C1D06CE3F9BD88914886B7F1F646B03E8BDA783FAB8B
> Session-ID-ctx:
> Master-Key:
> 42808C5CDF016480F1BC7FF6F764A4886886E430F8E23400D82A9E6A6DE377A30369541E52BA06E1DC878F18DAFC2ECA
> Key-Arg : None
> Krb5 Principal: None
> Start Time: 1300962675
> Timeout : 300 (sec)
> Verify return code: 18 (self signed certificate)
> ---
> drop connection and then reconnect
> CONNECTED(0003)
> ---
> Reused, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
> Secure Renegotiation IS supported
> Compression: zlib compression
> Expansion: zlib compression
> SSL-Session:
> Protocol : TLSv1
> Cipher: DHE-RSA-AES256-SHA
> Session-ID:
> 8A72957E09AF60AD3807C1D06CE3F9BD88914886B7F1F646B03E8BDA783FAB8B
> Session-ID-ctx:
> Master-Key:
> 42808C5CDF016480F1BC7FF6F764A4886886E430F8E23400D82A9E6A6DE377A30369541E52BA06E1DC878F18DAFC2ECA
> Key-Arg : None
> Krb5 Principal: None
>Compression: 1 (zlib compression)
> Start Time: 1300962675
> Timeout : 300 (sec)
> Verify return code: 18 (self signed certificate)
> ---
> drop connection and then reconnect
> CONNECTED(0003)
> ---
> Reused, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
> Secure Renegotiation IS supported
> Compression: zlib compression
> Expansion: z
[jira] [Updated] (TS-703) cannot find server response 502 :( plz help me!!
[ https://issues.apache.org/jira/browse/TS-703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-703: - Fix Version/s: (was: 3.3.1) > cannot find server response 502 :( plz help me!! > > > Key: TS-703 > URL: https://issues.apache.org/jira/browse/TS-703 > Project: Traffic Server > Issue Type: Test >Reporter: KenYun > > Finally, I installed ASF with a rpm vesrsion but I faced with the other > problem as you see just under. > I will really appreciate if you could help me :) > This just under is a message after I put ' curl -v http://localhost/ ' to > test if AFS works. > ] curl -v http://localhost/ > . > . > . > > FYI, > Of course I did following things, > CONFIG proxy.config.proxy_name STRING kenyun > CONFIG proxy.config.http.server_port INT 80 > map http://localhost:80/ http://localhost:8080/ > map http://kenyun:80/ http://localhost:8080/ > Listen 8080 > Plz tell me if I did something wrong here ㅠㅠ -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-703) cannot find server response 502 :( plz help me!!
[ https://issues.apache.org/jira/browse/TS-703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-703. -- Resolution: Won't Fix Please use 127.0.0.1 instead. > cannot find server response 502 :( plz help me!! > > > Key: TS-703 > URL: https://issues.apache.org/jira/browse/TS-703 > Project: Traffic Server > Issue Type: Test >Reporter: KenYun > Fix For: 3.3.1 > > > Finally, I installed ASF with a rpm vesrsion but I faced with the other > problem as you see just under. > I will really appreciate if you could help me :) > This just under is a message after I put ' curl -v http://localhost/ ' to > test if AFS works. > ] curl -v http://localhost/ > . > . > . > > FYI, > Of course I did following things, > CONFIG proxy.config.proxy_name STRING kenyun > CONFIG proxy.config.http.server_port INT 80 > map http://localhost:80/ http://localhost:8080/ > map http://kenyun:80/ http://localhost:8080/ > Listen 8080 > Plz tell me if I did something wrong here ㅠㅠ -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1724) Tool to compare records.config files
[ https://issues.apache.org/jira/browse/TS-1724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Harrison updated TS-1724: -- Attachment: compare_records_config.py Script to compare records.config files. > Tool to compare records.config files > > > Key: TS-1724 > URL: https://issues.apache.org/jira/browse/TS-1724 > Project: Traffic Server > Issue Type: Improvement > Components: Configuration >Reporter: Mark Harrison > Attachments: compare_records_config.py > > > I wrote a quick tool to compare records.config files (usually > records.config.default.in from the ATS source with an installed records.conf) > and display changes, normalizing things like FLOAT 1.5 and INT 32M. This > might be useful for others, and so I'm adding it here. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1724) Tool to compare records.config files
Mark Harrison created TS-1724: - Summary: Tool to compare records.config files Key: TS-1724 URL: https://issues.apache.org/jira/browse/TS-1724 Project: Traffic Server Issue Type: Improvement Components: Configuration Reporter: Mark Harrison I wrote a quick tool to compare records.config files (usually records.config.default.in from the ATS source with an installed records.conf) and display changes, normalizing things like FLOAT 1.5 and INT 32M. This might be useful for others, and so I'm adding it here. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1723) remove libiconv dependency
[ https://issues.apache.org/jira/browse/TS-1723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13586088#comment-13586088 ] ASF subversion and git services commented on TS-1723: - Commit 8a9ad20522e5993cd3b10e6f30326db0e1e4e47c in branch refs/heads/master from [~i.galic] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=8a9ad20 ] TS-1723: Remove @LIBICONV@ from Makefile.ams > remove libiconv dependency > -- > > Key: TS-1723 > URL: https://issues.apache.org/jira/browse/TS-1723 > Project: Traffic Server > Issue Type: Improvement > Components: Core, Packaging, Portability >Reporter: James Peach >Assignee: Igor Galić > > libiconv is only used by ink_utf8_to_latin1(), and that function is never > called. Let's remove the whole thing! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1723) remove libiconv dependency
[ https://issues.apache.org/jira/browse/TS-1723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13586072#comment-13586072 ] ASF subversion and git services commented on TS-1723: - Commit 8cbc7c87e5f44d47f7a96b27bbae5456f008e3f5 in branch refs/heads/master from [~i.galic] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=8cbc7c8 ] TS-1723 remove (lib)iconv dependency We don't need it anymore, for one, and for the other it might help us finally fix the Solaris 10 build > remove libiconv dependency > -- > > Key: TS-1723 > URL: https://issues.apache.org/jira/browse/TS-1723 > Project: Traffic Server > Issue Type: Improvement > Components: Core, Packaging, Portability >Reporter: James Peach >Assignee: Igor Galić > > libiconv is only used by ink_utf8_to_latin1(), and that function is never > called. Let's remove the whole thing! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1723) remove libiconv dependency
James Peach created TS-1723: --- Summary: remove libiconv dependency Key: TS-1723 URL: https://issues.apache.org/jira/browse/TS-1723 Project: Traffic Server Issue Type: Improvement Components: Core, Packaging, Portability Reporter: James Peach libiconv is only used by ink_utf8_to_latin1(), and that function is never called. Let's remove the whole thing! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-1723) remove libiconv dependency
[ https://issues.apache.org/jira/browse/TS-1723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach reassigned TS-1723: --- Assignee: Igor Galić Igor has kindly volunteered. > remove libiconv dependency > -- > > Key: TS-1723 > URL: https://issues.apache.org/jira/browse/TS-1723 > Project: Traffic Server > Issue Type: Improvement > Components: Core, Packaging, Portability >Reporter: James Peach >Assignee: Igor Galić > > libiconv is only used by ink_utf8_to_latin1(), and that function is never > called. Let's remove the whole thing! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-306) Rotating traffic.out
[ https://issues.apache.org/jira/browse/TS-306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13586046#comment-13586046 ] James Peach commented on TS-306: Mohamed, I don't see a patch here? Did you mean to mark this as "Patch Available"? > Rotating traffic.out > > > Key: TS-306 > URL: https://issues.apache.org/jira/browse/TS-306 > Project: Traffic Server > Issue Type: Improvement > Components: Logging >Reporter: Miles Libbey >Priority: Critical > Fix For: sometime > > > (from yahoo bug 913896) > Original description > by Leif Hedstrom 3 years ago at 2006-12-04 12:42 > There might be reasons why this file might get filled up, e.g. libraries used > by plugins producing output on STDOUT/STDERR. A few suggestions have been > made, to somehow rotate traffic.out. One possible solution (suggested by > Ryan) is to use cronolog (http://cronolog.org/), which seems like a fine idea. > > > Comment 1 > by Joseph Rothrock 2 years ago at 2007-10-17 09:13:24 > Maybe consider rolling diags.log as well. -Feature enhancement. > > Comment 2 > by Kevin Dalley 13 months ago at 2009-03-04 15:32:18 > When traffic.out gets filled up, error.log stops filing up, even though > rotation is turned on. This is > counter-intuitive. Rotation does not control traffic.out, but a large > traffic.out will stop error.log from being > written. > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
