[jira] [Updated] (TS-1453) remove InactivityCop and enable define INACTIVITY_TIMEOUT
[ https://issues.apache.org/jira/browse/TS-1453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen updated TS-1453: - Attachment: TS-1453_v2.patch this patch base on TS-1405_v12.patch > remove InactivityCop and enable define INACTIVITY_TIMEOUT > - > > Key: TS-1453 > URL: https://issues.apache.org/jira/browse/TS-1453 > Project: Traffic Server > Issue Type: Sub-task > Components: Core >Affects Versions: 3.2.0 >Reporter: Bin Chen >Assignee: Bin Chen > Labels: A > Fix For: 5.2.0 > > Attachments: TS-1453.patch, TS-1453_v2.patch > > > when we have O(1), then we can be enable define INACTIVITY_TIMEOUT -- This message was sent by Atlassian JIRA (v6.2#6252)
[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=13917710#comment-13917710 ] Bin Chen commented on TS-1405: -- the origin event schedule policy will schedule the event(event->timeout_at - now < 5ms).now new patch(v12) will schedule these event too. > 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 > Labels: C > Fix For: 5.2.0 > > Attachments: linux_time_wheel.patch, linux_time_wheel_v10jp.patch, > linux_time_wheel_v11jp.patch, linux_time_wheel_v12.patch, > linux_time_wheel_v2.patch, linux_time_wheel_v3.patch, > linux_time_wheel_v4.patch, linux_time_wheel_v5.patch, > linux_time_wheel_v6.patch, linux_time_wheel_v7.patch, > linux_time_wheel_v8.patch, linux_time_wheel_v9jp.patch, patch12_test.pdf > > > 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 was sent by Atlassian JIRA (v6.2#6252)
[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: patch12_test.pdf test between original version and patch p12. > 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 > Labels: C > Fix For: 5.2.0 > > Attachments: linux_time_wheel.patch, linux_time_wheel_v10jp.patch, > linux_time_wheel_v11jp.patch, linux_time_wheel_v12.patch, > linux_time_wheel_v2.patch, linux_time_wheel_v3.patch, > linux_time_wheel_v4.patch, linux_time_wheel_v5.patch, > linux_time_wheel_v6.patch, linux_time_wheel_v7.patch, > linux_time_wheel_v8.patch, linux_time_wheel_v9jp.patch, patch12_test.pdf > > > 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 was sent by Atlassian JIRA (v6.2#6252)
[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_v12.patch base master 5.0.0 > 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 > Labels: C > Fix For: 5.2.0 > > Attachments: linux_time_wheel.patch, linux_time_wheel_v10jp.patch, > linux_time_wheel_v11jp.patch, linux_time_wheel_v12.patch, > linux_time_wheel_v2.patch, linux_time_wheel_v3.patch, > linux_time_wheel_v4.patch, linux_time_wheel_v5.patch, > linux_time_wheel_v6.patch, linux_time_wheel_v7.patch, > linux_time_wheel_v8.patch, linux_time_wheel_v9jp.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 was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2201) split drainIncomingChannel two thread, one handle Broadcast message and other handle Reliable(TCP) request
[ https://issues.apache.org/jira/browse/TS-2201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13769166#comment-13769166 ] Bin Chen commented on TS-2201: -- for supporting large cluster. > split drainIncomingChannel two thread, one handle Broadcast message and other > handle Reliable(TCP) request > -- > > Key: TS-2201 > URL: https://issues.apache.org/jira/browse/TS-2201 > Project: Traffic Server > Issue Type: Improvement > Components: Clustering, cop >Reporter: Bin Chen >Assignee: Bin Chen > Attachments: TS-2201.patch > > -- 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] [Closed] (TS-2201) split drainIncomingChannel two thread, one handle Broadcast message and other handle Reliable(TCP) request
[ https://issues.apache.org/jira/browse/TS-2201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen closed TS-2201. Resolution: Fixed Fix Version/s: 4.1.0 > split drainIncomingChannel two thread, one handle Broadcast message and other > handle Reliable(TCP) request > -- > > Key: TS-2201 > URL: https://issues.apache.org/jira/browse/TS-2201 > Project: Traffic Server > Issue Type: Improvement > Components: Clustering, cop >Reporter: Bin Chen >Assignee: Bin Chen > Fix For: 4.1.0 > > Attachments: TS-2201.patch > > -- 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-2201) split drainIncomingChannel two thread, one handle Broadcast message and other handle Reliable(TCP) request
[ https://issues.apache.org/jira/browse/TS-2201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen updated TS-2201: - Attachment: TS-2201.patch > split drainIncomingChannel two thread, one handle Broadcast message and other > handle Reliable(TCP) request > -- > > Key: TS-2201 > URL: https://issues.apache.org/jira/browse/TS-2201 > Project: Traffic Server > Issue Type: Improvement > Components: Clustering, cop >Reporter: Bin Chen >Assignee: Bin Chen > Attachments: TS-2201.patch > > -- 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] [Closed] (TS-1637) nodes as idle/dead if we have not heard from them in awhile
[ https://issues.apache.org/jira/browse/TS-1637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen closed TS-1637. Resolution: Fixed Fix Version/s: (was: 4.2.0) 4.1.0 > nodes as idle/dead if we have not heard from them in awhile > --- > > Key: TS-1637 > URL: https://issues.apache.org/jira/browse/TS-1637 > Project: Traffic Server > Issue Type: Improvement > Components: Clustering, Management >Affects Versions: 3.2.0 >Reporter: Bin Chen >Assignee: Bin Chen > Fix For: 4.1.0 > > Attachments: TS-1637.patch, TS-1637_v2.patch > > > in ClusterCom::sendReliableMessageReadTillClose(), if we can't connect peer > node quickly(if timeout, will > 30s(default peer_timeout)), then won't send > Shared date called by ClusterCom::sendSharedData. So peer node will marking > me 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] [Closed] (TS-2185) support to control ClusterCom::sendSharedData frequency
[ https://issues.apache.org/jira/browse/TS-2185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen closed TS-2185. Resolution: Fixed Fix Version/s: 4.1.0 > support to control ClusterCom::sendSharedData frequency > --- > > Key: TS-2185 > URL: https://issues.apache.org/jira/browse/TS-2185 > Project: Traffic Server > Issue Type: Improvement > Components: Clustering >Reporter: Bin Chen >Assignee: Bin Chen > Fix For: 4.1.0 > > Attachments: TS-2185.patch > > > support to control ClusterCom::sendSharedData frequency. The original design > ClusterCom::sendSharedData will be called every loop. It's so frequent. -- 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-2201) split drainIncomingChannel two thread, one handle Broadcast message and other handle Reliable(TCP) request
[ https://issues.apache.org/jira/browse/TS-2201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen reassigned TS-2201: Assignee: Bin Chen > split drainIncomingChannel two thread, one handle Broadcast message and other > handle Reliable(TCP) request > -- > > Key: TS-2201 > URL: https://issues.apache.org/jira/browse/TS-2201 > Project: Traffic Server > Issue Type: Improvement > Components: Clustering, cop >Reporter: Bin Chen >Assignee: Bin Chen > -- 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-2201) split drainIncomingChannel two thread, one handle Broadcast message and other handle Reliable(TCP) request
Bin Chen created TS-2201: Summary: split drainIncomingChannel two thread, one handle Broadcast message and other handle Reliable(TCP) request Key: TS-2201 URL: https://issues.apache.org/jira/browse/TS-2201 Project: Traffic Server Issue Type: Improvement Components: Clustering, cop Reporter: Bin Chen -- 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-2184) Fetch from cluster with proxy.config.http.cache.cluster_cache_local enabled
[ https://issues.apache.org/jira/browse/TS-2184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen reassigned TS-2184: Assignee: Bin Chen > Fetch from cluster with proxy.config.http.cache.cluster_cache_local enabled > --- > > Key: TS-2184 > URL: https://issues.apache.org/jira/browse/TS-2184 > Project: Traffic Server > Issue Type: Improvement > Components: Cache, Clustering >Reporter: Scott Harris >Assignee: Bin Chen > > With proxy.config.http.cache.cluster_cache_local enabled I would like cluster > nodes to store content locally but try to retrieve content from the cluster > first (if not cached locally) and if no cluster nodes have content cached > then retrieve from origin. > Example - 2 Cluster nodes in Full cluster mode. > 1. Node1 and Node2 are both empty. > 2. Request to Node1 for "http://www.example.com/foo.html";. > 3. Query Cluster for object > 4. Not cached in cluster so retrieve from orgin, serve to client, object now > cached on Node1. > 5. Request comes to Node2 for "http://www.example.com/foo.html";. > 6. Node2 retrieves cached version from Node1, serves to client, stores > locally. > 7. Subsequent request comes to Node1 or Node2 for > "http://www.example.com/foo.html";, object is served to client from local > cache. -- 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-2185) support to control ClusterCom::sendSharedData frequency
[ https://issues.apache.org/jira/browse/TS-2185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen updated TS-2185: - Attachment: TS-2185.patch > support to control ClusterCom::sendSharedData frequency > --- > > Key: TS-2185 > URL: https://issues.apache.org/jira/browse/TS-2185 > Project: Traffic Server > Issue Type: Improvement > Components: Clustering >Reporter: Bin Chen >Assignee: Bin Chen > Attachments: TS-2185.patch > > > support to control ClusterCom::sendSharedData frequency. The original design > ClusterCom::sendSharedData will be called every loop. It's so frequent. -- 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-2185) support to control ClusterCom::sendSharedData frequency
[ https://issues.apache.org/jira/browse/TS-2185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen reassigned TS-2185: Assignee: Bin Chen > support to control ClusterCom::sendSharedData frequency > --- > > Key: TS-2185 > URL: https://issues.apache.org/jira/browse/TS-2185 > Project: Traffic Server > Issue Type: Improvement > Components: Clustering >Reporter: Bin Chen >Assignee: Bin Chen > > support to control ClusterCom::sendSharedData frequency. The original design > ClusterCom::sendSharedData will be called every loop. It's so frequent. -- 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-2185) support to control ClusterCom::sendSharedData frequency
Bin Chen created TS-2185: Summary: support to control ClusterCom::sendSharedData frequency Key: TS-2185 URL: https://issues.apache.org/jira/browse/TS-2185 Project: Traffic Server Issue Type: Improvement Components: Clustering Reporter: Bin Chen support to control ClusterCom::sendSharedData frequency. The original design ClusterCom::sendSharedData will be called every loop. It's so frequent. -- 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] [Work started] (TS-1637) nodes as idle/dead if we have not heard from them in awhile
[ https://issues.apache.org/jira/browse/TS-1637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on TS-1637 started by Bin Chen. > nodes as idle/dead if we have not heard from them in awhile > --- > > Key: TS-1637 > URL: https://issues.apache.org/jira/browse/TS-1637 > Project: Traffic Server > Issue Type: Improvement > Components: Clustering, Management >Affects Versions: 3.2.0 >Reporter: Bin Chen >Assignee: Bin Chen > Fix For: 4.2.0 > > Attachments: TS-1637.patch, TS-1637_v2.patch > > > in ClusterCom::sendReliableMessageReadTillClose(), if we can't connect peer > node quickly(if timeout, will > 30s(default peer_timeout)), then won't send > Shared date called by ClusterCom::sendSharedData. So peer node will marking > me 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] [Commented] (TS-1637) nodes as idle/dead if we have not heard from them in awhile
[ https://issues.apache.org/jira/browse/TS-1637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13758768#comment-13758768 ] Bin Chen commented on TS-1637: -- mgmt_select() broadcast fd will be timeout. So checkPeers will be setting node(timeout) down. So we should reduce tv about mgmt_select(). set the default tv timeout 5s. > nodes as idle/dead if we have not heard from them in awhile > --- > > Key: TS-1637 > URL: https://issues.apache.org/jira/browse/TS-1637 > Project: Traffic Server > Issue Type: Improvement > Components: Clustering, Management >Affects Versions: 3.2.0 >Reporter: Bin Chen >Assignee: Bin Chen > Fix For: 4.2.0 > > Attachments: TS-1637.patch, TS-1637_v2.patch > > > in ClusterCom::sendReliableMessageReadTillClose(), if we can't connect peer > node quickly(if timeout, will > 30s(default peer_timeout)), then won't send > Shared date called by ClusterCom::sendSharedData. So peer node will marking > me 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-1637) nodes as idle/dead if we have not heard from them in awhile
[ https://issues.apache.org/jira/browse/TS-1637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen updated TS-1637: - Attachment: TS-1637_v2.patch > nodes as idle/dead if we have not heard from them in awhile > --- > > Key: TS-1637 > URL: https://issues.apache.org/jira/browse/TS-1637 > Project: Traffic Server > Issue Type: Improvement > Components: Clustering, Management >Affects Versions: 3.2.0 >Reporter: Bin Chen >Assignee: Bin Chen > Fix For: 4.2.0 > > Attachments: TS-1637.patch, TS-1637_v2.patch > > > in ClusterCom::sendReliableMessageReadTillClose(), if we can't connect peer > node quickly(if timeout, will > 30s(default peer_timeout)), then won't send > Shared date called by ClusterCom::sendSharedData. So peer node will marking > me 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-2149) loop in dir_clean_bucket()
[ https://issues.apache.org/jira/browse/TS-2149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen updated TS-2149: - Attachment: Screenshot.png > loop in dir_clean_bucket() > -- > > Key: TS-2149 > URL: https://issues.apache.org/jira/browse/TS-2149 > Project: Traffic Server > Issue Type: Bug > Components: Cache >Reporter: Bin Chen > Attachments: Screenshot.png > > > Ts will enter loop in dir_clean_bucket(). The define LOOP_CHECK_MODE not use > default. -- 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-2149) loop in dir_clean_bucket()
Bin Chen created TS-2149: Summary: loop in dir_clean_bucket() Key: TS-2149 URL: https://issues.apache.org/jira/browse/TS-2149 Project: Traffic Server Issue Type: Bug Components: Cache Reporter: Bin Chen Ts will enter loop in dir_clean_bucket(). The define LOOP_CHECK_MODE not use default. -- 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] [Closed] (TS-2107) add absolute proxy.config.http.transaction_active_timeout_in about request
[
https://issues.apache.org/jira/browse/TS-2107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bin Chen closed TS-2107.
Resolution: Fixed
Fix Version/s: 4.1.0
> add absolute proxy.config.http.transaction_active_timeout_in about request
> ---
>
> Key: TS-2107
> URL: https://issues.apache.org/jira/browse/TS-2107
> Project: Traffic Server
> Issue Type: New Feature
> Components: HTTP
>Affects Versions: 3.3.5
>Reporter: Bin Chen
>Assignee: Bin Chen
> Fix For: 4.1.0, 4.2.0
>
> Attachments: TS-2107.patch
>
>
> Now, ts use proxy.config.http.transaction_active_timeout_in handle request
> and response transaction. But in some very bad network, we catch some log
> that it cost >30s to get ua_read_header_done, that is unacceptable, should be
> controled with some dedicated timeout in records.config.
> we world prefer to add proxy.config.http.transaction_header_timeout_in
> proxy.config.http.transaction_request_timeout_in
> {code}
> [Aug 6 22:11:46.698] Server {0x2b37cf0f9700} ERROR: [1366077161] Slow
> Request: url: http://x/853771125_1448036722.jpg status: 0 unique id:
> bytes: 0 fd: 0 client state: 0 server state: 0 ua_begin: 0.000
> ua_read_header_done: 46.790 cache_open_read_begin: 46.790
> cache_open_read_end: -1.000 dns_lookup_begin: -1.000 dns_lookup_end: -1.000
> server_connect: -1.000 server_first_read: -1.000 server_read_header_done:
> -1.000 server_close: -1.000 ua_close: 46.790 sm_finish: 46.790
> {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-2107) add absolute proxy.config.http.transaction_active_timeout_in about request
[
https://issues.apache.org/jira/browse/TS-2107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bin Chen updated TS-2107:
-
Attachment: TS-2107.patch
> add absolute proxy.config.http.transaction_active_timeout_in about request
> ---
>
> Key: TS-2107
> URL: https://issues.apache.org/jira/browse/TS-2107
> Project: Traffic Server
> Issue Type: New Feature
> Components: HTTP
>Affects Versions: 3.3.5
>Reporter: Bin Chen
>Assignee: Bin Chen
> Fix For: 3.5.1
>
> Attachments: TS-2107.patch
>
>
> Now, ts use proxy.config.http.transaction_active_timeout_in handle request
> and response transaction. But in some very bad network, we catch some log
> that it cost >30s to get ua_read_header_done, that is unacceptable, should be
> controled with some dedicated timeout in records.config.
> we world prefer to add proxy.config.http.transaction_header_timeout_in
> proxy.config.http.transaction_request_timeout_in
> {code}
> [Aug 6 22:11:46.698] Server {0x2b37cf0f9700} ERROR: [1366077161] Slow
> Request: url: http://x/853771125_1448036722.jpg status: 0 unique id:
> bytes: 0 fd: 0 client state: 0 server state: 0 ua_begin: 0.000
> ua_read_header_done: 46.790 cache_open_read_begin: 46.790
> cache_open_read_end: -1.000 dns_lookup_begin: -1.000 dns_lookup_end: -1.000
> server_connect: -1.000 server_first_read: -1.000 server_read_header_done:
> -1.000 server_close: -1.000 ua_close: 46.790 sm_finish: 46.790
> {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] [Closed] (TS-287) transaction_active_timeout_in does not trigger on the first request of a Keep-Alive connection
[ https://issues.apache.org/jira/browse/TS-287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen closed TS-287. --- Resolution: Fixed > transaction_active_timeout_in does not trigger on the first request of a > Keep-Alive connection > -- > > Key: TS-287 > URL: https://issues.apache.org/jira/browse/TS-287 > Project: Traffic Server > Issue Type: Bug > Components: Core >Reporter: Steve Jiang >Assignee: Bin Chen > Fix For: 3.5.0 > > Attachments: slowclient.pl, TS-287.patch > > > proxy.config.http.transaction_active_timeout_in does not trigger on a slow > request on if the request is the first on a new client connection, because > the timeout event is cancelled before it can be triggered. > Subsequent requests with keep-alive on the same connection will correctly > trigger the active_timeout_in. -- 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-287) transaction_active_timeout_in does not trigger on the first request of a Keep-Alive connection
[ https://issues.apache.org/jira/browse/TS-287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13744784#comment-13744784 ] Bin Chen commented on TS-287: - This bug is fixed by Que Han (Li Gang). > transaction_active_timeout_in does not trigger on the first request of a > Keep-Alive connection > -- > > Key: TS-287 > URL: https://issues.apache.org/jira/browse/TS-287 > Project: Traffic Server > Issue Type: Bug > Components: Core >Reporter: Steve Jiang >Assignee: Bin Chen > Fix For: 3.5.0 > > Attachments: slowclient.pl, TS-287.patch > > > proxy.config.http.transaction_active_timeout_in does not trigger on a slow > request on if the request is the first on a new client connection, because > the timeout event is cancelled before it can be triggered. > Subsequent requests with keep-alive on the same connection will correctly > trigger the active_timeout_in. -- 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-1595) different domain have different origin_max_connections?
[ https://issues.apache.org/jira/browse/TS-1595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen reassigned TS-1595: Assignee: Yu Qing (was: Bin Chen) > different domain have different origin_max_connections? > --- > > Key: TS-1595 > URL: https://issues.apache.org/jira/browse/TS-1595 > Project: Traffic Server > Issue Type: Sub-task > Components: Network >Reporter: Bin Chen >Assignee: Yu Qing >Priority: Minor > Fix For: sometime > > > In our env, we want different domain having different > "origin_max_connections" to manage connection more careful avoiding network > throttling. If not have different config in remap, use > "origin_max_connections" default. Other, config in remap will replace > "origin_max_connections". -- This message 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-287) transaction_active_timeout_in does not trigger on the first request of a Keep-Alive connection
[ https://issues.apache.org/jira/browse/TS-287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen updated TS-287: Attachment: TS-287.patch does not trigger becasue of set_active_timeout() success only UnixNetVConnection.read(write) is enable. > transaction_active_timeout_in does not trigger on the first request of a > Keep-Alive connection > -- > > Key: TS-287 > URL: https://issues.apache.org/jira/browse/TS-287 > Project: Traffic Server > Issue Type: Bug > Components: Core >Reporter: Steve Jiang >Assignee: Bin Chen > Fix For: 3.5.0 > > Attachments: slowclient.pl, TS-287.patch > > > proxy.config.http.transaction_active_timeout_in does not trigger on a slow > request on if the request is the first on a new client connection, because > the timeout event is cancelled before it can be triggered. > Subsequent requests with keep-alive on the same connection will correctly > trigger the active_timeout_in. -- 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] [Closed] (TS-2136) the first proxy.config.http.accept_no_activity_timeout is invalid
[ https://issues.apache.org/jira/browse/TS-2136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen closed TS-2136. Resolution: Fixed Fix Version/s: 3.5.0 > the first proxy.config.http.accept_no_activity_timeout is invalid > - > > Key: TS-2136 > URL: https://issues.apache.org/jira/browse/TS-2136 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: Bin Chen >Assignee: Bin Chen > Fix For: 3.5.0 > > Attachments: TS-2136.patch > > -- 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-2136) the first proxy.config.http.accept_no_activity_timeout is invalid
[ https://issues.apache.org/jira/browse/TS-2136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen updated TS-2136: - Attachment: TS-2136.patch > the first proxy.config.http.accept_no_activity_timeout is invalid > - > > Key: TS-2136 > URL: https://issues.apache.org/jira/browse/TS-2136 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: Bin Chen >Assignee: Bin Chen > Attachments: TS-2136.patch > > -- 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-2136) the first proxy.config.http.accept_no_activity_timeout is invalid
Bin Chen created TS-2136: Summary: the first proxy.config.http.accept_no_activity_timeout is invalid Key: TS-2136 URL: https://issues.apache.org/jira/browse/TS-2136 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: Bin Chen -- 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-2136) the first proxy.config.http.accept_no_activity_timeout is invalid
[ https://issues.apache.org/jira/browse/TS-2136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen reassigned TS-2136: Assignee: Bin Chen > the first proxy.config.http.accept_no_activity_timeout is invalid > - > > Key: TS-2136 > URL: https://issues.apache.org/jira/browse/TS-2136 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: Bin Chen >Assignee: Bin Chen > -- 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-2133) proxy.config.http.transaction_active_timeout_in is invalid
[ https://issues.apache.org/jira/browse/TS-2133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen reassigned TS-2133: Assignee: Bin Chen > proxy.config.http.transaction_active_timeout_in is invalid > -- > > Key: TS-2133 > URL: https://issues.apache.org/jira/browse/TS-2133 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: Bin Chen >Assignee: Bin Chen > > when client_vc isn't called by do_io_read(or do_io_write, the vc is disable), > then proxy.config.http.transaction_active_timeout_in is invalid. -- 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-2133) proxy.config.http.transaction_active_timeout_in is invalid
Bin Chen created TS-2133: Summary: proxy.config.http.transaction_active_timeout_in is invalid Key: TS-2133 URL: https://issues.apache.org/jira/browse/TS-2133 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: Bin Chen when client_vc isn't called by do_io_read(or do_io_write, the vc is disable), then proxy.config.http.transaction_active_timeout_in is invalid. -- 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-2107) add absolute proxy.config.http.transaction_active_timeout_in about request
[ https://issues.apache.org/jira/browse/TS-2107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen updated TS-2107: - Priority: Blocker (was: Major) Affects Version/s: 3.3.5 Fix Version/s: 3.3.5 Assignee: Bin Chen > add absolute proxy.config.http.transaction_active_timeout_in about request > --- > > Key: TS-2107 > URL: https://issues.apache.org/jira/browse/TS-2107 > Project: Traffic Server > Issue Type: New Feature > Components: HTTP, Security >Affects Versions: 3.3.5 >Reporter: Bin Chen >Assignee: Bin Chen >Priority: Blocker > Fix For: 3.3.5 > > > Now, ts use proxy.config.http.transaction_active_timeout_in handle request > and response transaction. But if some client send one byte and one byte > request, so we should maintain more transaction. So add absolute > proxy.config.http.transaction_active_timeout_in maybe more effective. -- 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-2107) add absolute proxy.config.http.transaction_active_timeout_in about request
Bin Chen created TS-2107: Summary: add absolute proxy.config.http.transaction_active_timeout_in about request Key: TS-2107 URL: https://issues.apache.org/jira/browse/TS-2107 Project: Traffic Server Issue Type: New Feature Components: HTTP, Security Reporter: Bin Chen Now, ts use proxy.config.http.transaction_active_timeout_in handle request and response transaction. But if some client send one byte and one byte request, so we should maintain more transaction. So add absolute proxy.config.http.transaction_active_timeout_in maybe more effective. -- 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-2085) Can't put url in ram
[ https://issues.apache.org/jira/browse/TS-2085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen reassigned TS-2085: Assignee: Bin Chen > Can't put url in ram > > > Key: TS-2085 > URL: https://issues.apache.org/jira/browse/TS-2085 > Project: Traffic Server > Issue Type: Bug > Components: Cache, HTTP >Reporter: Bin Chen >Assignee: Bin Chen > > 1.when ram size >= max_bytes(proxy.config.cache.ram_cache.size), the ram is > full. > 2. one size_bucket[i] is empty > 3. the from url is putted in size_bucket[i] > this condition url won't be putted in ram. -- 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-2085) Can't put url in ram
Bin Chen created TS-2085: Summary: Can't put url in ram Key: TS-2085 URL: https://issues.apache.org/jira/browse/TS-2085 Project: Traffic Server Issue Type: Bug Components: Cache, HTTP Reporter: Bin Chen 1.when ram size >= max_bytes(proxy.config.cache.ram_cache.size), the ram is full. 2. one size_bucket[i] is empty 3. the from url is putted in size_bucket[i] this condition url won't be putted in ram. -- 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-2084) support forcing to put some very hot url in ram?
[ https://issues.apache.org/jira/browse/TS-2084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen updated TS-2084: - Description: 1. should ts support forcing to put some very hot url in ram by cache.config? (was: 1. should ts support some very hot url force to put in ram by cache.config?) Assignee: Bin Chen Summary: support forcing to put some very hot url in ram? (was: support some very hot url force to put in ram?) > support forcing to put some very hot url in ram? > > > Key: TS-2084 > URL: https://issues.apache.org/jira/browse/TS-2084 > Project: Traffic Server > Issue Type: Improvement > Components: Cache, HTTP >Reporter: Bin Chen >Assignee: Bin Chen > > 1. should ts support forcing to put some very hot url in ram by cache.config? -- This message 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-2084) support some very hot url force to put in ram?
Bin Chen created TS-2084: Summary: support some very hot url force to put in ram? Key: TS-2084 URL: https://issues.apache.org/jira/browse/TS-2084 Project: Traffic Server Issue Type: Improvement Components: Cache, HTTP Reporter: Bin Chen 1. should ts support some very hot url force to put in ram by cache.config? -- 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-1375) too many connections, throttling
[
https://issues.apache.org/jira/browse/TS-1375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13717929#comment-13717929
]
Bin Chen commented on TS-1375:
--
should we disable throttling? If connection is exceed, then ts can response 500?
> too many connections, throttling
>
>
> Key: TS-1375
> URL: https://issues.apache.org/jira/browse/TS-1375
> Project: Traffic Server
> Issue Type: Bug
> Components: Network
> Environment: centos 6.2 x86_64 ats from git(3.3.0)
>Reporter: bettydramit
>Assignee: Bin Chen
> Fix For: 3.5.0
>
>
> [Jul 20 09:09:19.787] Server {0x2ad5ddd00060} WARNING: too many open file
> descriptors, emergency throttling
> [Jul 20 09:09:19.788] Server {0x2ad5ded28700} WARNING: too many connections,
> throttling
> [Jul 20 09:19:19.823] Server {0x2ad5eb6d2700} WARNING: too many connections,
> throttling
> [Jul 20 09:19:22.634] Manager {0x7f10bc4327e0} NOTE: [Alarms::signalAlarm]
> Skipping Alarm: 'too many connections, throttling'
> [TrafficManager] ==> Cleaning up and reissuing signal #15
> [Jul 20 09:21:50.819] Manager {0x7f10bc4327e0} ERROR: [TrafficManager] ==>
> Cleaning up and reissuing signal #15
> [Jul 20 09:21:50.819] Manager {0x7f10bc4327e0} ERROR: (last system error 2:
> No such file or directory)
> NOTE: Traffic Server received Sig 15: Terminated
> [TrafficManager] ==> signal #15
--
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-1595) different domain have different origin_max_connections?
[ https://issues.apache.org/jira/browse/TS-1595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13717927#comment-13717927 ] Bin Chen commented on TS-1595: -- this issue will a part of new remap format > different domain have different origin_max_connections? > --- > > Key: TS-1595 > URL: https://issues.apache.org/jira/browse/TS-1595 > Project: Traffic Server > Issue Type: Sub-task > Components: Network >Reporter: Bin Chen >Assignee: Bin Chen >Priority: Minor > Fix For: sometime > > > In our env, we want different domain having different > "origin_max_connections" to manage connection more careful avoiding network > throttling. If not have different config in remap, use > "origin_max_connections" default. Other, config in remap will replace > "origin_max_connections". -- This message 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] [Closed] (TS-1280) add url match token about cache control rule
[ https://issues.apache.org/jira/browse/TS-1280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen closed TS-1280. Resolution: Fixed > add url match token about cache control rule > > > Key: TS-1280 > URL: https://issues.apache.org/jira/browse/TS-1280 > Project: Traffic Server > Issue Type: Improvement > Components: Configuration, HTTP, Performance >Affects Versions: 3.1.4 >Reporter: Zhao Yongming >Assignee: Bin Chen > Fix For: 3.5.0 > > Attachments: TS-1280.patch, url.patch > > > in a big hosting env, you may create many rules in cache.config, the > performance of the matching is critical, much liking remap, we need do some > performance tweak: > 1, how can we handle 1000+ rules? > 2, can we handle the full URL match? > 3, how to handle the path match, the better way > ... > place this issue as a track for all performance improvement -- 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-1280) add url match token about cache control rule
[ https://issues.apache.org/jira/browse/TS-1280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen updated TS-1280: - Attachment: TS-1280.patch rebase master > add url match token about cache control rule > > > Key: TS-1280 > URL: https://issues.apache.org/jira/browse/TS-1280 > Project: Traffic Server > Issue Type: Improvement > Components: Configuration, HTTP, Performance >Affects Versions: 3.1.4 >Reporter: Zhao Yongming >Assignee: Bin Chen > Fix For: 3.5.0 > > Attachments: TS-1280.patch, url.patch > > > in a big hosting env, you may create many rules in cache.config, the > performance of the matching is critical, much liking remap, we need do some > performance tweak: > 1, how can we handle 1000+ rules? > 2, can we handle the full URL match? > 3, how to handle the path match, the better way > ... > place this issue as a track for all performance improvement -- 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-1280) add url match token about cache control rule
[ https://issues.apache.org/jira/browse/TS-1280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen updated TS-1280: - Summary: add url match token about cache control rule (was: cache control rule matching performance tweak(add url token)) > add url match token about cache control rule > > > Key: TS-1280 > URL: https://issues.apache.org/jira/browse/TS-1280 > Project: Traffic Server > Issue Type: Improvement > Components: Configuration, HTTP, Performance >Affects Versions: 3.1.4 >Reporter: Zhao Yongming >Assignee: Bin Chen > Fix For: 3.5.0 > > Attachments: url.patch > > > in a big hosting env, you may create many rules in cache.config, the > performance of the matching is critical, much liking remap, we need do some > performance tweak: > 1, how can we handle 1000+ rules? > 2, can we handle the full URL match? > 3, how to handle the path match, the better way > ... > place this issue as a track for all performance improvement -- 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-1280) cache control rule matching performance tweak(add url token)
[ https://issues.apache.org/jira/browse/TS-1280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen updated TS-1280: - Summary: cache control rule matching performance tweak(add url token) (was: cache control rule matching performance tweak) > cache control rule matching performance tweak(add url token) > > > Key: TS-1280 > URL: https://issues.apache.org/jira/browse/TS-1280 > Project: Traffic Server > Issue Type: Improvement > Components: Configuration, HTTP, Performance >Affects Versions: 3.1.4 >Reporter: Zhao Yongming >Assignee: Bin Chen > Fix For: 3.5.0 > > Attachments: url.patch > > > in a big hosting env, you may create many rules in cache.config, the > performance of the matching is critical, much liking remap, we need do some > performance tweak: > 1, how can we handle 1000+ rules? > 2, can we handle the full URL match? > 3, how to handle the path match, the better way > ... > place this issue as a track for all performance improvement -- 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-2053) When Consumer(User agent)->write_vio.nbytes = INT64_MAX & Producer(Cache)->alive = false HttpSM will hung
[ https://issues.apache.org/jira/browse/TS-2053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen updated TS-2053: - Affects Version/s: (was: 3.3.4) Fix Version/s: (was: 3.3.5) 3.2.4 > When Consumer(User agent)->write_vio.nbytes = INT64_MAX & > Producer(Cache)->alive = false HttpSM will hung > -- > > Key: TS-2053 > URL: https://issues.apache.org/jira/browse/TS-2053 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Affects Versions: 3.2.4 >Reporter: Bin Chen >Assignee: Bin Chen > Fix For: 3.2.4 > > Attachments: TS-2053.patch > > > When Consumer(User agent)->write_vio.nbytes = INT64_MAX & > Producer(Cache)->alive = false, HttpClientSession->client_vc will be called > write_disable. So client_vc won't be handle when vc is timeout or closed. -- 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-2053) When Consumer(User agent)->write_vio.nbytes = INT64_MAX & Producer(Cache)->alive = false HttpSM will hung
[ https://issues.apache.org/jira/browse/TS-2053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen updated TS-2053: - Priority: Major (was: Blocker) > When Consumer(User agent)->write_vio.nbytes = INT64_MAX & > Producer(Cache)->alive = false HttpSM will hung > -- > > Key: TS-2053 > URL: https://issues.apache.org/jira/browse/TS-2053 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Affects Versions: 3.3.4, 3.2.4 >Reporter: Bin Chen >Assignee: Bin Chen > Fix For: 3.3.5 > > Attachments: TS-2053.patch > > > When Consumer(User agent)->write_vio.nbytes = INT64_MAX & > Producer(Cache)->alive = false, HttpClientSession->client_vc will be called > write_disable. So client_vc won't be handle when vc is timeout or closed. -- 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-2053) When Consumer(User agent)->write_vio.nbytes = INT64_MAX & Producer(Cache)->alive = false HttpSM will hung
[ https://issues.apache.org/jira/browse/TS-2053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen updated TS-2053: - Attachment: TS-2053.patch > When Consumer(User agent)->write_vio.nbytes = INT64_MAX & > Producer(Cache)->alive = false HttpSM will hung > -- > > Key: TS-2053 > URL: https://issues.apache.org/jira/browse/TS-2053 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Affects Versions: 3.3.4, 3.2.4 >Reporter: Bin Chen >Assignee: Bin Chen > Fix For: 3.3.6 > > Attachments: TS-2053.patch > > > When Consumer(User agent)->write_vio.nbytes = INT64_MAX & > Producer(Cache)->alive = false, HttpClientSession->client_vc will be called > write_disable. So client_vc won't be handle when vc is timeout or closed. -- 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-2053) When Consumer(User agent)->write_vio.nbytes = INT64_MAX & Producer(Cache)->alive = false HttpSM will hung
Bin Chen created TS-2053: Summary: When Consumer(User agent)->write_vio.nbytes = INT64_MAX & Producer(Cache)->alive = false HttpSM will hung Key: TS-2053 URL: https://issues.apache.org/jira/browse/TS-2053 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: Bin Chen When Consumer(User agent)->write_vio.nbytes = INT64_MAX & Producer(Cache)->alive = false, HttpClientSession->client_vc will be called write_disable. So client_vc won't be handle when vc is timeout or closed. -- 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-2053) When Consumer(User agent)->write_vio.nbytes = INT64_MAX & Producer(Cache)->alive = false HttpSM will hung
[ https://issues.apache.org/jira/browse/TS-2053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen updated TS-2053: - Affects Version/s: 3.3.4 3.2.4 Fix Version/s: 3.3.6 Assignee: Bin Chen > When Consumer(User agent)->write_vio.nbytes = INT64_MAX & > Producer(Cache)->alive = false HttpSM will hung > -- > > Key: TS-2053 > URL: https://issues.apache.org/jira/browse/TS-2053 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Affects Versions: 3.3.4, 3.2.4 >Reporter: Bin Chen >Assignee: Bin Chen > Fix For: 3.3.6 > > > When Consumer(User agent)->write_vio.nbytes = INT64_MAX & > Producer(Cache)->alive = false, HttpClientSession->client_vc will be called > write_disable. So client_vc won't be handle when vc is timeout or closed. -- 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] [Closed] (TS-1898) improve cluster read/write performance
[ https://issues.apache.org/jira/browse/TS-1898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen closed TS-1898. Resolution: Fixed > improve cluster read/write performance > -- > > Key: TS-1898 > URL: https://issues.apache.org/jira/browse/TS-1898 > Project: Traffic Server > Issue Type: Improvement > Components: Cache, Clustering >Affects Versions: 3.3.2 >Reporter: Zhao Yongming >Assignee: Bin Chen > Fix For: 3.5.0 > > Attachments: TS-1898.patch, TS-1898_v2.patch > > > we find out that cluster read and write performace is very poor, and even > worse whe the conten is >2MB larger, we should improve that. > a typical testing of 10MB file in cluster is about 10+s > we have a patch that will improve to 300-800ms, all testing in local 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-1898) improve cluster read/write performance
[ https://issues.apache.org/jira/browse/TS-1898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen updated TS-1898: - Attachment: TS-1898_v2.patch rebase on master > improve cluster read/write performance > -- > > Key: TS-1898 > URL: https://issues.apache.org/jira/browse/TS-1898 > Project: Traffic Server > Issue Type: Improvement > Components: Cache, Clustering >Affects Versions: 3.3.2 >Reporter: Zhao Yongming >Assignee: Bin Chen > Fix For: 3.5.0 > > Attachments: TS-1898.patch, TS-1898_v2.patch > > > we find out that cluster read and write performace is very poor, and even > worse whe the conten is >2MB larger, we should improve that. > a typical testing of 10MB file in cluster is about 10+s > we have a patch that will improve to 300-800ms, all testing in local 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] [Closed] (TS-1520) CacheContinuation->timeout->m_ptr is null, then core
[
https://issues.apache.org/jira/browse/TS-1520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bin Chen closed TS-1520.
Resolution: Fixed
> CacheContinuation->timeout->m_ptr is null, then core
>
>
> Key: TS-1520
> URL: https://issues.apache.org/jira/browse/TS-1520
> Project: Traffic Server
> Issue Type: Bug
> Components: Clustering, Core
>Affects Versions: 3.2.0
> Environment: LOCAL proxy.local.cluster.type INT 1
>Reporter: Bin Chen
>Assignee: Bin Chen
> Fix For: 3.3.6
>
>
> {code}
> Core was generated by `/usr/bin/traffic_server -M --httpport
> 8080:fd=12,80:fd=15'.
> Program terminated with signal 11, Segmentation fault.
> #0 0x2b58f03cc080 in ?? ()
> Missing separate debuginfos, use: debuginfo-install
> expat-2.0.1-9.1.el6.x86_64 glibc-2.12-1.47.el6.x86_64
> keyutils-libs-1.4-3.el6.x86_64 krb5-libs-1.9-22.el6.x86_64
> libcom_err-1.41.12-11.el6.x86_64 libgcc-4.4.6-3.el6.x86_64
> libselinux-2.0.94-5.2.el6.x86_64 libstdc++-4.4.6-3.el6.x86_64
> ncurses-libs-5.7-3.20090208.el6.x86_64 openssl-1.0.0-20.el6.x86_64
> pcre-7.8-3.1.el6.x86_64 readline-6.0-3.el6.x86_64 tcl-8.5.7-6.el6.x86_64
> xz-libs-4.999.9-0.3.beta.20091007git.el6.x86_64 zlib-1.2.3-27.el6.x86_64
> #0 0x2b58f03cc080 in ?? ()
> #1 0x00647db6 in CacheContinuation::remoteOpEvent
> (this=0x2b58d9803000, event_code=1151, e=0x2b58f0323380)
> at ClusterCache.cc:2289
> #2 0x004e6e02 in Continuation::handleEvent (this=0x2b58d9803000,
> event=1151, data=0x2b58f0323380)
> at ../iocore/eventsystem/I_Continuation.h:146
> #3 0x00647280 in cache_op_result_ClusterFunction (ch=0x2b58d922fbd0,
> d=0x2b58f0323318, l=28) at ClusterCache.cc:2088
> #4 0x006513a0 in ClusterHandler::process_incoming_callouts
> (this=0x2b58d922fbd0, m=0x2b59d801b4a0)
> at ClusterHandler.cc:1215
> #5 0x0065963f in ClusterCalloutContinuation::CalloutHandler
> (this=0x2b59d001bf60, event=2, e=0x2b58f00031e0)
> at ClusterHandlerBase.cc:62
> #6 0x004e6e02 in Continuation::handleEvent (this=0x2b59d001bf60,
> event=2, data=0x2b58f00031e0)
> at ../iocore/eventsystem/I_Continuation.h:146
> #7 0x006d95be in EThread::process_event (this=0x2b58b99c6010,
> e=0x2b58f00031e0, calling_code=2)
> at UnixEThread.cc:142
> #8 0x006d98d9 in EThread::execute (this=0x2b58b99c6010) at
> UnixEThread.cc:221
> #9 0x006d8887 in spawn_thread_internal (a=0x22a6970) at Thread.cc:88
> #10 0x0030308077f1 in start_thread () from /lib64/libpthread.so.0
> #11 0x0030304e570d in clone () from /lib64/libc.so.6
> (gdb) f 1
> #1 0x00647db6 in CacheContinuation::remoteOpEvent
> (this=0x2b58d9803000, event_code=1151, e=0x2b58f0323380)
> at ClusterCache.cc:2289
> /usr/src/debug/trafficserver-3.2.0/iocore/cluster/ClusterCache.cc:2289:77022:beg:0x647db6
> (gdb) l
> 2284 case CACHE_EVENT_RESPONSE_MSG:{
> 2285
> 2286 // the response has arrived, cancel timeout
> 2287
> 2288 if (timeout) {
> 2289timeout->cancel();
> 2290timeout = 0;
> 2291 }
> 2292 // remove from the pending queue
> 2293 unsigned int hash = FOLDHASH(target_ip, seq_number);
> (gdb) p timeout
> $1 = (Event *) 0x2b58e8008c70
> (gdb) p *timeout
> $2 = { = {_vptr.Action = 0x2b5a0c0022a0, continuation =
> 0x2b58d97fd600, mutex = {m_ptr = 0x0}, cancelled = 0},
> ethread = 0x2b58b94c1010, in_the_prot_queue = 0, in_the_priority_queue = 0,
> immediate = 0, globally_allocated = 1,
> in_heap = 9, callback_event = 2, timeout_at = 1349964312579683000, period =
> 0, cookie = 0x0, link = {> = {
> next = 0x0}, prev = 0x0}}
> {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] [Closed] (TS-1482) enable define INACTIVITY_TIMEOUT, Action::cancel_action will assert
[ https://issues.apache.org/jira/browse/TS-1482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen closed TS-1482. Resolution: Fixed > enable define INACTIVITY_TIMEOUT, Action::cancel_action will assert > --- > > Key: TS-1482 > URL: https://issues.apache.org/jira/browse/TS-1482 > Project: Traffic Server > Issue Type: Sub-task > Components: Core >Affects Versions: 3.2.0 >Reporter: Bin Chen >Assignee: Bin Chen > Fix For: 3.3.6 > > > enable define INACTIVITY_TIMEOUT, Action::cancel_action will assertï¼›because > of inactivity_timeout will be used by two UnixNetVConnection. Why? > #0 0x003e38232885 in raise () from /lib64/libc.so.6 > #1 0x003e38234065 in abort () from /lib64/libc.so.6 > #2 0x003134c1cbf4 in ink_die_die_die (retval=1) at ink_error.cc:43 > #3 0x003134c1ccc6 in ink_fatal_va(int, const char *, typedef > __va_list_tag __va_list_tag *) (return_code=1, > message_format=0x3134c3a100 "%s:%d: failed assert `%s`", > ap=0x759a7030) at ink_error.cc:65 > #4 0x003134c1cd91 in ink_fatal (return_code=1, > message_format=0x3134c3a100 "%s:%d: failed assert `%s`") at ink_error.cc:73 > #5 0x003134c1bb54 in _ink_assert (expression=0x753564 "!c || c == > continuation", file=0x753540 "../../iocore/eventsystem/I_Action.h", line=162) > at ink_assert.cc:38 > #6 0x00685231 in Action::cancel_action (this=0x7fffb800c890, > c=0x7fffc4027bd0) at ../../iocore/eventsystem/I_Action.h:162 > #7 0x006852b4 in Event::cancel_action (this=0x7fffb800c890, > c=0x7fffc4027bd0) at ../../iocore/eventsystem/P_UnixEvent.h:40 > #8 0x006bf574 in UnixNetVConnection::set_inactivity_timeout > (this=0x7fffc4027bd0, timeout=300) at P_UnixNetVConnection.h:284 > #9 0x0057d8cd in HttpSM::attach_server_session (this=0x7fffed1db190, > s=0x7fffcc03ff50) at HttpSM.cc:5214 > #10 0x0056ad56 in _acquire_session (bucket=0xc94000, > ip=0x7fffed1db828, hostname_hash=..., sm=0x7fffed1db190) at > HttpSessionManager.cc:245 > #11 0x0056b10f in HttpSessionManager::acquire_session (this=0xc93720, > cont=0x7fffed1db190, ip=0x7fffed1db828, > hostname=0x7fffcc0290e9 "115.238.23.58", ua_session=0x7fffcc010f40, > sm=0x7fffed1db190) at HttpSessionManager.cc:323 > #12 0x0057a68f in HttpSM::do_http_server_open (this=0x7fffed1db190, > raw=false) at HttpSM.cc:4208 > #13 0x00582294 in HttpSM::set_next_state (this=0x7fffed1db190) at > HttpSM.cc:6603 > #14 0x005818b5 in HttpSM::call_transact_and_set_next_state > (this=0x7fffed1db190, f=0) at HttpSM.cc:6438 > #15 0x00573683 in HttpSM::state_cache_open_write > (this=0x7fffed1db190, event=1108, data=0x7fffdc16df80) at HttpSM.cc:2358 > #16 0x00573ebe in HttpSM::main_handler (this=0x7fffed1db190, > event=1108, data=0x7fffdc16df80) at HttpSM.cc:2465 > #17 0x004e8b3c in Continuation::handleEvent (this=0x7fffed1db190, > event=1108, data=0x7fffdc16df80) at ../iocore/eventsystem/I_Continuation.h:146 > #18 0x0055b3a0 in HttpCacheSM::state_cache_open_write > (this=0x7fffed1dd258, event=1108, data=0x7fffdc16df80) at HttpCacheSM.cc:172 > #19 0x004e8b3c in Continuation::handleEvent (this=0x7fffed1dd258, > event=1108, data=0x7fffdc16df80) at ../iocore/eventsystem/I_Continuation.h:146 > #20 0x006a3fad in CacheVC::callcont (this=0x7fffdc16df80, event=1108) > at P_CacheInternal.h:636 > #21 0x006ac3de in Cache::open_write (this=0x7fffe00045d0, > cont=0x7fffed1dd258, key=0x759a7860, info=0x0, apin_in_cache=0, key1=0x0, > type=CACHE_FRAG_TYPE_HTTP, hostname=0x7fffedab5041 > "ts.cn801ts/18297/253est222.cn8 > (ApacheTrafficServer/3.2.0)ATS/3.2.0(ApacheTrafficServer/3.2.0)", > host_len=5) at CacheWrite.cc:1830 > #22 0x006870ca in Cache::open_write (this=0x7fffe00045d0, > cont=0x7fffed1dd258, url=0x7fffed1db230, request=0x7fffed1db888, > old_info=0x0, > pin_in_cache=0, type=CACHE_FRAG_TYPE_HTTP) at P_CacheInternal.h:1083 > #23 0x00684e69 in CacheProcessor::open_write (this=0x1222740, > cont=0x7fffed1dd258, expected_size=0, url=0x7fffed1db230, > cluster_cache_local=false, > request=0x7fffed1db888, old_info=0x0, pin_in_cache=0, > type=CACHE_FRAG_TYPE_HTTP) at Cache.cc:2811 > #24 0x0055b975 in HttpCacheSM::open_write (this=0x7fffed1dd258, > url=0x7fffed1db230, request=0x7fffed1db888, old_info=0x0, pin_in_cache=0, > retry=true, allow_multiple=false) at HttpCacheSM.cc:309 > #25 0x00579f05 in HttpSM::do_cache_prepare_action > (this=0x7fffed1db190, c_sm=0x7fffed1dd258, object_read_info=0x0, retry=true, > allow_multiple=false) > at HttpSM.cc:4111 > #26 0x005879e2 in HttpSM::do_cache_prepare_write > (this=0x7fffed1db190) at HttpSM.cc:4029 > #27
[jira] [Updated] (TS-1898) improve cluster read/write performance
[ https://issues.apache.org/jira/browse/TS-1898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen updated TS-1898: - Attachment: TS-1898.patch 1.add atomiclist to notify vc is ready 2.remove clustervc schedule handle > improve cluster read/write performance > -- > > Key: TS-1898 > URL: https://issues.apache.org/jira/browse/TS-1898 > Project: Traffic Server > Issue Type: Improvement > Components: Cache, Clustering >Affects Versions: 3.3.2 >Reporter: Zhao Yongming >Assignee: Bin Chen > Fix For: 3.3.6 > > Attachments: TS-1898.patch > > > we find out that cluster read and write performace is very poor, and even > worse whe the conten is >2MB larger, we should improve that. > a typical testing of 10MB file in cluster is about 10+s > we have a patch that will improve to 300-800ms, all testing in local 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] [Closed] (TS-1957) if CacheContinuation timeout, timeout Event will be loop
[ https://issues.apache.org/jira/browse/TS-1957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen closed TS-1957. Resolution: Fixed > if CacheContinuation timeout, timeout Event will be loop > - > > Key: TS-1957 > URL: https://issues.apache.org/jira/browse/TS-1957 > Project: Traffic Server > Issue Type: Bug > Components: Clustering >Affects Versions: 3.3.4, 3.2.4 >Reporter: Bin Chen >Assignee: Bin Chen > Fix For: 3.3.5 > > Attachments: TS-1957.patch, TS-1957_v2.patch > > -- 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-1006) memory management, cut down memory waste ?
[
https://issues.apache.org/jira/browse/TS-1006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bin Chen reassigned TS-1006:
Assignee: Yunkai Zhang (was: Bin Chen)
> memory management, cut down memory waste ?
> --
>
> Key: TS-1006
> URL: https://issues.apache.org/jira/browse/TS-1006
> Project: Traffic Server
> Issue Type: Improvement
> Components: Core
>Affects Versions: 3.1.1
>Reporter: Zhao Yongming
>Assignee: Yunkai Zhang
> Fix For: 3.3.6
>
> Attachments:
> 0001-TS-1006-Add-an-enable-reclaimable-freelist-option.patch,
> 0002-TS-1006-Add-a-new-wrapper-ink_atomic_decrement.patch,
> 0003-TS-1006-Introduce-a-reclaimable-InkFreeList.patch,
> 0004-TS-1006-Make-InkFreeList-memory-pool-configurable.patch,
> Memory-Usage-After-Introduced-New-Allocator.png, memusage.ods, memusage.ods
>
>
> when we review the memory usage in the production, there is something
> abnormal, ie, looks like TS take much memory than index data + common system
> waste, and here is some memory dump result by set
> "proxy.config.dump_mem_info_frequency"
> 1, the one on a not so busy forwarding system:
> physics memory: 32G
> RAM cache: 22G
> DISK: 6140 GB
> average_object_size 64000
> {code}
> allocated |in-use | type size | free list name
> |||--
> 671088640 | 37748736 |2097152 |
> memory/ioBufAllocator[14]
> 2248146944 | 2135949312 |1048576 |
> memory/ioBufAllocator[13]
> 1711276032 | 1705508864 | 524288 |
> memory/ioBufAllocator[12]
> 1669332992 | 1667760128 | 262144 |
> memory/ioBufAllocator[11]
> 2214592512 | 221184 | 131072 |
> memory/ioBufAllocator[10]
> 2325741568 | 2323775488 | 65536 |
> memory/ioBufAllocator[9]
> 2091909120 | 2089123840 | 32768 |
> memory/ioBufAllocator[8]
> 1956642816 | 1956478976 | 16384 |
> memory/ioBufAllocator[7]
> 2094530560 | 2094071808 | 8192 |
> memory/ioBufAllocator[6]
> 356515840 | 355540992 | 4096 |
> memory/ioBufAllocator[5]
> 1048576 | 14336 | 2048 |
> memory/ioBufAllocator[4]
> 131072 | 0 | 1024 |
> memory/ioBufAllocator[3]
> 65536 | 0 |512 |
> memory/ioBufAllocator[2]
> 32768 | 0 |256 |
> memory/ioBufAllocator[1]
> 16384 | 0 |128 |
> memory/ioBufAllocator[0]
> 0 | 0 |576 |
> memory/ICPRequestCont_allocator
> 0 | 0 |112 |
> memory/ICPPeerReadContAllocator
> 0 | 0 |432 |
> memory/PeerReadDataAllocator
> 0 | 0 | 32 |
> memory/MIMEFieldSDKHandle
> 0 | 0 |240 |
> memory/INKVConnAllocator
> 0 | 0 | 96 |
> memory/INKContAllocator
>4096 | 0 | 32 |
> memory/apiHookAllocator
> 0 | 0 |288 |
> memory/FetchSMAllocator
> 0 | 0 | 80 |
> memory/prefetchLockHandlerAllocator
> 0 | 0 |176 |
> memory/PrefetchBlasterAllocator
> 0 | 0 | 80 |
> memory/prefetchUrlBlaster
> 0 | 0 | 96 | memory/blasterUrlList
> 0 | 0 | 96 |
> memory/prefetchUrlEntryAllocator
> 0 | 0 |128 |
> memory/socksProxyAllocator
> 0 | 0 |144 |
> memory/ObjectReloadCont
> 3258368 | 576016 |592 |
> memory/httpClientSessionAllocator
> 825344 | 139568 |208 |
> memory/httpServerSessionAllocator
>22597632 |1284848 | 9808 | memory/httpSMAllocator
> 0 | 0 | 32 |
> memory/CacheLookupHttpConfigAllocator
> 0 | 0 | 9856 |
> memory/httpUpdateSMAllocator
> 0 | 0 |128 |
> memory/RemapPluginsAlloc
> 0 | 0 | 48 |
> memory/CongestRequestParamAllocator
> 0 | 0 |128 |
> memory/CongestionDBContAllocator
> 5767168 | 704512 | 2048 | memory/hdr
[jira] [Updated] (TS-1967) create max accept handler function
[ https://issues.apache.org/jira/browse/TS-1967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen updated TS-1967: - Attachment: TS-1967.patch add max accept & max client transactions limit. when exceed then drop request. > create max accept handler function > --- > > Key: TS-1967 > URL: https://issues.apache.org/jira/browse/TS-1967 > Project: Traffic Server > Issue Type: Improvement > Components: Network >Affects Versions: 3.2.4 >Reporter: Bin Chen >Assignee: Bin Chen > Attachments: TS-1967.patch > > -- 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-1967) create max accept handler function
[ https://issues.apache.org/jira/browse/TS-1967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen updated TS-1967: - Assignee: Bin Chen Issue Type: Improvement (was: Bug) Affects Version/s: 3.2.4 > create max accept handler function > --- > > Key: TS-1967 > URL: https://issues.apache.org/jira/browse/TS-1967 > Project: Traffic Server > Issue Type: Improvement > Components: Network >Affects Versions: 3.2.4 >Reporter: Bin Chen >Assignee: Bin Chen > -- 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-1967) create max accept handler function
Bin Chen created TS-1967: Summary: create max accept handler function Key: TS-1967 URL: https://issues.apache.org/jira/browse/TS-1967 Project: Traffic Server Issue Type: Bug Components: Network Reporter: Bin Chen -- 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-1957) if CacheContinuation timeout, timeout Event will be loop
[ https://issues.apache.org/jira/browse/TS-1957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen updated TS-1957: - Attachment: TS-1957_v2.patch > if CacheContinuation timeout, timeout Event will be loop > - > > Key: TS-1957 > URL: https://issues.apache.org/jira/browse/TS-1957 > Project: Traffic Server > Issue Type: Bug > Components: Clustering >Affects Versions: 3.3.4, 3.2.4 >Reporter: Bin Chen >Assignee: Bin Chen > Fix For: 3.3.5 > > Attachments: TS-1957.patch, TS-1957_v2.patch > > -- 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-1957) if CacheContinuation timeout, timeout Event will be loop
[ https://issues.apache.org/jira/browse/TS-1957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen updated TS-1957: - Attachment: TS-1957.patch > if CacheContinuation timeout, timeout Event will be loop > - > > Key: TS-1957 > URL: https://issues.apache.org/jira/browse/TS-1957 > Project: Traffic Server > Issue Type: Bug > Components: Clustering >Affects Versions: 3.3.4, 3.2.4 >Reporter: Bin Chen >Assignee: Bin Chen > Fix For: 3.3.5 > > Attachments: TS-1957.patch > > -- 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-1957) if CacheContinuation timeout, timeout Event will be loop
[ https://issues.apache.org/jira/browse/TS-1957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13683463#comment-13683463 ] Bin Chen commented on TS-1957: -- In cluster mode, if CacheContinuation timeout, the "proxy.process.cluster.remote_op_timeouts" in stat will be increase more and more. > if CacheContinuation timeout, timeout Event will be loop > - > > Key: TS-1957 > URL: https://issues.apache.org/jira/browse/TS-1957 > Project: Traffic Server > Issue Type: Bug > Components: Clustering >Reporter: Bin Chen >Assignee: Bin Chen > -- 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-1957) if CacheContinuation timeout, timeout Event will be loop
[ https://issues.apache.org/jira/browse/TS-1957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen reassigned TS-1957: Assignee: Bin Chen > if CacheContinuation timeout, timeout Event will be loop > - > > Key: TS-1957 > URL: https://issues.apache.org/jira/browse/TS-1957 > Project: Traffic Server > Issue Type: Bug > Components: Clustering >Reporter: Bin Chen >Assignee: Bin Chen > -- 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-1957) if CacheContinuation timeout, timeout Event will be loop
Bin Chen created TS-1957: Summary: if CacheContinuation timeout, timeout Event will be loop Key: TS-1957 URL: https://issues.apache.org/jira/browse/TS-1957 Project: Traffic Server Issue Type: Bug Components: Clustering Reporter: Bin Chen -- 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-1757) core at LogUtils::escapify_url()
[
https://issues.apache.org/jira/browse/TS-1757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bin Chen reassigned TS-1757:
Assignee: Yunkai Zhang (was: taorui)
> core at LogUtils::escapify_url()
>
>
> Key: TS-1757
> URL: https://issues.apache.org/jira/browse/TS-1757
> Project: Traffic Server
> Issue Type: Bug
> Components: Logging
>Reporter: Bin Chen
>Assignee: Yunkai Zhang
> Labels: crash
> Fix For: 3.3.4
>
>
> {code}
> NOTE: Traffic Server received Sig 11: Segmentation fault
> /usr/bin/traffic_server - STACK TRACE:
> /lib64/libpthread.so.0[0x39ab20f4a0]
> /usr/bin/traffic_server(LogUtils::e虽scapify_url(Arena*, char*, unsigned long,
> int*, char*, unsigned long, unsigned char const*)+0x60)[0x5b8550]
> /usr/bin/traffic_server(LogAccessHttp::init()+0xbc)[0x59864c]
> /usr/bin/traffic_server(Log::access(LogAccess*)+0x11e)[0x59b3ce]
> /usr/bin/traffic_server(HttpSM::update_stats()+0x630)[0x52be20]
> /usr/bin/traffic_server(HttpSM::kill_this()+0x928)[0x5374d8]
> /usr/bin/traffic_server(HttpSM::main_handler(int, void*)+0x198)[0x5377f8]虽
> /usr/bin/traffic_server[0x68727b]
> /usr/bin/traffic_server(UnixNetVConnection::mainEvent(int,
> Event*)+0x5df)[0x68989f]
> /usr/bin/traffic_server(InactivityCop::check_inactivity(int,
> Event*)+0xa6)[0x6839b6]
> /usr/bin/traffic_server(EThread::process_event(Event*, int)+0xb4)[0x6ac714]
> /usr/bin/traffic_server(PriorityEventQueue::check_ready(long,
> EThread*)+0x17b)[0x6aebab]
> /usr/bin/traffic_server(EThread::execute()+0x12c)[0x6acd0c]虽
> /usr/bin/traffic_server[0x6ab2b2]
> /lib64/libpthread.so.0[0x39ab2077f1]
> /lib64/libc.so.6(clone+0x6d)[0x39aaee570d]
> {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] [Created] (TS-1906) crash at BaseStatPagesHandler::resp_add
Bin Chen created TS-1906:
Summary: crash at BaseStatPagesHandler::resp_add
Key: TS-1906
URL: https://issues.apache.org/jira/browse/TS-1906
Project: Traffic Server
Issue Type: Bug
Components: Web site
Reporter: Bin Chen
{code}
#0 0x003984b3ef48 in __memcpy_ssse3_back () from /lib64/libc.so.6
Missing separate debuginfos, use: debuginfo-install expat-2.0.1-9.1.el6.x86_64
glibc-2.12-1.47.el6.x86_64 keyutils-libs-1.4-3.el6.x86_64
krb5-libs-1.9-22.el6.x86_64 libattr-2.4.44-7.el6.x86_64
libcap-2.16-5.5.el6.x86_64 libcom_err-1.41.12-11.el6.x86_64
libgcc-4.4.6-3.el6.x86_64 libselinux-2.0.94-5.2.el6.x86_64
libstdc++-4.4.6-3.el6.x86_64 ncurses-libs-5.7-3.20090208.el6.x86_64
openssl-1.0.0-20.el6.x86_64 pcre-7.8-3.1.el6.x86_64 readline-6.0-3.el6.x86_64
tcl-8.5.7-6.el6.x86_64 xz-libs-4.999.9-0.3.beta.20091007git.el6.x86_64
zlib-1.2.3-27.el6.x86_64
(gdb) bt
#0 0x003984b3ef48 in __memcpy_ssse3_back () from /lib64/libc.so.6
#1 0x004e59f0 in BaseStatPagesHandler::resp_add (this=0x2ad6205cdf10,
fmt=) at StatPages.cc:181
#2 0x0057658c in HttpPagesHandler::handle_smlist (this=0x2ad6205cdf10,
event=, data=)
at HttpPages.cc:419
#3 0x006aa0b4 in handleEvent (this=0x2ad60931d010, e=0x2ad6402cf310,
calling_code=1) at I_Continuation.h:146
#4 EThread::process_event (this=0x2ad60931d010, e=0x2ad6402cf310,
calling_code=1) at UnixEThread.cc:142
#5 0x006aac1b in EThread::execute (this=0x2ad60931d010) at
UnixEThread.cc:193
#6 0x006a9052 in spawn_thread_internal (a=0x317b860) at Thread.cc:88
#7 0x003984e077f1 in start_thread () from /lib64/libpthread.so.0
#8 0x003984ae570d in clone () from /lib64/libc.so.6
(gdb) f 1
#1 0x004e59f0 in BaseStatPagesHandler::resp_add (this=0x2ad6205cdf10,
fmt=) at StatPages.cc:181
/usr/src/debug/trafficserver-3.2.0/proxy/StatPages.cc:181:4220:beg:0x4e59f0
(gdb) l
176 response = (char *)ats_realloc(response, size);
177 }
178 response_size = size;
179 }
180
181 memcpy(&response[response_length], buf, length + 1);
182 response_length += length;
183 }
184
185 void
(gdb) p length
$1 = 38015
{code}
char buf[16384], but length = 38015
--
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-1453) remove InactivityCop and enable define INACTIVITY_TIMEOUT
[ https://issues.apache.org/jira/browse/TS-1453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13635969#comment-13635969 ] Bin Chen commented on TS-1453: -- this patch can be not depending on TS-1405. In our env, ts should handle 200 thounds connections(InActiveCop should check every 1 second every conntions, It's so terrible). Now, we should improve cpu usage. The same box and same qps, our custom proxy use cpu about 60% of ts. > remove InactivityCop and enable define INACTIVITY_TIMEOUT > - > > Key: TS-1453 > URL: https://issues.apache.org/jira/browse/TS-1453 > Project: Traffic Server > Issue Type: Sub-task > Components: Core >Affects Versions: 3.2.0 >Reporter: Bin Chen >Assignee: Bin Chen > Fix For: 3.3.5 > > Attachments: TS-1453.patch > > > when we have O(1), then we can be enable define INACTIVITY_TIMEOUT -- 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-1453) remove InactivityCop and enable define INACTIVITY_TIMEOUT
[ https://issues.apache.org/jira/browse/TS-1453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen updated TS-1453: - Attachment: (was: TS-1453.patch) > remove InactivityCop and enable define INACTIVITY_TIMEOUT > - > > Key: TS-1453 > URL: https://issues.apache.org/jira/browse/TS-1453 > Project: Traffic Server > Issue Type: Sub-task > Components: Core >Affects Versions: 3.2.0 >Reporter: Bin Chen >Assignee: Bin Chen > Fix For: 3.3.5 > > Attachments: TS-1453.patch > > > when we have O(1), then we can be enable define INACTIVITY_TIMEOUT -- 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-1453) remove InactivityCop and enable define INACTIVITY_TIMEOUT
[ https://issues.apache.org/jira/browse/TS-1453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen updated TS-1453: - Attachment: TS-1453.patch base git master + TS-1405(linux_time_wheel_v11jp.patch) > remove InactivityCop and enable define INACTIVITY_TIMEOUT > - > > Key: TS-1453 > URL: https://issues.apache.org/jira/browse/TS-1453 > Project: Traffic Server > Issue Type: Sub-task > Components: Core >Affects Versions: 3.2.0 >Reporter: Bin Chen >Assignee: Bin Chen > Fix For: 3.3.5 > > Attachments: TS-1453.patch > > > when we have O(1), then we can be enable define INACTIVITY_TIMEOUT -- 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-1453) remove InactivityCop and enable define INACTIVITY_TIMEOUT
[ https://issues.apache.org/jira/browse/TS-1453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13634992#comment-13634992 ] Bin Chen commented on TS-1453: -- John & Leif, please help to review this patch(replace InActivCop), Thanks. > remove InactivityCop and enable define INACTIVITY_TIMEOUT > - > > Key: TS-1453 > URL: https://issues.apache.org/jira/browse/TS-1453 > Project: Traffic Server > Issue Type: Sub-task > Components: Core >Affects Versions: 3.2.0 >Reporter: Bin Chen >Assignee: Bin Chen > Fix For: 3.3.5 > > Attachments: TS-1453.patch > > > when we have O(1), then we can be enable define INACTIVITY_TIMEOUT -- 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-1453) remove InactivityCop and enable define INACTIVITY_TIMEOUT
[ https://issues.apache.org/jira/browse/TS-1453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen updated TS-1453: - Attachment: TS-1453.patch > remove InactivityCop and enable define INACTIVITY_TIMEOUT > - > > Key: TS-1453 > URL: https://issues.apache.org/jira/browse/TS-1453 > Project: Traffic Server > Issue Type: Sub-task > Components: Core >Affects Versions: 3.2.0 >Reporter: Bin Chen >Assignee: Bin Chen > Fix For: 3.3.5 > > Attachments: TS-1453.patch > > > when we have O(1), then we can be enable define INACTIVITY_TIMEOUT -- 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] [Comment Edited] (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=13631560#comment-13631560
]
Bin Chen edited comment on TS-1405 at 4/15/13 7:44 AM:
---
http_load test:
Very important:
* disabe ram cache (If not, test may be not in control).
* should run more time http_load, becasue of the first result may be not precise
url.txt:
total 50 urls.
the last number is the size of object.
{code}
http://ts.cn:8080/ts/20400
http://ts.cn:8080/ts/20401
http://ts.cn:8080/ts/20402
..
http://ts.cn:8080/ts/20448
http://ts.cn:8080/ts/20449
{code}
git master:
cpu: 230
{code}
[root@test69 ~]# http_load -parallel 100 -seconds 60 -keep_alive 100 ./url.txt
331224 fetches on 3325 conns, 100 max parallel, 6.76508e+09 bytes, in 60 seconds
20424.5 mean bytes/fetch
5520.4 fetches/sec, 1.12751e+08 bytes/sec
msecs/connect: 0.134652 mean, 0.846 max, 0.049 min
msecs/first-response: 16.4409 mean, 89.136 max, 0.3 min
HTTP response codes:
code 200 -- 331224
{code}
git master + linux_time_wheel_v11jp.patch
cpu: 240
{code}
[root@test69 ~]# http_load -parallel 100 -seconds 60 -keep_alive 100 ./url.txt
339305 fetches on 3408 conns, 100 max parallel, 6.93014e+09 bytes, in 60 seconds
20424.5 mean bytes/fetch
5655.08 fetches/sec, 1.15502e+08 bytes/sec
msecs/connect: 0.135805 mean, 0.561 max, 0.052 min
msecs/first-response: 15.9165 mean, 78.146 max, 0.28 min
HTTP response codes:
code 200 -- 339305
{code}
using patch, the cpu usage become high because of our fast recycle cancelled
event. So we should be careful if sensitive about cpu.
was (Author: kuotai):
http_load test:
Very important:
* disabe ram cache (If not, test may be not in control).
* should run more time http_load, becasue of the first result may be not precise
git master:
{code}
[root@test69 ~]# http_load -parallel 100 -seconds 60 -keep_alive 100 ./url.txt
331224 fetches on 3325 conns, 100 max parallel, 6.76508e+09 bytes, in 60 seconds
20424.5 mean bytes/fetch
5520.4 fetches/sec, 1.12751e+08 bytes/sec
msecs/connect: 0.134652 mean, 0.846 max, 0.049 min
msecs/first-response: 16.4409 mean, 89.136 max, 0.3 min
HTTP response codes:
code 200 -- 331224
{code}
git master + linux_time_wheel_v11jp.patch
{code}
[root@test69 ~]# http_load -parallel 100 -seconds 60 -keep_alive 100 ./url.txt
339305 fetches on 3408 conns, 100 max parallel, 6.93014e+09 bytes, in 60 seconds
20424.5 mean bytes/fetch
5655.08 fetches/sec, 1.15502e+08 bytes/sec
msecs/connect: 0.135805 mean, 0.561 max, 0.052 min
msecs/first-response: 15.9165 mean, 78.146 max, 0.28 min
HTTP response codes:
code 200 -- 339305
{code}
> 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.2
>
> Attachments: linux_time_wheel.patch, linux_time_wheel_v10jp.patch,
> linux_time_wheel_v11jp.patch, linux_time_wheel_v2.patch,
> linux_time_wheel_v3.patch, linux_time_wheel_v4.patch,
> linux_time_wheel_v5.patch, linux_time_wheel_v6.patch,
> linux_time_wheel_v7.patch, linux_time_wheel_v8.patch,
> linux_time_wheel_v9jp.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=13631560#comment-13631560
]
Bin Chen commented on TS-1405:
--
http_load test:
Very important:
* disabe ram cache (If not, test may be not in control).
* should run more time http_load, becasue of the first result may be not precise
git master:
{code}
[root@test69 ~]# http_load -parallel 100 -seconds 60 -keep_alive 100 ./url.txt
331224 fetches on 3325 conns, 100 max parallel, 6.76508e+09 bytes, in 60 seconds
20424.5 mean bytes/fetch
5520.4 fetches/sec, 1.12751e+08 bytes/sec
msecs/connect: 0.134652 mean, 0.846 max, 0.049 min
msecs/first-response: 16.4409 mean, 89.136 max, 0.3 min
HTTP response codes:
code 200 -- 331224
{code}
git master + linux_time_wheel_v11jp.patch
{code}
[root@test69 ~]# http_load -parallel 100 -seconds 60 -keep_alive 100 ./url.txt
339305 fetches on 3408 conns, 100 max parallel, 6.93014e+09 bytes, in 60 seconds
20424.5 mean bytes/fetch
5655.08 fetches/sec, 1.15502e+08 bytes/sec
msecs/connect: 0.135805 mean, 0.561 max, 0.052 min
msecs/first-response: 15.9165 mean, 78.146 max, 0.28 min
HTTP response codes:
code 200 -- 339305
{code}
> 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.2
>
> Attachments: linux_time_wheel.patch, linux_time_wheel_v10jp.patch,
> linux_time_wheel_v11jp.patch, linux_time_wheel_v2.patch,
> linux_time_wheel_v3.patch, linux_time_wheel_v4.patch,
> linux_time_wheel_v5.patch, linux_time_wheel_v6.patch,
> linux_time_wheel_v7.patch, linux_time_wheel_v8.patch,
> linux_time_wheel_v9jp.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] [Issue Comment Deleted] (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:
-
Comment: was deleted
(was: url.txt:
total 50 urls.
the last number is the size of object.
{code}
http://ts.cn:8080/ts/20400
http://ts.cn:8080/ts/20401
http://ts.cn:8080/ts/20402
..
http://ts.cn:8080/ts/20448
http://ts.cn:8080/ts/20449
{code})
> 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.2
>
> Attachments: linux_time_wheel.patch, linux_time_wheel_v10jp.patch,
> linux_time_wheel_v11jp.patch, linux_time_wheel_v2.patch,
> linux_time_wheel_v3.patch, linux_time_wheel_v4.patch,
> linux_time_wheel_v5.patch, linux_time_wheel_v6.patch,
> linux_time_wheel_v7.patch, linux_time_wheel_v8.patch,
> linux_time_wheel_v9jp.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=13631562#comment-13631562
]
Bin Chen commented on TS-1405:
--
url.txt:
total 50 urls.
the last number is the size of object.
{code}
http://ts.cn:8080/ts/20400
http://ts.cn:8080/ts/20401
http://ts.cn:8080/ts/20402
..
http://ts.cn:8080/ts/20448
http://ts.cn:8080/ts/20449
{code}
> 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.2
>
> Attachments: linux_time_wheel.patch, linux_time_wheel_v10jp.patch,
> linux_time_wheel_v11jp.patch, linux_time_wheel_v2.patch,
> linux_time_wheel_v3.patch, linux_time_wheel_v4.patch,
> linux_time_wheel_v5.patch, linux_time_wheel_v6.patch,
> linux_time_wheel_v7.patch, linux_time_wheel_v8.patch,
> linux_time_wheel_v9jp.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=13628638#comment-13628638 ] Bin Chen commented on TS-1405: -- http_load -parallel 100 -seconds 60 -keep_alive 100 /tmp/URL all /tmp/URL is hit or miss? how about hit ratio? > 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.2 > > Attachments: linux_time_wheel.patch, linux_time_wheel_v10jp.patch, > linux_time_wheel_v11jp.patch, linux_time_wheel_v2.patch, > linux_time_wheel_v3.patch, linux_time_wheel_v4.patch, > linux_time_wheel_v5.patch, linux_time_wheel_v6.patch, > linux_time_wheel_v7.patch, linux_time_wheel_v8.patch, > linux_time_wheel_v9jp.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=13626171#comment-13626171 ] Bin Chen commented on TS-1405: -- linux_time_wheel_v11jp.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.2 > > Attachments: linux_time_wheel.patch, linux_time_wheel_v10jp.patch, > linux_time_wheel_v11jp.patch, linux_time_wheel_v2.patch, > linux_time_wheel_v3.patch, linux_time_wheel_v4.patch, > linux_time_wheel_v5.patch, linux_time_wheel_v6.patch, > linux_time_wheel_v7.patch, linux_time_wheel_v8.patch, > linux_time_wheel_v9jp.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=13626145#comment-13626145 ] Bin Chen commented on TS-1405: -- test box: Cluster(cluster_type == 1) 10*Cache Server: CPU:Intel(R) Xeon(R) CPU L5630 @ 2.13GHz Ram:MemTotal: 49416984 kB Interface: Intel Corporation 82599EB 10-Gigabit SFI/SFP+ Network Total Throughput: > 8Gbps > 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.2 > > Attachments: linux_time_wheel.patch, linux_time_wheel_v10jp.patch, > linux_time_wheel_v11jp.patch, linux_time_wheel_v2.patch, > linux_time_wheel_v3.patch, linux_time_wheel_v4.patch, > linux_time_wheel_v5.patch, linux_time_wheel_v6.patch, > linux_time_wheel_v7.patch, linux_time_wheel_v8.patch, > linux_time_wheel_v9jp.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=13625411#comment-13625411 ] Bin Chen commented on TS-1405: -- Last patch have been running on our ten boxes five days. These boxes run about 5K qps. Maybe we can commit this patch after one week if no problem. How about? 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.2 > > Attachments: linux_time_wheel.patch, linux_time_wheel_v10jp.patch, > linux_time_wheel_v11jp.patch, linux_time_wheel_v2.patch, > linux_time_wheel_v3.patch, linux_time_wheel_v4.patch, > linux_time_wheel_v5.patch, linux_time_wheel_v6.patch, > linux_time_wheel_v7.patch, linux_time_wheel_v8.patch, > linux_time_wheel_v9jp.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=13620798#comment-13620798 ] Bin Chen commented on TS-1405: -- it's good idea freeing CANCEL_QUEUED event in EThread::process_cancelled_events(). Not free in process_event first. > 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.2 > > Attachments: linux_time_wheel.patch, linux_time_wheel_v10jp.patch, > linux_time_wheel_v11jp.patch, linux_time_wheel_v2.patch, > linux_time_wheel_v3.patch, linux_time_wheel_v4.patch, > linux_time_wheel_v5.patch, linux_time_wheel_v6.patch, > linux_time_wheel_v7.patch, linux_time_wheel_v8.patch, > linux_time_wheel_v9jp.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] [Assigned] (TS-1757) core at LogUtils::escapify_url()
[
https://issues.apache.org/jira/browse/TS-1757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bin Chen reassigned TS-1757:
Assignee: taorui
> core at LogUtils::escapify_url()
>
>
> Key: TS-1757
> URL: https://issues.apache.org/jira/browse/TS-1757
> Project: Traffic Server
> Issue Type: Bug
> Components: Logging
>Reporter: Bin Chen
>Assignee: taorui
> Fix For: 3.3.2
>
>
> {code}
> NOTE: Traffic Server received Sig 11: Segmentation fault
> /usr/bin/traffic_server - STACK TRACE:
> /lib64/libpthread.so.0[0x39ab20f4a0]
> /usr/bin/traffic_server(LogUtils::escapify_url(Arena*, char*, unsigned long,
> int*, char*, unsigned long, unsigned char const*)+0x60)[0x5b8550]
> /usr/bin/traffic_server(LogAccessHttp::init()+0xbc)[0x59864c]
> /usr/bin/traffic_server(Log::access(LogAccess*)+0x11e)[0x59b3ce]
> /usr/bin/traffic_server(HttpSM::update_stats()+0x630)[0x52be20]
> /usr/bin/traffic_server(HttpSM::kill_this()+0x928)[0x5374d8]
> /usr/bin/traffic_server(HttpSM::main_handler(int, void*)+0x198)[0x5377f8]
> /usr/bin/traffic_server[0x68727b]
> /usr/bin/traffic_server(UnixNetVConnection::mainEvent(int,
> Event*)+0x5df)[0x68989f]
> /usr/bin/traffic_server(InactivityCop::check_inactivity(int,
> Event*)+0xa6)[0x6839b6]
> /usr/bin/traffic_server(EThread::process_event(Event*, int)+0xb4)[0x6ac714]
> /usr/bin/traffic_server(PriorityEventQueue::check_ready(long,
> EThread*)+0x17b)[0x6aebab]
> /usr/bin/traffic_server(EThread::execute()+0x12c)[0x6acd0c]
> /usr/bin/traffic_server[0x6ab2b2]
> /lib64/libpthread.so.0[0x39ab2077f1]
> /lib64/libc.so.6(clone+0x6d)[0x39aaee570d]
> {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] [Closed] (TS-1797) when ts start, maybe some clusterHandlers is null. So we can scan all clusterHandlers in ClusterHandler *ClusterMachine::pop_ClusterHandler().
[ https://issues.apache.org/jira/browse/TS-1797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen closed TS-1797. Resolution: Fixed > when ts start, maybe some clusterHandlers is null. So we can scan all > clusterHandlers in ClusterHandler *ClusterMachine::pop_ClusterHandler(). > -- > > Key: TS-1797 > URL: https://issues.apache.org/jira/browse/TS-1797 > Project: Traffic Server > Issue Type: Improvement > Components: Clustering >Reporter: Bin Chen >Assignee: Bin Chen > Fix For: 3.3.2 > > Attachments: TS-1797.patch > > > when ts start, maybe some clusterHandlers is null. So we can scan > allclusterHandlers. Maybe one clusterHandler have created(connection is > establish) -- 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-1797) when ts start, maybe some clusterHandlers is null. So we can scan all clusterHandlers in ClusterHandler *ClusterMachine::pop_ClusterHandler().
[ https://issues.apache.org/jira/browse/TS-1797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen updated TS-1797: - Attachment: TS-1797.patch > when ts start, maybe some clusterHandlers is null. So we can scan all > clusterHandlers in ClusterHandler *ClusterMachine::pop_ClusterHandler(). > -- > > Key: TS-1797 > URL: https://issues.apache.org/jira/browse/TS-1797 > Project: Traffic Server > Issue Type: Improvement > Components: Clustering >Reporter: Bin Chen >Assignee: Bin Chen > Fix For: 3.3.2 > > Attachments: TS-1797.patch > > > when ts start, maybe some clusterHandlers is null. So we can scan > allclusterHandlers. Maybe one clusterHandler have created(connection is > establish) -- 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-1797) when ts start, maybe some clusterHandlers is null. So we can scan all clusterHandlers in ClusterHandler *ClusterMachine::pop_ClusterHandler.
[ https://issues.apache.org/jira/browse/TS-1797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen updated TS-1797: - Summary: when ts start, maybe some clusterHandlers is null. So we can scan all clusterHandlers in ClusterHandler *ClusterMachine::pop_ClusterHandler. (was: when ts start, maybe some clusterHandlers is null. So we can scan all clusterHandlers.) > when ts start, maybe some clusterHandlers is null. So we can scan all > clusterHandlers in ClusterHandler *ClusterMachine::pop_ClusterHandler. > > > Key: TS-1797 > URL: https://issues.apache.org/jira/browse/TS-1797 > Project: Traffic Server > Issue Type: Improvement > Components: Clustering >Reporter: Bin Chen >Assignee: Bin Chen > Fix For: 3.3.2 > > > when ts start, maybe some clusterHandlers is null. So we can scan > allclusterHandlers. Maybe one clusterHandler have created(connection is > establish) -- 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-1797) when ts start, maybe some clusterHandlers is null. So we can scan all clusterHandlers in ClusterHandler *ClusterMachine::pop_ClusterHandler().
[ https://issues.apache.org/jira/browse/TS-1797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen updated TS-1797: - Summary: when ts start, maybe some clusterHandlers is null. So we can scan all clusterHandlers in ClusterHandler *ClusterMachine::pop_ClusterHandler(). (was: when ts start, maybe some clusterHandlers is null. So we can scan all clusterHandlers in ClusterHandler *ClusterMachine::pop_ClusterHandler.) > when ts start, maybe some clusterHandlers is null. So we can scan all > clusterHandlers in ClusterHandler *ClusterMachine::pop_ClusterHandler(). > -- > > Key: TS-1797 > URL: https://issues.apache.org/jira/browse/TS-1797 > Project: Traffic Server > Issue Type: Improvement > Components: Clustering >Reporter: Bin Chen >Assignee: Bin Chen > Fix For: 3.3.2 > > > when ts start, maybe some clusterHandlers is null. So we can scan > allclusterHandlers. Maybe one clusterHandler have created(connection is > establish) -- 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-1797) when ts start, maybe some clusterHandlers is null. So we can scan all clusterHandlers.
[ https://issues.apache.org/jira/browse/TS-1797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen updated TS-1797: - Summary: when ts start, maybe some clusterHandlers is null. So we can scan all clusterHandlers. (was: when ts start, maybe some clusterHandlers is null. So we can scan allclusterHandlers.) > when ts start, maybe some clusterHandlers is null. So we can scan all > clusterHandlers. > -- > > Key: TS-1797 > URL: https://issues.apache.org/jira/browse/TS-1797 > Project: Traffic Server > Issue Type: Improvement > Components: Clustering >Reporter: Bin Chen >Assignee: Bin Chen > Fix For: 3.3.2 > > > when ts start, maybe some clusterHandlers is null. So we can scan > allclusterHandlers. Maybe one clusterHandler have created(connection is > establish) -- 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-1797) when ts start, maybe some clusterHandlers is null. So we can scan all clusterHandlers.
[ https://issues.apache.org/jira/browse/TS-1797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13619794#comment-13619794 ] Bin Chen commented on TS-1797: -- in ClusterHandler *ClusterMachine::pop_ClusterHandler. > when ts start, maybe some clusterHandlers is null. So we can scan all > clusterHandlers. > -- > > Key: TS-1797 > URL: https://issues.apache.org/jira/browse/TS-1797 > Project: Traffic Server > Issue Type: Improvement > Components: Clustering >Reporter: Bin Chen >Assignee: Bin Chen > Fix For: 3.3.2 > > > when ts start, maybe some clusterHandlers is null. So we can scan > allclusterHandlers. Maybe one clusterHandler have created(connection is > establish) -- 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-1797) when ts start, maybe some clusterHandlers is null. So we can scan allclusterHandlers.
Bin Chen created TS-1797: Summary: when ts start, maybe some clusterHandlers is null. So we can scan allclusterHandlers. Key: TS-1797 URL: https://issues.apache.org/jira/browse/TS-1797 Project: Traffic Server Issue Type: Improvement Components: Clustering Reporter: Bin Chen when ts start, maybe some clusterHandlers is null. So we can scan allclusterHandlers. Maybe one clusterHandler have created(connection is establish) -- 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-1797) when ts start, maybe some clusterHandlers is null. So we can scan allclusterHandlers.
[ https://issues.apache.org/jira/browse/TS-1797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen updated TS-1797: - Fix Version/s: 3.3.2 > when ts start, maybe some clusterHandlers is null. So we can scan > allclusterHandlers. > - > > Key: TS-1797 > URL: https://issues.apache.org/jira/browse/TS-1797 > Project: Traffic Server > Issue Type: Improvement > Components: Clustering >Reporter: Bin Chen >Assignee: Bin Chen > Fix For: 3.3.2 > > > when ts start, maybe some clusterHandlers is null. So we can scan > allclusterHandlers. Maybe one clusterHandler have created(connection is > establish) -- 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-1797) when ts start, maybe some clusterHandlers is null. So we can scan allclusterHandlers.
[ https://issues.apache.org/jira/browse/TS-1797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen reassigned TS-1797: Assignee: Bin Chen > when ts start, maybe some clusterHandlers is null. So we can scan > allclusterHandlers. > - > > Key: TS-1797 > URL: https://issues.apache.org/jira/browse/TS-1797 > Project: Traffic Server > Issue Type: Improvement > Components: Clustering >Reporter: Bin Chen >Assignee: Bin Chen > > when ts start, maybe some clusterHandlers is null. So we can scan > allclusterHandlers. Maybe one clusterHandler have created(connection is > establish) -- 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] [Closed] (TS-1751) when ts have high cpu usage, cluster thread isn't balance
[ https://issues.apache.org/jira/browse/TS-1751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen closed TS-1751. Resolution: Fixed > when ts have high cpu usage, cluster thread isn't balance > - > > Key: TS-1751 > URL: https://issues.apache.org/jira/browse/TS-1751 > Project: Traffic Server > Issue Type: Improvement > Components: Clustering >Reporter: Bin Chen >Assignee: Bin Chen > Fix For: 3.3.2 > > Attachments: TS-1751.patch, TS-1751_v2.patch, TS-1751_v3.patch > > > eg: > 3944 ats 20 0 33.1g 26g 7156 S 25.1 57.0 28:14.11 [ET_CLUSTER 4] > > > 3946 ats 20 0 33.1g 26g 7156 S 23.2 57.0 25:49.79 [ET_CLUSTER 6] > > > 3948 ats 20 0 33.1g 26g 7156 R 23.2 57.0 23:58.17 [ET_CLUSTER 8] > > > 3945 ats 20 0 33.1g 26g 7156 S 21.2 57.0 25:42.89 [ET_CLUSTER 5] > > > 3941 ats 20 0 33.1g 26g 7156 R 19.3 57.0 22:46.74 [ET_CLUSTER 1] > > > 3942 ats 20 0 33.1g 26g 7156 S 19.3 57.0 23:49.98 [ET_CLUSTER 2] > > > 3943 ats 20 0 33.1g 26g 7156 R 19.3 57.0 21:34.23 [ET_CLUSTER 3] > > > 3949 ats 20 0 33.1g 26g 7156 S 19.3 57.0 26:26.14 [ET_CLUSTER 9] > > > 3950 ats 20 0 33.1g 26g 7156 R 17.4 57.0 19:16.56 [ET_CLUSTER 10] > > > 3940 ats 20 0 33.1g 26g 7156 S 13.5 57.0 15:18.88 [ET_CLUSTER 0] > > > 3947 ats 20 0 33.1g 26g 7156 S 13.5 57.0 14:18.56 [ET_CLUSTER 7] > > > 3951 ats 20 0 33.1g 26g 7156 S 11.6 57.0 12:16.01 [ET_CLUSTER 11] > -- 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=13619536#comment-13619536 ] Bin Chen commented on TS-1405: -- yeah, i should read more carefully. But i can test this patch first. Thanks 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.2 > > Attachments: linux_time_wheel.patch, linux_time_wheel_v10jp.patch, > linux_time_wheel_v11jp.patch, linux_time_wheel_v2.patch, > linux_time_wheel_v3.patch, linux_time_wheel_v4.patch, > linux_time_wheel_v5.patch, linux_time_wheel_v6.patch, > linux_time_wheel_v7.patch, linux_time_wheel_v8.patch, > linux_time_wheel_v9jp.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-1751) when ts have high cpu usage, cluster thread isn't balance
[ https://issues.apache.org/jira/browse/TS-1751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen updated TS-1751: - Attachment: TS-1751_v3.patch when cluster connection assigned ok(origin assign by connection handle), don't bind clear and bind. > when ts have high cpu usage, cluster thread isn't balance > - > > Key: TS-1751 > URL: https://issues.apache.org/jira/browse/TS-1751 > Project: Traffic Server > Issue Type: Improvement > Components: Clustering >Reporter: Bin Chen >Assignee: Bin Chen > Fix For: 3.3.2 > > Attachments: TS-1751.patch, TS-1751_v2.patch, TS-1751_v3.patch > > > eg: > 3944 ats 20 0 33.1g 26g 7156 S 25.1 57.0 28:14.11 [ET_CLUSTER 4] > > > 3946 ats 20 0 33.1g 26g 7156 S 23.2 57.0 25:49.79 [ET_CLUSTER 6] > > > 3948 ats 20 0 33.1g 26g 7156 R 23.2 57.0 23:58.17 [ET_CLUSTER 8] > > > 3945 ats 20 0 33.1g 26g 7156 S 21.2 57.0 25:42.89 [ET_CLUSTER 5] > > > 3941 ats 20 0 33.1g 26g 7156 R 19.3 57.0 22:46.74 [ET_CLUSTER 1] > > > 3942 ats 20 0 33.1g 26g 7156 S 19.3 57.0 23:49.98 [ET_CLUSTER 2] > > > 3943 ats 20 0 33.1g 26g 7156 R 19.3 57.0 21:34.23 [ET_CLUSTER 3] > > > 3949 ats 20 0 33.1g 26g 7156 S 19.3 57.0 26:26.14 [ET_CLUSTER 9] > > > 3950 ats 20 0 33.1g 26g 7156 R 17.4 57.0 19:16.56 [ET_CLUSTER 10] > > > 3940 ats 20 0 33.1g 26g 7156 S 13.5 57.0 15:18.88 [ET_CLUSTER 0] > > > 3947 ats 20 0 33.1g 26g 7156 S 13.5 57.0 14:18.56 [ET_CLUSTER 7] > > > 3951 ats 20 0 33.1g 26g 7156 S 11.6 57.0 12:16.01 [ET_CLUSTER 11] > -- 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-1751) when ts have high cpu usage, cluster thread isn't balance
[ https://issues.apache.org/jira/browse/TS-1751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen updated TS-1751: - Fix Version/s: (was: 3.5.0) 3.3.2 > when ts have high cpu usage, cluster thread isn't balance > - > > Key: TS-1751 > URL: https://issues.apache.org/jira/browse/TS-1751 > Project: Traffic Server > Issue Type: Improvement > Components: Clustering >Reporter: Bin Chen >Assignee: Bin Chen > Fix For: 3.3.2 > > Attachments: TS-1751.patch, TS-1751_v2.patch > > > eg: > 3944 ats 20 0 33.1g 26g 7156 S 25.1 57.0 28:14.11 [ET_CLUSTER 4] > > > 3946 ats 20 0 33.1g 26g 7156 S 23.2 57.0 25:49.79 [ET_CLUSTER 6] > > > 3948 ats 20 0 33.1g 26g 7156 R 23.2 57.0 23:58.17 [ET_CLUSTER 8] > > > 3945 ats 20 0 33.1g 26g 7156 S 21.2 57.0 25:42.89 [ET_CLUSTER 5] > > > 3941 ats 20 0 33.1g 26g 7156 R 19.3 57.0 22:46.74 [ET_CLUSTER 1] > > > 3942 ats 20 0 33.1g 26g 7156 S 19.3 57.0 23:49.98 [ET_CLUSTER 2] > > > 3943 ats 20 0 33.1g 26g 7156 R 19.3 57.0 21:34.23 [ET_CLUSTER 3] > > > 3949 ats 20 0 33.1g 26g 7156 S 19.3 57.0 26:26.14 [ET_CLUSTER 9] > > > 3950 ats 20 0 33.1g 26g 7156 R 17.4 57.0 19:16.56 [ET_CLUSTER 10] > > > 3940 ats 20 0 33.1g 26g 7156 S 13.5 57.0 15:18.88 [ET_CLUSTER 0] > > > 3947 ats 20 0 33.1g 26g 7156 S 13.5 57.0 14:18.56 [ET_CLUSTER 7] > > > 3951 ats 20 0 33.1g 26g 7156 S 11.6 57.0 12:16.01 [ET_CLUSTER 11] > -- 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] [Closed] (TS-1796) remove cluster connection number change handler because of cluster connection number = (base on) cluster thread number
[ https://issues.apache.org/jira/browse/TS-1796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen closed TS-1796. Resolution: Fixed > remove cluster connection number change handler because of cluster connection > number = (base on) cluster thread number > -- > > Key: TS-1796 > URL: https://issues.apache.org/jira/browse/TS-1796 > Project: Traffic Server > Issue Type: Improvement > Components: Clustering >Reporter: Bin Chen >Assignee: Bin Chen > Fix For: 3.3.2 > > Attachments: TS-1796.patch > > -- 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-1796) remove cluster connection number change handler because of cluster connection number = (base on) cluster thread number
[ https://issues.apache.org/jira/browse/TS-1796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen updated TS-1796: - Attachment: TS-1796.patch > remove cluster connection number change handler because of cluster connection > number = (base on) cluster thread number > -- > > Key: TS-1796 > URL: https://issues.apache.org/jira/browse/TS-1796 > Project: Traffic Server > Issue Type: Improvement > Components: Clustering >Reporter: Bin Chen >Assignee: Bin Chen > Attachments: TS-1796.patch > > -- 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-1796) remove cluster connection number change handler because of cluster connection number = (base on) cluster thread number
[ https://issues.apache.org/jira/browse/TS-1796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen reassigned TS-1796: Assignee: Bin Chen > remove cluster connection number change handler because of cluster connection > number = (base on) cluster thread number > -- > > Key: TS-1796 > URL: https://issues.apache.org/jira/browse/TS-1796 > Project: Traffic Server > Issue Type: Improvement > Components: Clustering >Reporter: Bin Chen >Assignee: Bin Chen > -- 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-1796) remove cluster connection number change handler because of cluster connection number = (base on) cluster thread number
Bin Chen created TS-1796: Summary: remove cluster connection number change handler because of cluster connection number = (base on) cluster thread number Key: TS-1796 URL: https://issues.apache.org/jira/browse/TS-1796 Project: Traffic Server Issue Type: Improvement Components: Clustering Reporter: Bin Chen -- 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] [Closed] (TS-1793) force cluster connection = cluster number for cluster thread balance
[ https://issues.apache.org/jira/browse/TS-1793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen closed TS-1793. Resolution: Fixed > force cluster connection = cluster number for cluster thread balance > - > > Key: TS-1793 > URL: https://issues.apache.org/jira/browse/TS-1793 > Project: Traffic Server > Issue Type: Improvement > Components: Clustering >Reporter: Bin Chen >Assignee: Bin Chen > Attachments: TS-1793.patch > > > force cluster connection = cluster number for cluster thread balance. The > TS-1751 will base on this issue -- 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-1793) force cluster connection = cluster number for cluster thread balance
[ https://issues.apache.org/jira/browse/TS-1793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen updated TS-1793: - Attachment: TS-1793.patch > force cluster connection = cluster number for cluster thread balance > - > > Key: TS-1793 > URL: https://issues.apache.org/jira/browse/TS-1793 > Project: Traffic Server > Issue Type: Improvement > Components: Clustering >Reporter: Bin Chen >Assignee: Bin Chen > Attachments: TS-1793.patch > > > force cluster connection = cluster number for cluster thread balance. The > TS-1751 will base on this issue -- 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
