[jira] [Commented] (TS-899) ts crash
[ https://issues.apache.org/jira/browse/TS-899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13080772#comment-13080772 ] Zhao Yongming commented on TS-899: -- weijin find out that prefetch plugin will cause this remap into the buggy transform codes, can crash the server, so I update it a prefetch sub task, and hopes we can get all target for prefetch clear and fixed later. ts crash Key: TS-899 URL: https://issues.apache.org/jira/browse/TS-899 Project: Traffic Server Issue Type: Sub-task Components: HTTP, MIME Affects Versions: 3.0.1 Environment: readhat5.5, ts-3.0.1, X86-64 Reporter: weijin If a request url is forbidden then redirected to another url, TS crash. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-849) proxy.config.http.slow.log.threshold is unable to set from traffic_line -s
[
https://issues.apache.org/jira/browse/TS-849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13080799#comment-13080799
]
Zhao Yongming commented on TS-849:
--
it turns out to be that we incorrectly handle RecCheckT = RECC_INT and checking
regex pattern is set to ^[0-
9]+$. all RECC_INT checking is band to recordRangeCheck(), while it does not
handle plain regex pattern.
there is some others need to change:
{code}
{RECT_CONFIG, proxy.config.http.server_max_connections, RECD_INT, 0,
RECU_DYNAMIC, RR_NULL, RECC_INT, ^[0-9]+$, RECA_NULL}
,
{RECT_CONFIG, proxy.config.http.origin_max_connections, RECD_INT, 0,
RECU_DYNAMIC, RR_NULL, RECC_INT, ^[0-9]+$, RECA_NULL}
,
{RECT_CONFIG, proxy.config.http.origin_min_keep_alive_connections,
RECD_INT, 0, RECU_DYNAMIC, RR_NULL, RECC_INT, ^[0-9]+$, RECA_NULL}
{RECT_CONFIG, proxy.config.http.slow.log.threshold, RECD_INT, 0,
RECU_DYNAMIC, RR_NULL, RECC_INT, ^[0-9]+$, RECA_NULL}
{RECT_CONFIG, proxy.config.net.defer_accept, RECD_INT,
#ifdef TCP_DEFER_ACCEPT
45,
#else
1,
#endif
RECU_DYNAMIC, RR_NULL, RECC_INT, ^[0-9]+$, RECA_NULL}
{code}
proxy.config.http.slow.log.threshold is unable to set from traffic_line -s
--
Key: TS-849
URL: https://issues.apache.org/jira/browse/TS-849
Project: Traffic Server
Issue Type: Bug
Components: Configuration
Affects Versions: 3.1.0, 3.0.1
Reporter: Zhao Yongming
Assignee: Zhao Yongming
Fix For: 3.1.1
I am wondering how many config items from records have the same situation?
{code}
[root@cache164 trafficserver]# traffic_line -s
proxy.config.http.slow.log.threshold -v 30
Layout configuration
--prefix = '/usr'
--exec_prefix = '/usr'
--bindir = '/usr/bin'
--sbindir = '/usr/sbin'
--sysconfdir = '/etc/trafficserver'
--datadir = '/usr/share/trafficserver'
--includedir = '/usr/include/trafficserver'
--libdir = '/usr/lib64/trafficserver'
--libexecdir = '/usr/lib64/trafficserver/plugins'
--localstatedir = '/var/trafficserver'
--runtimedir = '/var/run/trafficserver'
--logdir = '/var/log/trafficserver'
--mandir = '/usr/share/man'
--infodir = '/usr/share/info'
--cachedir = '/var/cache/trafficserver'
traffic_line: Only configuration vars can be set
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-849) proxy.config.http.slow.log.threshold is unable to set from traffic_line -s
[
https://issues.apache.org/jira/browse/TS-849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zhao Yongming resolved TS-849.
--
Resolution: Fixed
Fix Version/s: (was: 3.1.1)
3.1.0
fixed in r1154888
proxy.config.http.slow.log.threshold is unable to set from traffic_line -s
--
Key: TS-849
URL: https://issues.apache.org/jira/browse/TS-849
Project: Traffic Server
Issue Type: Bug
Components: Configuration
Affects Versions: 3.1.0, 3.0.1
Reporter: Zhao Yongming
Assignee: Zhao Yongming
Fix For: 3.1.0
I am wondering how many config items from records have the same situation?
{code}
[root@cache164 trafficserver]# traffic_line -s
proxy.config.http.slow.log.threshold -v 30
Layout configuration
--prefix = '/usr'
--exec_prefix = '/usr'
--bindir = '/usr/bin'
--sbindir = '/usr/sbin'
--sysconfdir = '/etc/trafficserver'
--datadir = '/usr/share/trafficserver'
--includedir = '/usr/include/trafficserver'
--libdir = '/usr/lib64/trafficserver'
--libexecdir = '/usr/lib64/trafficserver/plugins'
--localstatedir = '/var/trafficserver'
--runtimedir = '/var/run/trafficserver'
--logdir = '/var/log/trafficserver'
--mandir = '/usr/share/man'
--infodir = '/usr/share/info'
--cachedir = '/var/cache/trafficserver'
traffic_line: Only configuration vars can be set
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-732) wish to get the WCCP codes in ancient TrafficServer for reference
[ https://issues.apache.org/jira/browse/TS-732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zhao Yongming resolved TS-732. -- Resolution: Won't Fix no way to get it, close it now. wish to get the WCCP codes in ancient TrafficServer for reference - Key: TS-732 URL: https://issues.apache.org/jira/browse/TS-732 Project: Traffic Server Issue Type: Wish Components: Clustering, Management, Network Affects Versions: 2.1.8 Reporter: Zhao Yongming Assignee: vijaya bhaskar mamidi Priority: Trivial Labels: wccp back to the begin of TS in Yahoo. the codes includes WCCP, which is documented in Admin Guide. When we need to reimplement some features, if we can get those codes for reference, it will be very useful for us. things we are interesting in: wccp L2 supports cluster + wccp integrating wccp configuration and stats collections may need Vijay from Yahoo help us on this proposal. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TS-888) SSL connections working with 2.1.5 fail with 3.0.1 and FireFox
[ https://issues.apache.org/jira/browse/TS-888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Plevyak closed TS-888. --- Resolution: Fixed Assignee: John Plevyak (was: Leif Hedstrom) Fixed 1155125. SSL connections working with 2.1.5 fail with 3.0.1 and FireFox -- Key: TS-888 URL: https://issues.apache.org/jira/browse/TS-888 Project: Traffic Server Issue Type: Bug Components: SSL Affects Versions: 3.0.1 Environment: Ubuntu 10.04 LTS amd64, Glassfish 3.0.1, FireFox 5.0 Reporter: Kurt Huwig Assignee: John Plevyak Fix For: 3.1.0 Attachments: TS-888-jp.patch ATS has SSL server certificates. The backend is accessed via SSL as well which uses the same certificates. It fails with FireFox, but works with Google Chrome. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (TS-888) SSL connections working with 2.1.5 fail with 3.0.1 and FireFox
[ https://issues.apache.org/jira/browse/TS-888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reopened TS-888: -- Lets reopen this, since I really think this should get backported to 3.0.2. Thanks a lot John for fixing this ugly bug! SSL connections working with 2.1.5 fail with 3.0.1 and FireFox -- Key: TS-888 URL: https://issues.apache.org/jira/browse/TS-888 Project: Traffic Server Issue Type: Bug Components: SSL Affects Versions: 3.0.1 Environment: Ubuntu 10.04 LTS amd64, Glassfish 3.0.1, FireFox 5.0 Reporter: Kurt Huwig Assignee: John Plevyak Fix For: 3.1.0 Attachments: TS-888-jp.patch ATS has SSL server certificates. The backend is accessed via SSL as well which uses the same certificates. It fails with FireFox, but works with Google Chrome. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-909) code cleanup for format
[ https://issues.apache.org/jira/browse/TS-909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] mohan_zl updated TS-909: Attachment: TS-format-fix_1.patch Fix the net format error code cleanup for format --- Key: TS-909 URL: https://issues.apache.org/jira/browse/TS-909 Project: Traffic Server Issue Type: Bug Reporter: mohan_zl Attachments: TS-format-fix_1.patch -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-880) Major performance problem with second request on same keep-alive connection
[ https://issues.apache.org/jira/browse/TS-880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13081434#comment-13081434 ] Manjesh Nilange commented on TS-880: William, the new patch worked for me. Thanks! Major performance problem with second request on same keep-alive connection --- Key: TS-880 URL: https://issues.apache.org/jira/browse/TS-880 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 3.0.0, 2.1.4 Environment: 32-bit TS on linux, using epoll. With proxy.config.http.keep_alive_enabled_out = 1 Reporter: William Bardwell Assignee: William Bardwell Fix For: 3.1.0 Attachments: performance_2nd_req.diff, performance_2nd_req_try2.diff If I load the same URL through TS twice in a row to a server with keep-alives turned on I get really slow performance on the second request. E.g. (loading 212M over loopback with uncachable content, but results are similar with cachable content): % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 100 212M 100 212M0 0 140M 0 0:00:01 0:00:01 --:--:-- 142M* % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 100 212M 100 212M0 0 6397k 0 0:00:34 0:00:34 --:--:-- 6400k* If I turn off proxy.config.http.keep_alive_enabled_out the problem goes away, it can also be partially solved by making proxy.config.io.max_buffer_size really big (but it needs to be bigger for larger content, and that supports the comment below, and proves that it isn't the origin server's fault.) When I turn on debug messages it looks like the IO loop for the second request only wakes up every 10ms (when an epoll_wait times out) and then it reads and writes, for the first request it goes much faster without those pauses. My theory is that the issue is related to the the fact that the outgoing connection fd gets added to the epoll fd for the thread handling the first request and the first user agent fd is added to the same epoll fd, and it stays on that epoll fd. But the new user agent request is on a different epoll fd which I assume means is tied to a different thread. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
