[jira] [Created] (TS-1562) traffic_manager crash
Bin Chen created TS-1562:
Summary: traffic_manager crash
Key: TS-1562
URL: https://issues.apache.org/jira/browse/TS-1562
Project: Traffic Server
Issue Type: Bug
Components: Management
Affects Versions: 3.2.0
Environment: LOCAL proxy.local.cluster.type INT 1
Reporter: Bin Chen
Assignee: Bin Chen
Fix For: 3.2.0
patch enable_seg.patch, core:
{code}
#0 0x7fb4e5b60da5 in textBuffer::copyFrom (this=0x7fb4c890fc30,
source=0x7fb4c8910400, num_bytes=0) at TextBuffer.cc:100
#1 0x0043eef7 in insert_locals (rec_cfg_new=0x7fb4c890fc30,
rec_cfg=0x7fb4c890fff0, local_ht=0x7fb4c890fc90) at ClusterCom.cc:1061
#2 0x0043f340 in ClusterCom::handleMultiCastFilePacket
(this=0x21b9d90,
last=0x7fb4dffef95f "health_check.config 2 0\nupdate.config 2
0\nhosting.config 2 0\nvaddrs.config 2 0\nicp.config 2 0\nlogs_xml.config 2
0\nplugin.config 3 0\nwpad.dat 2 0\nip_allow.config 2 0\nproxy.pac 2
0\ncongestion.config 2 0"..., ip=0x7fb4dffef390 "10.235.234.82") at
ClusterCom.cc:1154
#3 0x0043dbc9 in ClusterCom::handleMultiCastMessage (this=0x21b9d90,
message=0x7fb4dffef8b0 "ip: 10.235.234.82") at ClusterCom.cc:731
#4 0x0043c10c in drainIncomingChannel (arg=0x0) at ClusterCom.cc:149
#5 0x003aecc077f1 in start_thread () from /lib64/libpthread.so.0
#6 0x003aec8e570d in clone () from /lib64/libc.so.6
(gdb) f 0
#0 0x7fb4e5b60da5 in textBuffer::copyFrom (this=0x7fb4c890fc30,
source=0x7fb4c8910400, num_bytes=0) at TextBuffer.cc:100
/root/trafficserver-3.2.0/lib/ts/TextBuffer.cc:100:2445:beg:0x7fb4e5b60da5
(gdb) l
95
96memcpy(nextAdd, source, num_bytes);
97spaceLeft -= num_bytes;
98
99nextAdd += num_bytes;
100 nextAdd[0] = '\0';
101
102 return num_bytes;
103 }
104
(gdb) p nextAdd
$1 = 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] [Updated] (TS-1562) traffic_manager crash
[
https://issues.apache.org/jira/browse/TS-1562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bin Chen updated TS-1562:
-
Attachment: enable_seg.patch
this patch enable SIGSEGV default handler, then will create core file
> traffic_manager crash
> -
>
> Key: TS-1562
> URL: https://issues.apache.org/jira/browse/TS-1562
> Project: Traffic Server
> Issue Type: Bug
> Components: Management
>Affects Versions: 3.2.0
> Environment: LOCAL proxy.local.cluster.type INT 1
>Reporter: Bin Chen
>Assignee: Bin Chen
> Fix For: 3.2.0
>
> Attachments: enable_seg.patch
>
>
> patch enable_seg.patch, core:
> {code}
> #0 0x7fb4e5b60da5 in textBuffer::copyFrom (this=0x7fb4c890fc30,
> source=0x7fb4c8910400, num_bytes=0) at TextBuffer.cc:100
> #1 0x0043eef7 in insert_locals (rec_cfg_new=0x7fb4c890fc30,
> rec_cfg=0x7fb4c890fff0, local_ht=0x7fb4c890fc90) at ClusterCom.cc:1061
> #2 0x0043f340 in ClusterCom::handleMultiCastFilePacket
> (this=0x21b9d90,
> last=0x7fb4dffef95f "health_check.config 2 0\nupdate.config 2
> 0\nhosting.config 2 0\nvaddrs.config 2 0\nicp.config 2 0\nlogs_xml.config 2
> 0\nplugin.config 3 0\nwpad.dat 2 0\nip_allow.config 2 0\nproxy.pac 2
> 0\ncongestion.config 2 0"..., ip=0x7fb4dffef390 "10.235.234.82") at
> ClusterCom.cc:1154
> #3 0x0043dbc9 in ClusterCom::handleMultiCastMessage (this=0x21b9d90,
> message=0x7fb4dffef8b0 "ip: 10.235.234.82") at ClusterCom.cc:731
> #4 0x0043c10c in drainIncomingChannel (arg=0x0) at ClusterCom.cc:149
> #5 0x003aecc077f1 in start_thread () from /lib64/libpthread.so.0
> #6 0x003aec8e570d in clone () from /lib64/libc.so.6
> (gdb) f 0
> #0 0x7fb4e5b60da5 in textBuffer::copyFrom (this=0x7fb4c890fc30,
> source=0x7fb4c8910400, num_bytes=0) at TextBuffer.cc:100
> /root/trafficserver-3.2.0/lib/ts/TextBuffer.cc:100:2445:beg:0x7fb4e5b60da5
> (gdb) l
> 95
> 96 memcpy(nextAdd, source, num_bytes);
> 97 spaceLeft -= num_bytes;
> 98
> 99 nextAdd += num_bytes;
> 100 nextAdd[0] = '\0';
> 101
> 102 return num_bytes;
> 103 }
> 104
> (gdb) p nextAdd
> $1 = 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] [Updated] (TS-1562) traffic_manager crash
[
https://issues.apache.org/jira/browse/TS-1562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bin Chen updated TS-1562:
-
Attachment: TS-1562.patch
if reply is NULL(close by remote), break to process file update.
> traffic_manager crash
> -
>
> Key: TS-1562
> URL: https://issues.apache.org/jira/browse/TS-1562
> Project: Traffic Server
> Issue Type: Bug
> Components: Management
>Affects Versions: 3.2.0
> Environment: LOCAL proxy.local.cluster.type INT 1
>Reporter: Bin Chen
>Assignee: Bin Chen
> Fix For: 3.2.0
>
> Attachments: enable_seg.patch, TS-1562.patch
>
>
> patch enable_seg.patch, core:
> {code}
> #0 0x7fb4e5b60da5 in textBuffer::copyFrom (this=0x7fb4c890fc30,
> source=0x7fb4c8910400, num_bytes=0) at TextBuffer.cc:100
> #1 0x0043eef7 in insert_locals (rec_cfg_new=0x7fb4c890fc30,
> rec_cfg=0x7fb4c890fff0, local_ht=0x7fb4c890fc90) at ClusterCom.cc:1061
> #2 0x0043f340 in ClusterCom::handleMultiCastFilePacket
> (this=0x21b9d90,
> last=0x7fb4dffef95f "health_check.config 2 0\nupdate.config 2
> 0\nhosting.config 2 0\nvaddrs.config 2 0\nicp.config 2 0\nlogs_xml.config 2
> 0\nplugin.config 3 0\nwpad.dat 2 0\nip_allow.config 2 0\nproxy.pac 2
> 0\ncongestion.config 2 0"..., ip=0x7fb4dffef390 "10.235.234.82") at
> ClusterCom.cc:1154
> #3 0x0043dbc9 in ClusterCom::handleMultiCastMessage (this=0x21b9d90,
> message=0x7fb4dffef8b0 "ip: 10.235.234.82") at ClusterCom.cc:731
> #4 0x0043c10c in drainIncomingChannel (arg=0x0) at ClusterCom.cc:149
> #5 0x003aecc077f1 in start_thread () from /lib64/libpthread.so.0
> #6 0x003aec8e570d in clone () from /lib64/libc.so.6
> (gdb) f 0
> #0 0x7fb4e5b60da5 in textBuffer::copyFrom (this=0x7fb4c890fc30,
> source=0x7fb4c8910400, num_bytes=0) at TextBuffer.cc:100
> /root/trafficserver-3.2.0/lib/ts/TextBuffer.cc:100:2445:beg:0x7fb4e5b60da5
> (gdb) l
> 95
> 96 memcpy(nextAdd, source, num_bytes);
> 97 spaceLeft -= num_bytes;
> 98
> 99 nextAdd += num_bytes;
> 100 nextAdd[0] = '\0';
> 101
> 102 return num_bytes;
> 103 }
> 104
> (gdb) p nextAdd
> $1 = 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] [Commented] (TS-1492) if being net_connections_throttled, ts must to be restarted?(because of can't accept health checking request)
[ https://issues.apache.org/jira/browse/TS-1492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13494593#comment-13494593 ] Bin Chen commented on TS-1492: -- if we should restart traffic_server, set stat records=1. And if ts restored, then we must set stat records=0. But maybe have more case(throttling, cache error), one is setting, and other is restoring, how to set stat records? so maybe we can't use only one stat records. > if being net_connections_throttled, ts must to be restarted?(because of > can't accept health checking request) > -- > > Key: TS-1492 > URL: https://issues.apache.org/jira/browse/TS-1492 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Affects Versions: 3.2.0 >Reporter: Bin Chen >Assignee: Bin Chen >Priority: Critical > Fix For: 3.3.1 > > Attachments: backdoor_not_throttling.patch > > > In our env, ts will be throttled because of many request incomming > simultaneously(because of frontend haproxy is restarted). But we don't expect > ts be restarted because of this case. we can handled this: > 1、if throttled, ts's health check request always be handled > 2、many many connection request may be handled in long time -- 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-1492) if being net_connections_throttled, ts must to be restarted?(because of can't accept health checking request)
[ https://issues.apache.org/jira/browse/TS-1492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13494596#comment-13494596 ] Bin Chen commented on TS-1492: -- the other solution, we can use one stat records to flagging one case(throttling, cache not enable), and traffic manager collect to handler(check every case) traffic_server restart. > if being net_connections_throttled, ts must to be restarted?(because of > can't accept health checking request) > -- > > Key: TS-1492 > URL: https://issues.apache.org/jira/browse/TS-1492 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Affects Versions: 3.2.0 >Reporter: Bin Chen >Assignee: Bin Chen >Priority: Critical > Fix For: 3.3.1 > > Attachments: backdoor_not_throttling.patch > > > In our env, ts will be throttled because of many request incomming > simultaneously(because of frontend haproxy is restarted). But we don't expect > ts be restarted because of this case. we can handled this: > 1、if throttled, ts's health check request always be handled > 2、many many connection request may be handled in long time -- 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-1504) stats should not get a negative value
[
https://issues.apache.org/jira/browse/TS-1504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bin Chen reassigned TS-1504:
Assignee: taorui (was: Bin Chen)
> stats should not get a negative value
> -
>
> Key: TS-1504
> URL: https://issues.apache.org/jira/browse/TS-1504
> Project: Traffic Server
> Issue Type: Bug
> Components: Stats
>Affects Versions: 3.3.0
>Reporter: Zhao Yongming
>Assignee: taorui
> Fix For: 3.3.2
>
>
> {code}
> proxy.process.http.transaction_totaltime.hit_fresh.process=-8090340352.00
> proxy.process.cluster.open_delays=-1568985805836593376
> proxy.process.cluster.connections_avg_time=-76.100204
> proxy.process.cluster.control_messages_avg_send_time=-92.242027
> proxy.process.cluster.open_delay_time=-1147.221313
> proxy.process.cluster.rmt_cache_callback_time=-214.001053
> proxy.process.cluster.remote_connection_time=-259.256744
> {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-1578) connection manage
Bin Chen created TS-1578: Summary: connection manage Key: TS-1578 URL: https://issues.apache.org/jira/browse/TS-1578 Project: Traffic Server Issue Type: Improvement Components: Network Affects Versions: 3.2.0 Reporter: Bin Chen Assignee: Bin Chen ts must handle some connection cases: 1、receiving large concurrent connections suddenly 2、have slow original server(incomming producer greater than consumer), so will be throttling. if throttling, ts will restart. Replacing throttling to max_accept limmiting maybe more friendly? 3、different domain have different origin_max_connections? 4、how to handle health check if use max_accept? -- 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-1579) register_ShowNet calling is high load
Bin Chen created TS-1579:
Summary: register_ShowNet calling is high load
Key: TS-1579
URL: https://issues.apache.org/jira/browse/TS-1579
Project: Traffic Server
Issue Type: Bug
Components: Stats
Affects Versions: 3.2.0
Reporter: Bin Chen
Assignee: Bin Chen
a box running ts:
{code}
run perf top
samples pcnt function
DSO
___ _
_ __
1270.00 7.8% register_ShowNet(Continuation*, HTTPHdr*)
traffic_server
860.00 5.3% copy_user_generic_string
[kernel.kallsyms]
743.00 4.6% ixgbe_notify_dca
[ixgbe]
425.00 2.6% ink_freelist_new
libtsutil.so.3.2.0
260.00 1.6% kmem_cache_free
[kernel.kallsyms]
248.00 1.5% tcp_ack
[kernel.kallsyms]
246.00 1.5% kfree
[kernel.kallsyms]
232.00 1.4% intel_idle
[kernel.kallsyms]
228.00 1.4% __memcpy_ssse3_back
libc-2.12.so
219.00 1.4% PriorityEventQueue::enqueue(Event*, long)
traffic_server
181.00 1.1% _spin_lock
[kernel.kallsyms]
176.00 1.1% ink_freelist_free
libtsutil.so.3.2.0
158.00 1.0% ip_route_input
[kernel.kallsyms]
135.00 0.8% __inet_lookup_established
[kernel.kallsyms]
126.00 0.8% register_stat_callbacks()
traffic_server
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1562) traffic_manager crash
[
https://issues.apache.org/jira/browse/TS-1562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13503366#comment-13503366
]
Bin Chen commented on TS-1562:
--
commit: 5e55f601e3ac5ff581d371ccd588f4ddafa967b2
> traffic_manager crash
> -
>
> Key: TS-1562
> URL: https://issues.apache.org/jira/browse/TS-1562
> Project: Traffic Server
> Issue Type: Bug
> Components: Management
>Affects Versions: 3.2.0
> Environment: LOCAL proxy.local.cluster.type INT 1
>Reporter: Bin Chen
>Assignee: Bin Chen
> Fix For: 3.2.0
>
> Attachments: enable_seg.patch, TS-1562.patch
>
>
> patch enable_seg.patch, core:
> {code}
> #0 0x7fb4e5b60da5 in textBuffer::copyFrom (this=0x7fb4c890fc30,
> source=0x7fb4c8910400, num_bytes=0) at TextBuffer.cc:100
> #1 0x0043eef7 in insert_locals (rec_cfg_new=0x7fb4c890fc30,
> rec_cfg=0x7fb4c890fff0, local_ht=0x7fb4c890fc90) at ClusterCom.cc:1061
> #2 0x0043f340 in ClusterCom::handleMultiCastFilePacket
> (this=0x21b9d90,
> last=0x7fb4dffef95f "health_check.config 2 0\nupdate.config 2
> 0\nhosting.config 2 0\nvaddrs.config 2 0\nicp.config 2 0\nlogs_xml.config 2
> 0\nplugin.config 3 0\nwpad.dat 2 0\nip_allow.config 2 0\nproxy.pac 2
> 0\ncongestion.config 2 0"..., ip=0x7fb4dffef390 "10.235.234.82") at
> ClusterCom.cc:1154
> #3 0x0043dbc9 in ClusterCom::handleMultiCastMessage (this=0x21b9d90,
> message=0x7fb4dffef8b0 "ip: 10.235.234.82") at ClusterCom.cc:731
> #4 0x0043c10c in drainIncomingChannel (arg=0x0) at ClusterCom.cc:149
> #5 0x003aecc077f1 in start_thread () from /lib64/libpthread.so.0
> #6 0x003aec8e570d in clone () from /lib64/libc.so.6
> (gdb) f 0
> #0 0x7fb4e5b60da5 in textBuffer::copyFrom (this=0x7fb4c890fc30,
> source=0x7fb4c8910400, num_bytes=0) at TextBuffer.cc:100
> /root/trafficserver-3.2.0/lib/ts/TextBuffer.cc:100:2445:beg:0x7fb4e5b60da5
> (gdb) l
> 95
> 96 memcpy(nextAdd, source, num_bytes);
> 97 spaceLeft -= num_bytes;
> 98
> 99 nextAdd += num_bytes;
> 100 nextAdd[0] = '\0';
> 101
> 102 return num_bytes;
> 103 }
> 104
> (gdb) p nextAdd
> $1 = 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] [Commented] (TS-1562) traffic_manager crash
[
https://issues.apache.org/jira/browse/TS-1562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13503369#comment-13503369
]
Bin Chen commented on TS-1562:
--
commit: master
> traffic_manager crash
> -
>
> Key: TS-1562
> URL: https://issues.apache.org/jira/browse/TS-1562
> Project: Traffic Server
> Issue Type: Bug
> Components: Management
>Affects Versions: 3.2.0
> Environment: LOCAL proxy.local.cluster.type INT 1
>Reporter: Bin Chen
>Assignee: Bin Chen
> Fix For: 3.2.0
>
> Attachments: enable_seg.patch, TS-1562.patch
>
>
> patch enable_seg.patch, core:
> {code}
> #0 0x7fb4e5b60da5 in textBuffer::copyFrom (this=0x7fb4c890fc30,
> source=0x7fb4c8910400, num_bytes=0) at TextBuffer.cc:100
> #1 0x0043eef7 in insert_locals (rec_cfg_new=0x7fb4c890fc30,
> rec_cfg=0x7fb4c890fff0, local_ht=0x7fb4c890fc90) at ClusterCom.cc:1061
> #2 0x0043f340 in ClusterCom::handleMultiCastFilePacket
> (this=0x21b9d90,
> last=0x7fb4dffef95f "health_check.config 2 0\nupdate.config 2
> 0\nhosting.config 2 0\nvaddrs.config 2 0\nicp.config 2 0\nlogs_xml.config 2
> 0\nplugin.config 3 0\nwpad.dat 2 0\nip_allow.config 2 0\nproxy.pac 2
> 0\ncongestion.config 2 0"..., ip=0x7fb4dffef390 "10.235.234.82") at
> ClusterCom.cc:1154
> #3 0x0043dbc9 in ClusterCom::handleMultiCastMessage (this=0x21b9d90,
> message=0x7fb4dffef8b0 "ip: 10.235.234.82") at ClusterCom.cc:731
> #4 0x0043c10c in drainIncomingChannel (arg=0x0) at ClusterCom.cc:149
> #5 0x003aecc077f1 in start_thread () from /lib64/libpthread.so.0
> #6 0x003aec8e570d in clone () from /lib64/libc.so.6
> (gdb) f 0
> #0 0x7fb4e5b60da5 in textBuffer::copyFrom (this=0x7fb4c890fc30,
> source=0x7fb4c8910400, num_bytes=0) at TextBuffer.cc:100
> /root/trafficserver-3.2.0/lib/ts/TextBuffer.cc:100:2445:beg:0x7fb4e5b60da5
> (gdb) l
> 95
> 96 memcpy(nextAdd, source, num_bytes);
> 97 spaceLeft -= num_bytes;
> 98
> 99 nextAdd += num_bytes;
> 100 nextAdd[0] = '\0';
> 101
> 102 return num_bytes;
> 103 }
> 104
> (gdb) p nextAdd
> $1 = 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] [Created] (TS-1592) crash at HttpCompat::parse_tok_list
Bin Chen created TS-1592:
Summary: crash at HttpCompat::parse_tok_list
Key: TS-1592
URL: https://issues.apache.org/jira/browse/TS-1592
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Affects Versions: 3.2.0
Environment: full_cluster
Reporter: Bin Chen
{code}
Program terminated with signal 11, Segmentation fault.
#0 HttpCompat::parse_tok_list (list=0x2b3d7aca86f0, trim_quotes=, string=,
len=, sep=59 ';') at HttpCompat.cc:77
/usr/src/debug/trafficserver-3.2.0/proxy/hdrs/HttpCompat.cc:77:2565:beg:0x5a7990
Missing separate debuginfos, use: debuginfo-install expat-2.0.1-9.1.el6.x86_64
glibc-2.12-1.47.el6.x86_64 keyutils-libs-1.4-3.el6.x86_64
krb5-libs-1.9-22.el6.x86_64 libcom_err-1.41.12-11.el6.x86_64
libgcc-4.4.6-3.el6.x86_64 libselinux-2.0.94-5.2.el6.x86_64
libstdc++-4.4.6-3.el6.x86_64 ncurses-libs-5.7-3.20090208.el6.x86_64
openssl-1.0.0-20.el6.x86_64 pcre-7.8-3.1.el6.x86_64 readline-6.0-3.el6.x86_64
tcl-8.5.7-6.el6.x86_64 xz-libs-4.999.9-0.3.beta.20091007git.el6.x86_64
zlib-1.2.3-27.el6.x86_64
(gdb) bt
#0 HttpCompat::parse_tok_list (list=0x2b3d7aca86f0, trim_quotes=, string=,
len=, sep=59 ';') at HttpCompat.cc:77
#1 0x0052e4fc in parse_semicolon_list (accept_field=0x2b3da50ab118,
content_field=)
at ../../proxy/hdrs/HttpCompat.h:92
#2 HttpTransactCache::calculate_quality_of_accept_match
(accept_field=0x2b3da50ab118, content_field=)
at HttpTransactCache.cc:519
#3 0x00530cf6 in HttpTransactCache::calculate_quality_of_match
(http_config_param=0x2b3da6a074a0,
client_request=0x2b3d94749ba0, obj_client_request=0x2b3f4748d5c0,
obj_origin_server_response=0x2b3f4748d600)
at HttpTransactCache.cc:327
#4 0x00531a7d in HttpTransactCache::SelectFromAlternates
(cache_vector=0x2b3d94749be0,
client_request=0x2b3d94749ba0, http_config_params=0x2b3da6a074a0) at
HttpTransactCache.cc:214
#5 0x006245e5 in CacheVC::openReadStartHead (this=0x2b3d94749ae0,
event=3900, e=0x0) at CacheRead.cc:1019
#6 0x00604348 in handleEvent (this=0x2b3d94749ae0, event=, e=)
at ../../iocore/eventsystem/I_Continuation.h:146
#7 CacheVC::handleReadDone (this=0x2b3d94749ae0, event=,
e=) at Cache.cc:1952
#8 0x00608035 in handleEvent (this=, event=, data=)
at ../../iocore/eventsystem/I_Continuation.h:146
#9 AIOCallbackInternal::io_complete (this=, event=, data=)
at ../../iocore/aio/P_AIO.h:80
#10 0x0066ae94 in handleEvent (this=0x2b3d7a42b010, e=0x213ec10,
calling_code=1) at I_Continuation.h:146
#11 EThread::process_event (this=0x2b3d7a42b010, e=0x213ec10, calling_code=1)
at UnixEThread.cc:189
#12 0x0066b773 in EThread::execute (this=0x2b3d7a42b010) at
UnixEThread.cc:240
#13 0x00669c72 in spawn_thread_internal (a=0x1785910) at Thread.cc:88
#14 0x0034bfc077f1 in start_thread () from /lib64/libpthread.so.0
#15 0x0034bf8e570d in clone () from /lib64/libc.so.6
{code}
--
This message 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-1592) crash at HttpCompat::parse_tok_list
[
https://issues.apache.org/jira/browse/TS-1592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bin Chen reassigned TS-1592:
Assignee: Bin Chen
> crash at HttpCompat::parse_tok_list
> ---
>
> Key: TS-1592
> URL: https://issues.apache.org/jira/browse/TS-1592
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
>Affects Versions: 3.2.0
> Environment: full_cluster
>Reporter: Bin Chen
>Assignee: Bin Chen
>
> {code}
> Program terminated with signal 11, Segmentation fault.
> #0 HttpCompat::parse_tok_list (list=0x2b3d7aca86f0, trim_quotes= optimized out>, string=,
> len=, sep=59 ';') at HttpCompat.cc:77
> /usr/src/debug/trafficserver-3.2.0/proxy/hdrs/HttpCompat.cc:77:2565:beg:0x5a7990
> Missing separate debuginfos, use: debuginfo-install
> expat-2.0.1-9.1.el6.x86_64 glibc-2.12-1.47.el6.x86_64
> keyutils-libs-1.4-3.el6.x86_64 krb5-libs-1.9-22.el6.x86_64
> libcom_err-1.41.12-11.el6.x86_64 libgcc-4.4.6-3.el6.x86_64
> libselinux-2.0.94-5.2.el6.x86_64 libstdc++-4.4.6-3.el6.x86_64
> ncurses-libs-5.7-3.20090208.el6.x86_64 openssl-1.0.0-20.el6.x86_64
> pcre-7.8-3.1.el6.x86_64 readline-6.0-3.el6.x86_64 tcl-8.5.7-6.el6.x86_64
> xz-libs-4.999.9-0.3.beta.20091007git.el6.x86_64 zlib-1.2.3-27.el6.x86_64
> (gdb) bt
> #0 HttpCompat::parse_tok_list (list=0x2b3d7aca86f0, trim_quotes= optimized out>, string=,
> len=, sep=59 ';') at HttpCompat.cc:77
> #1 0x0052e4fc in parse_semicolon_list (accept_field=0x2b3da50ab118,
> content_field=)
> at ../../proxy/hdrs/HttpCompat.h:92
> #2 HttpTransactCache::calculate_quality_of_accept_match
> (accept_field=0x2b3da50ab118, content_field=)
> at HttpTransactCache.cc:519
> #3 0x00530cf6 in HttpTransactCache::calculate_quality_of_match
> (http_config_param=0x2b3da6a074a0,
> client_request=0x2b3d94749ba0, obj_client_request=0x2b3f4748d5c0,
> obj_origin_server_response=0x2b3f4748d600)
> at HttpTransactCache.cc:327
> #4 0x00531a7d in HttpTransactCache::SelectFromAlternates
> (cache_vector=0x2b3d94749be0,
> client_request=0x2b3d94749ba0, http_config_params=0x2b3da6a074a0) at
> HttpTransactCache.cc:214
> #5 0x006245e5 in CacheVC::openReadStartHead (this=0x2b3d94749ae0,
> event=3900, e=0x0) at CacheRead.cc:1019
> #6 0x00604348 in handleEvent (this=0x2b3d94749ae0, event= optimized out>, e=)
> at ../../iocore/eventsystem/I_Continuation.h:146
> #7 CacheVC::handleReadDone (this=0x2b3d94749ae0, event= out>, e=) at Cache.cc:1952
> #8 0x00608035 in handleEvent (this=,
> event=, data=)
> at ../../iocore/eventsystem/I_Continuation.h:146
> #9 AIOCallbackInternal::io_complete (this=,
> event=, data=)
> at ../../iocore/aio/P_AIO.h:80
> #10 0x0066ae94 in handleEvent (this=0x2b3d7a42b010, e=0x213ec10,
> calling_code=1) at I_Continuation.h:146
> #11 EThread::process_event (this=0x2b3d7a42b010, e=0x213ec10, calling_code=1)
> at UnixEThread.cc:189
> #12 0x0066b773 in EThread::execute (this=0x2b3d7a42b010) at
> UnixEThread.cc:240
> #13 0x00669c72 in spawn_thread_internal (a=0x1785910) at Thread.cc:88
> #14 0x0034bfc077f1 in start_thread () from /lib64/libpthread.so.0
> #15 0x0034bf8e570d in clone () from /lib64/libc.so.6
> {code}
--
This message 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-1595) different domain have different origin_max_connections?
Bin Chen created TS-1595: Summary: different domain have different origin_max_connections? Key: TS-1595 URL: https://issues.apache.org/jira/browse/TS-1595 Project: Traffic Server Issue Type: Bug Components: Network Reporter: Bin Chen Assignee: Bin Chen Priority: Minor 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-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 updated TS-1595: - Issue Type: Sub-task (was: Bug) Parent: TS-1578 > 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 > > 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] [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=13504383#comment-13504383 ] Bin Chen commented on TS-1595: -- For example: in record.config: CONFIG proxy.config.http.origin_max_connections INT 1000 in remap.config: map http://foo.cow.com/ http://bar.cow.com @proxy.config.http.origin_max_connections=100 then bar.cow.com will use proxy.config.http.origin_max_connections=100 replacing proxy.config.http.origin_max_connections INT 1000 and the other will proxy.config.http.origin_max_connections INT 1000 > 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 > > 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] [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=13504403#comment-13504403 ] Bin Chen commented on TS-1595: -- how about performance? > 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 > > 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] [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=13505081#comment-13505081 ] Bin Chen commented on TS-1595: -- TS-1595 is only one requirement. I think ts should have unified UI (Overridable config, more flexable ACL support, more friendly plugin param about every remap rule, cache-control &). So user only take care of the unidfied UI in remap.config. > 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 > > 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] [Created] (TS-1600) when one http transaction complete, should HttpClientSession release serversession
Bin Chen created TS-1600: Summary: when one http transaction complete, should HttpClientSession release serversession Key: TS-1600 URL: https://issues.apache.org/jira/browse/TS-1600 Project: Traffic Server Issue Type: Improvement Components: HTTP Affects Versions: 3.2.0 Reporter: Bin Chen Assignee: Bin Chen Priority: Minor when one http transaction complete, HttpClientSession store last serversession in bound_ss. In high hit ratio, ts may use more serversession using less lock(server session pool). But in high pressure env, ts will use more serversession. Maybe we should use less serversession(origin connection limitted) by release bound_ss to serversession pool in transaction complete(HttpClientSession::release()) -- 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-1601) HttpServerSession::release don't close ServerSession if ServerSessionPool locking contention
Bin Chen created TS-1601: Summary: HttpServerSession::release don't close ServerSession if ServerSessionPool locking contention Key: TS-1601 URL: https://issues.apache.org/jira/browse/TS-1601 Project: Traffic Server Issue Type: Improvement Components: Network Affects Versions: 3.2.0 Reporter: Bin Chen Assignee: Bin Chen Priority: Minor -- 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-1602) crash at http_hdr_type_get
Bin Chen created TS-1602:
Summary: crash at http_hdr_type_get
Key: TS-1602
URL: https://issues.apache.org/jira/browse/TS-1602
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Affects Versions: 3.2.0
Reporter: Bin Chen
Assignee: Bin Chen
{code}
Program terminated with signal 11, Segmentation fault.
#0 0x005034b0 in http_hdr_type_get (hh=0x2abf98de9898) at
hdrs/HTTP.h:957
/usr/src/debug/trafficserver-3.2.0/proxy/hdrs/HTTP.h:957:28250:beg:0x5034b0
Missing separate debuginfos, use: debuginfo-install expat-2.0.1-9.1.el6.x86_64
glibc-2.12-1.47.el6.x86_64 keyutils-libs-1.4-3.el6.x86_64
krb5-libs-1.9-22.el6.x86_64 libcom_err-1.41.12-11.el6.x86_64
libgcc-4.4.6-3.el6.x86_64 libselinux-2.0.94-5.2.el6.x86_64
libstdc++-4.4.6-3.el6.x86_64 ncurses-libs-5.7-3.20090208.el6.x86_64
openssl-1.0.0-20.el6.x86_64 pcre-7.8-3.1.el6.x86_64 readline-6.0-3.el6.x86_64
tcl-8.5.7-6.el6.x86_64 xz-libs-4.999.9-0.3.beta.20091007git.el6.x86_64
zlib-1.2.3-27.el6.x86_64
(gdb) bt
#0 0x005034b0 in http_hdr_type_get (hh=0x2abf98de9898) at
hdrs/HTTP.h:957
#1 0x005034d2 in HTTPHdr::type_get (this=0x2ba4d149f088) at
hdrs/HTTP.h:967
#2 0x0058e6f4 in HttpTransact::HandleCacheOpenRead (s=0x2ba51d5d2838)
at HttpTransact.cc:2046
#3 0x0057af93 in HttpSM::call_transact_and_set_next_state
(this=0x2ba51d5d27d0,
f=0x58e5cc ) at
HttpSM.cc:6425
#4 0x0056e576 in HttpSM::state_cache_open_read (this=0x2ba51d5d27d0,
event=1102, data=0x2ba3f8d00c10)
at HttpSM.cc:2406
#5 0x0056e968 in HttpSM::main_handler (this=0x2ba51d5d27d0,
event=1102, data=0x2ba3f8d00c10) at HttpSM.cc:2465
#6 0x004e6fae in Continuation::handleEvent (this=0x2ba51d5d27d0,
event=1102, data=0x2ba3f8d00c10)
at ../iocore/eventsystem/I_Continuation.h:146
#7 0x00556f02 in HttpCacheSM::state_cache_open_read
(this=0x2ba51d5d4898, event=1102, data=0x2ba3f8d00c10)
at HttpCacheSM.cc:118
#8 0x004e6fae in Continuation::handleEvent (this=0x2ba51d5d4898,
event=1102, data=0x2ba3f8d00c10)
at ../iocore/eventsystem/I_Continuation.h:146
#9 0x00649779 in CacheContinuation::callback_user
(this=0x2ba410a95560, res=1102, e=0x2ba3f8d00c10)
at ClusterCache.cc:2813
#10 0x00648433 in CacheContinuation::remoteOpEvent
(this=0x2ba410a95560, event_code=1151, e=0x2ba4d149f000)
at ClusterCache.cc:2345
#11 0x004e6fae in Continuation::handleEvent (this=0x2ba410a95560,
event=1151, data=0x2ba4d149f000)
at ../iocore/eventsystem/I_Continuation.h:146
#12 0x0064751c in cache_op_result_ClusterFunction (ch=0x2ba428881140,
d=0x2ba570cd4018, l=2776)
at ClusterCache.cc:2088
#13 0x00651747 in ClusterHandler::process_incoming_callouts
(this=0x2ba428881140, m=0x2ba3f92a3c50)
at ClusterHandler.cc:1237
#14 0x006598db in ClusterCalloutContinuation::CalloutHandler
(this=0x2ba4284057c0, event=2, e=0x2ba314b48ef0)
at ClusterHandlerBase.cc:62
#15 0x004e6fae in Continuation::handleEvent (this=0x2ba4284057c0,
event=2, data=0x2ba314b48ef0)
at ../iocore/eventsystem/I_Continuation.h:146
#16 0x006d99b8 in EThread::process_event (this=0x2ba2cf72e010,
e=0x2ba314b48ef0, calling_code=2)
at UnixEThread.cc:189
#17 0x006dbd79 in PriorityEventQueue::check_ready (this=0x2ba2cf82ec40,
now=135396960399086, t=0x2ba2cf72e010)
at PQ-List.cc:141
#18 0x006d9c8a in EThread::execute (this=0x2ba2cf72e010) at
UnixEThread.cc:258
#19 0x006d89e7 in spawn_thread_internal (a=0x15c19a0) at Thread.cc:88
#20 0x003c088077f1 in start_thread () from /lib64/libpthread.so.0
#21 0x003c084e570d in clone () from /lib64/libc.so.6
(gdb) f 0
#0 0x005034b0 in http_hdr_type_get (hh=0x2abf98de9898) at
hdrs/HTTP.h:957
/usr/src/debug/trafficserver-3.2.0/proxy/hdrs/HTTP.h:957:28250:beg:0x5034b0
(gdb) l
952
-*/
953
954 inline HTTPType
955 http_hdr_type_get(HTTPHdrImpl *hh)
956 {
957 return (hh->m_polarity);
958 }
959
960
/*-
961
-*/
(gdb) p hh->m_polarity
Cannot access memory at address 0x2abf98de989c
(gdb) p *hh
Cannot access memory at address 0x2abf98de9898
{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-1603) crash at ClusterHandler::mainClusterEvent
Bin Chen created TS-1603:
Summary: crash at ClusterHandler::mainClusterEvent
Key: TS-1603
URL: https://issues.apache.org/jira/browse/TS-1603
Project: Traffic Server
Issue Type: Bug
Components: Clustering
Affects Versions: 3.2.0
Reporter: Bin Chen
Assignee: Bin Chen
{code}
#0 0x006556c4 in ClusterHandler::mainClusterEvent
(this=0x2ab444c1e4e0, event=2, e=0x0) at ClusterHandler.cc:2469
/usr/src/debug/trafficserver-3.2.0/iocore/cluster/ClusterHandler.cc:2469:81142:beg:0x6556c4
Missing separate debuginfos, use: debuginfo-install expat-2.0.1-9.1.el6.x86_64
glibc-2.12-1.47.el6.x86_64 keyutils-libs-1.4-3.el6.x86_64
krb5-libs-1.9-22.el6.x86_64 libcom_err-1.41.12-11.el6.x86_64
libgcc-4.4.6-3.el6.x86_64 libselinux-2.0.94-5.2.el6.x86_64
libstdc++-4.4.6-3.el6.x86_64 ncurses-libs-5.7-3.20090208.el6.x86_64
openssl-1.0.0-20.el6.x86_64 pcre-7.8-3.1.el6.x86_64 readline-6.0-3.el6.x86_64
tcl-8.5.7-6.el6.x86_64 xz-libs-4.999.9-0.3.beta.20091007git.el6.x86_64
zlib-1.2.3-27.el6.x86_64
(gdb) bt
#0 0x006556c4 in ClusterHandler::mainClusterEvent
(this=0x2ab444c1e4e0, event=2, e=0x0) at ClusterHandler.cc:2469
#1 0x0065d6a3 in ClusterHandler::protoZombieEvent
(this=0x2ab444c1e4e0, event=1, e=0x0)
at ClusterHandlerBase.cc:1219
#2 0x004e6fae in Continuation::handleEvent (this=0x2ab444c1e4e0,
event=1, data=0x0)
at ../iocore/eventsystem/I_Continuation.h:146
#3 0x0065b081 in ClusterState::IOComplete (this=0x2ab444c1e840) at
ClusterHandlerBase.cc:584
#4 0x0065ae1a in ClusterState::doIO_read_event (this=0x2ab444c1e840,
event=104, d=0x2ab3613601d8)
at ClusterHandlerBase.cc:496
#5 0x004e6fae in Continuation::handleEvent (this=0x2ab444c1e840,
event=104, data=0x2ab3613601d8)
at ../iocore/eventsystem/I_Continuation.h:146
#6 0x006b806c in read_signal_and_update (event=104, vc=0x2ab3613600d0)
at UnixNetVConnection.cc:129
#7 0x006b81bd in read_signal_done (event=104, nh=0x2ab35f1211e8,
vc=0x2ab3613600d0) at UnixNetVConnection.cc:159
#8 0x006b8707 in read_from_net (nh=0x2ab35f1211e8, vc=0x2ab3613600d0,
thread=0x2ab35f11e010)
at UnixNetVConnection.cc:282
#9 0x006ba351 in UnixNetVConnection::net_read_io (this=0x2ab3613600d0,
nh=0x2ab35f1211e8, lthread=0x2ab35f11e010)
at UnixNetVConnection.cc:802
#10 0x006b5064 in NetHandler::mainNetEvent (this=0x2ab35f1211e8,
event=5, e=0x2ab33c536dd0) at UnixNet.cc:337
#11 0x004e6fae in Continuation::handleEvent (this=0x2ab35f1211e8,
event=5, data=0x2ab33c536dd0)
at ../iocore/eventsystem/I_Continuation.h:146
#12 0x006d99b8 in EThread::process_event (this=0x2ab35f11e010,
e=0x2ab33c536dd0, calling_code=5)
at UnixEThread.cc:189
#13 0x006d9e55 in EThread::execute (this=0x2ab35f11e010) at
UnixEThread.cc:301
#14 0x006d89e7 in spawn_thread_internal (a=0x2ab344334f20) at
Thread.cc:88
#15 0x0037a14077f1 in start_thread () from /lib64/libpthread.so.0
#16 0x0037a10e570d in clone () from /lib64/libc.so.6
(gdb) f 0
#0 0x006556c4 in ClusterHandler::mainClusterEvent
(this=0x2ab444c1e4e0, event=2, e=0x0) at ClusterHandler.cc:2469
/usr/src/debug/trafficserver-3.2.0/iocore/cluster/ClusterHandler.cc:2469:81142:beg:0x6556c4
(gdb) l
2464thread = (EThread *) e;
2465 } else {
2466if (io_callback) {
2467 thread = this_ethread();
2468} else {
2469 thread = e->ethread;
2470}
2471 }
2472
2473 int io_activity = 1;
(gdb) p e
$1 = (Event *) 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] [Created] (TS-1605) crash at mime_parse_int64
Bin Chen created TS-1605:
Summary: crash at mime_parse_int64
Key: TS-1605
URL: https://issues.apache.org/jira/browse/TS-1605
Project: Traffic Server
Issue Type: Bug
Components: HTTP, MIME
Reporter: Bin Chen
{code}
#0 0x00610f76 in mime_parse_int64 (buf=0x3fb ,
end=0x380f74 ) at MIME.cc:3076
/usr/src/debug/trafficserver-3.2.0/proxy/hdrs/MIME.cc:3076:106103:beg:0x610f76
Missing separate debuginfos, use: debuginfo-install expat-2.0.1-9.1.el6.x86_64
glibc-2.12-1.47.el6.x86_64 keyutils-libs-1.4-3.el6.x86_64
krb5-libs-1.9-22.el6.x86_64 libcom_err-1.41.12-11.el6.x86_64
libgcc-4.4.6-3.el6.x86_64 libselinux-2.0.94-5.2.el6.x86_64
libstdc++-4.4.6-3.el6.x86_64 ncurses-libs-5.7-3.20090208.el6.x86_64
openssl-1.0.0-20.el6.x86_64 pcre-7.8-3.1.el6.x86_64 readline-6.0-3.el6.x86_64
tcl-8.5.7-6.el6.x86_64 xz-libs-4.999.9-0.3.beta.20091007git.el6.x86_64
zlib-1.2.3-27.el6.x86_64
(gdb) bt
#0 0x00610f76 in mime_parse_int64 (buf=0x3fb ,
end=0x380f74 ) at MIME.cc:3076
#1 0x0060d7a6 in mime_field_value_get_int64 (field=0x2af6853bfdd0) at
MIME.cc:1694
#2 0x0057d41c in MIMEHdr::value_get_int64 (this=0x2af6853bf5c8,
name=0x2db7388 "Age", name_length=3)
at ../../proxy/hdrs/MIME.h:1217
#3 0x005a9230 in MIMEHdr::get_age (this=0x2af6853bf5c8) at
../../proxy/hdrs/MIME.h:1356
#4 0x005aac0b in HttpTransactHeaders::calculate_document_age
(request_time=1353920547, response_time=1353920547,
base_response=0x2af6853bf5c8, base_response_date=1352509636,
now=1354258269) at HttpTransactHeaders.cc:400
#5 0x00581d73 in HttpTransactCache::SelectFromAlternates
(cache_vector=0x2af5f0a057c0,
client_request=0x2af5f0a05780, http_config_params=0x2af6005fda30) at
HttpTransactCache.cc:221
#6 0x00692c34 in CacheVC::openReadStartHead (this=0x2af5f0a056c0,
event=3900, e=0x0) at CacheRead.cc:1019
#7 0x004e6fae in Continuation::handleEvent (this=0x2af5f0a056c0,
event=3900, data=0x0)
at ../iocore/eventsystem/I_Continuation.h:146
#8 0x006717e2 in CacheVC::handleReadDone (this=0x2af5f0a056c0,
event=3900, e=0x2af5f0a05840) at Cache.cc:1952
#9 0x004e6fae in Continuation::handleEvent (this=0x2af5f0a056c0,
event=3900, data=0x2af5f0a05840)
at ../iocore/eventsystem/I_Continuation.h:146
#10 0x006761cc in AIOCallbackInternal::io_complete
(this=0x2af5f0a05840, event=1, data=0x2af79c001420)
at ../../iocore/aio/P_AIO.h:80
#11 0x004e6fae in Continuation::handleEvent (this=0x2af5f0a05840,
event=1, data=0x2af79c001420)
at ../iocore/eventsystem/I_Continuation.h:146
#12 0x006d99b8 in EThread::process_event (this=0x2af4f84e6010,
e=0x2af79c001420, calling_code=1)
at UnixEThread.cc:189
#13 0x006d9b86 in EThread::execute (this=0x2af4f84e6010) at
UnixEThread.cc:240
#14 0x006d89e7 in spawn_thread_internal (a=0x2af4fc603b00) at
Thread.cc:88
#15 0x0034bfc077f1 in start_thread () from /lib64/libpthread.so.0
#16 0x0034bf8e570d in clone () from /lib64/libc.so.6
(gdb) f 0
#0 0x00610f76 in mime_parse_int64 (buf=0x3fb ,
end=0x380f74 ) at MIME.cc:3076
/usr/src/debug/trafficserver-3.2.0/proxy/hdrs/MIME.cc:3076:106103:beg:0x610f76
(gdb) l
3071 bool negative;
3072
3073 if (!buf || (buf == end))
3074return 0;
3075
3076 if (is_digit(*buf)) // fast case
3077{
3078 num = *buf++ - '0';
3079 while ((buf != end) && is_digit(*buf))
3080num = (num * 10) + (*buf++ - '0');
(gdb) p buf
$1 = 0x3fb
{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-1600) when one http transaction complete, should HttpClientSession release serversession
[ https://issues.apache.org/jira/browse/TS-1600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen updated TS-1600: - Attachment: TS-1600.patch > when one http transaction complete, should HttpClientSession release > serversession > --- > > Key: TS-1600 > URL: https://issues.apache.org/jira/browse/TS-1600 > Project: Traffic Server > Issue Type: Improvement > Components: HTTP >Affects Versions: 3.2.0 >Reporter: Bin Chen >Assignee: Bin Chen >Priority: Minor > Attachments: TS-1600.patch > > > when one http transaction complete, HttpClientSession store last > serversession in bound_ss. In high hit ratio, ts may use more serversession > using less lock(server session pool). But in high pressure env, ts will use > more serversession. Maybe we should use less serversession(origin connection > limitted) by release bound_ss to serversession pool in transaction > complete(HttpClientSession::release()) -- 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-1610) if httpSessionManager.acquire_session can't acquire server_session, how to do is better?
Bin Chen created TS-1610: Summary: if httpSessionManager.acquire_session can't acquire server_session, how to do is better? Key: TS-1610 URL: https://issues.apache.org/jira/browse/TS-1610 Project: Traffic Server Issue Type: Improvement Components: Network Reporter: Bin Chen if httpSessionManager.acquire_session can't acquire server_session, how to do is better? 1. retry by rescheduler? 2. use spin lock in server_session if use global_session_pool? -- 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-1610) if httpSessionManager.acquire_session can't acquire server_session, how to do is better?
[ https://issues.apache.org/jira/browse/TS-1610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen reassigned TS-1610: Assignee: Bin Chen > if httpSessionManager.acquire_session can't acquire server_session, how to do > is better? > > > Key: TS-1610 > URL: https://issues.apache.org/jira/browse/TS-1610 > Project: Traffic Server > Issue Type: Improvement > Components: Network >Reporter: Bin Chen >Assignee: Bin Chen > > if httpSessionManager.acquire_session can't acquire server_session, how to do > is better? > 1. retry by rescheduler? > 2. use spin lock in server_session if use global_session_pool? -- 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-1602) crash at http_hdr_type_get
[
https://issues.apache.org/jira/browse/TS-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bin Chen reassigned TS-1602:
Assignee: taorui (was: Bin Chen)
> crash at http_hdr_type_get
> --
>
> Key: TS-1602
> URL: https://issues.apache.org/jira/browse/TS-1602
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
>Affects Versions: 3.2.0
>Reporter: Bin Chen
>Assignee: taorui
>
> {code}
> Program terminated with signal 11, Segmentation fault.
> #0 0x005034b0 in http_hdr_type_get (hh=0x2abf98de9898) at
> hdrs/HTTP.h:957
> /usr/src/debug/trafficserver-3.2.0/proxy/hdrs/HTTP.h:957:28250:beg:0x5034b0
> Missing separate debuginfos, use: debuginfo-install
> expat-2.0.1-9.1.el6.x86_64 glibc-2.12-1.47.el6.x86_64
> keyutils-libs-1.4-3.el6.x86_64 krb5-libs-1.9-22.el6.x86_64
> libcom_err-1.41.12-11.el6.x86_64 libgcc-4.4.6-3.el6.x86_64
> libselinux-2.0.94-5.2.el6.x86_64 libstdc++-4.4.6-3.el6.x86_64
> ncurses-libs-5.7-3.20090208.el6.x86_64 openssl-1.0.0-20.el6.x86_64
> pcre-7.8-3.1.el6.x86_64 readline-6.0-3.el6.x86_64 tcl-8.5.7-6.el6.x86_64
> xz-libs-4.999.9-0.3.beta.20091007git.el6.x86_64 zlib-1.2.3-27.el6.x86_64
> (gdb) bt
> #0 0x005034b0 in http_hdr_type_get (hh=0x2abf98de9898) at
> hdrs/HTTP.h:957
> #1 0x005034d2 in HTTPHdr::type_get (this=0x2ba4d149f088) at
> hdrs/HTTP.h:967
> #2 0x0058e6f4 in HttpTransact::HandleCacheOpenRead
> (s=0x2ba51d5d2838) at HttpTransact.cc:2046
> #3 0x0057af93 in HttpSM::call_transact_and_set_next_state
> (this=0x2ba51d5d27d0,
> f=0x58e5cc ) at
> HttpSM.cc:6425
> #4 0x0056e576 in HttpSM::state_cache_open_read (this=0x2ba51d5d27d0,
> event=1102, data=0x2ba3f8d00c10)
> at HttpSM.cc:2406
> #5 0x0056e968 in HttpSM::main_handler (this=0x2ba51d5d27d0,
> event=1102, data=0x2ba3f8d00c10) at HttpSM.cc:2465
> #6 0x004e6fae in Continuation::handleEvent (this=0x2ba51d5d27d0,
> event=1102, data=0x2ba3f8d00c10)
> at ../iocore/eventsystem/I_Continuation.h:146
> #7 0x00556f02 in HttpCacheSM::state_cache_open_read
> (this=0x2ba51d5d4898, event=1102, data=0x2ba3f8d00c10)
> at HttpCacheSM.cc:118
> #8 0x004e6fae in Continuation::handleEvent (this=0x2ba51d5d4898,
> event=1102, data=0x2ba3f8d00c10)
> at ../iocore/eventsystem/I_Continuation.h:146
> #9 0x00649779 in CacheContinuation::callback_user
> (this=0x2ba410a95560, res=1102, e=0x2ba3f8d00c10)
> at ClusterCache.cc:2813
> #10 0x00648433 in CacheContinuation::remoteOpEvent
> (this=0x2ba410a95560, event_code=1151, e=0x2ba4d149f000)
> at ClusterCache.cc:2345
> #11 0x004e6fae in Continuation::handleEvent (this=0x2ba410a95560,
> event=1151, data=0x2ba4d149f000)
> at ../iocore/eventsystem/I_Continuation.h:146
> #12 0x0064751c in cache_op_result_ClusterFunction (ch=0x2ba428881140,
> d=0x2ba570cd4018, l=2776)
> at ClusterCache.cc:2088
> #13 0x00651747 in ClusterHandler::process_incoming_callouts
> (this=0x2ba428881140, m=0x2ba3f92a3c50)
> at ClusterHandler.cc:1237
> #14 0x006598db in ClusterCalloutContinuation::CalloutHandler
> (this=0x2ba4284057c0, event=2, e=0x2ba314b48ef0)
> at ClusterHandlerBase.cc:62
> #15 0x004e6fae in Continuation::handleEvent (this=0x2ba4284057c0,
> event=2, data=0x2ba314b48ef0)
> at ../iocore/eventsystem/I_Continuation.h:146
> #16 0x006d99b8 in EThread::process_event (this=0x2ba2cf72e010,
> e=0x2ba314b48ef0, calling_code=2)
> at UnixEThread.cc:189
> #17 0x006dbd79 in PriorityEventQueue::check_ready
> (this=0x2ba2cf82ec40, now=135396960399086, t=0x2ba2cf72e010)
> at PQ-List.cc:141
> #18 0x006d9c8a in EThread::execute (this=0x2ba2cf72e010) at
> UnixEThread.cc:258
> #19 0x006d89e7 in spawn_thread_internal (a=0x15c19a0) at Thread.cc:88
> #20 0x003c088077f1 in start_thread () from /lib64/libpthread.so.0
> #21 0x003c084e570d in clone () from /lib64/libc.so.6
> (gdb) f 0
> #0 0x005034b0 in http_hdr_type_get (hh=0x2abf98de9898) at
> hdrs/HTTP.h:957
> /usr/src/debug/trafficserver-3.2.0/proxy/hdrs/HTTP.h:957:28250:beg:0x5034b0
> (gdb) l
> 952
> -*/
> 953
> 954 inline HTTPType
> 955 http_hdr_type_get(HTTPHdrImpl *hh)
> 956 {
> 957 return (hh->m_polarity);
> 958 }
> 959
> 960
> /*-
> 961
> -*/
> (gdb) p hh->m_polarity
> Cannot access memory at address 0x2abf98de989c
> (gdb) p *hh
> Cannot access memory at address 0x2abf98de9898
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please con
[jira] [Assigned] (TS-1592) crash at HttpCompat::parse_tok_list
[
https://issues.apache.org/jira/browse/TS-1592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bin Chen reassigned TS-1592:
Assignee: taorui (was: Bin Chen)
> crash at HttpCompat::parse_tok_list
> ---
>
> Key: TS-1592
> URL: https://issues.apache.org/jira/browse/TS-1592
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
>Affects Versions: 3.2.0
> Environment: full_cluster
>Reporter: Bin Chen
>Assignee: taorui
>
> {code}
> Program terminated with signal 11, Segmentation fault.
> #0 HttpCompat::parse_tok_list (list=0x2b3d7aca86f0, trim_quotes= optimized out>, string=,
> len=, sep=59 ';') at HttpCompat.cc:77
> /usr/src/debug/trafficserver-3.2.0/proxy/hdrs/HttpCompat.cc:77:2565:beg:0x5a7990
> Missing separate debuginfos, use: debuginfo-install
> expat-2.0.1-9.1.el6.x86_64 glibc-2.12-1.47.el6.x86_64
> keyutils-libs-1.4-3.el6.x86_64 krb5-libs-1.9-22.el6.x86_64
> libcom_err-1.41.12-11.el6.x86_64 libgcc-4.4.6-3.el6.x86_64
> libselinux-2.0.94-5.2.el6.x86_64 libstdc++-4.4.6-3.el6.x86_64
> ncurses-libs-5.7-3.20090208.el6.x86_64 openssl-1.0.0-20.el6.x86_64
> pcre-7.8-3.1.el6.x86_64 readline-6.0-3.el6.x86_64 tcl-8.5.7-6.el6.x86_64
> xz-libs-4.999.9-0.3.beta.20091007git.el6.x86_64 zlib-1.2.3-27.el6.x86_64
> (gdb) bt
> #0 HttpCompat::parse_tok_list (list=0x2b3d7aca86f0, trim_quotes= optimized out>, string=,
> len=, sep=59 ';') at HttpCompat.cc:77
> #1 0x0052e4fc in parse_semicolon_list (accept_field=0x2b3da50ab118,
> content_field=)
> at ../../proxy/hdrs/HttpCompat.h:92
> #2 HttpTransactCache::calculate_quality_of_accept_match
> (accept_field=0x2b3da50ab118, content_field=)
> at HttpTransactCache.cc:519
> #3 0x00530cf6 in HttpTransactCache::calculate_quality_of_match
> (http_config_param=0x2b3da6a074a0,
> client_request=0x2b3d94749ba0, obj_client_request=0x2b3f4748d5c0,
> obj_origin_server_response=0x2b3f4748d600)
> at HttpTransactCache.cc:327
> #4 0x00531a7d in HttpTransactCache::SelectFromAlternates
> (cache_vector=0x2b3d94749be0,
> client_request=0x2b3d94749ba0, http_config_params=0x2b3da6a074a0) at
> HttpTransactCache.cc:214
> #5 0x006245e5 in CacheVC::openReadStartHead (this=0x2b3d94749ae0,
> event=3900, e=0x0) at CacheRead.cc:1019
> #6 0x00604348 in handleEvent (this=0x2b3d94749ae0, event= optimized out>, e=)
> at ../../iocore/eventsystem/I_Continuation.h:146
> #7 CacheVC::handleReadDone (this=0x2b3d94749ae0, event= out>, e=) at Cache.cc:1952
> #8 0x00608035 in handleEvent (this=,
> event=, data=)
> at ../../iocore/eventsystem/I_Continuation.h:146
> #9 AIOCallbackInternal::io_complete (this=,
> event=, data=)
> at ../../iocore/aio/P_AIO.h:80
> #10 0x0066ae94 in handleEvent (this=0x2b3d7a42b010, e=0x213ec10,
> calling_code=1) at I_Continuation.h:146
> #11 EThread::process_event (this=0x2b3d7a42b010, e=0x213ec10, calling_code=1)
> at UnixEThread.cc:189
> #12 0x0066b773 in EThread::execute (this=0x2b3d7a42b010) at
> UnixEThread.cc:240
> #13 0x00669c72 in spawn_thread_internal (a=0x1785910) at Thread.cc:88
> #14 0x0034bfc077f1 in start_thread () from /lib64/libpthread.so.0
> #15 0x0034bf8e570d in clone () from /lib64/libc.so.6
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1405) apply time-wheel scheduler about event system
[ https://issues.apache.org/jira/browse/TS-1405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen updated TS-1405: - Attachment: TS-1405-v5.patch improve event cancel > apply time-wheel scheduler about event system > -- > > Key: TS-1405 > URL: https://issues.apache.org/jira/browse/TS-1405 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Affects Versions: 3.2.0 >Reporter: Bin Chen >Assignee: Bin Chen > Fix For: 3.3.1 > > Attachments: linux_time_wheel.patch, linux_time_wheel_v2.patch, > linux_time_wheel_v3.patch, time_wheel_v4.patch, TS-1405-v5.patch > > > when have more and more event in event system scheduler, it's worse. This is > the reason why we use inactivecop to handler keepalive. the new scheduler is > time-wheel. It's have better time complexity(O(1)) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1405) apply time-wheel scheduler about event system
[ https://issues.apache.org/jira/browse/TS-1405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen updated TS-1405: - Attachment: (was: TS-1405-v5.patch) > apply time-wheel scheduler about event system > -- > > Key: TS-1405 > URL: https://issues.apache.org/jira/browse/TS-1405 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Affects Versions: 3.2.0 >Reporter: Bin Chen >Assignee: Bin Chen > Fix For: 3.3.1 > > Attachments: linux_time_wheel.patch, linux_time_wheel_v2.patch, > linux_time_wheel_v3.patch, time_wheel_v4.patch > > > when have more and more event in event system scheduler, it's worse. This is > the reason why we use inactivecop to handler keepalive. the new scheduler is > time-wheel. It's have better time complexity(O(1)) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TS-1600) when one http transaction complete, should HttpClientSession release serversession
[ https://issues.apache.org/jira/browse/TS-1600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen closed TS-1600. Resolution: Invalid > when one http transaction complete, should HttpClientSession release > serversession > --- > > Key: TS-1600 > URL: https://issues.apache.org/jira/browse/TS-1600 > Project: Traffic Server > Issue Type: Improvement > Components: HTTP >Affects Versions: 3.2.0 >Reporter: Bin Chen >Assignee: Bin Chen >Priority: Minor > Attachments: TS-1600.patch > > > when one http transaction complete, HttpClientSession store last > serversession in bound_ss. In high hit ratio, ts may use more serversession > using less lock(server session pool). But in high pressure env, ts will use > more serversession. Maybe we should use less serversession(origin connection > limitted) by release bound_ss to serversession pool in transaction > complete(HttpClientSession::release()) -- 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-1324) inactivitycop performance may need to improve
[ https://issues.apache.org/jira/browse/TS-1324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen closed TS-1324. Resolution: Duplicate TS-1453 > inactivitycop performance may need to improve > - > > Key: TS-1324 > URL: https://issues.apache.org/jira/browse/TS-1324 > Project: Traffic Server > Issue Type: Sub-task > Components: Network >Affects Versions: 3.3.0 >Reporter: Zhao Yongming > Fix For: 3.3.1 > > > inactivitycop is a scheduled on each net thread, for every 1s it will check > all the connections status, how can we manage millions of 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-1601) HttpServerSession::release don't close ServerSession if ServerSessionPool locking contention
[ https://issues.apache.org/jira/browse/TS-1601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen updated TS-1601: - Attachment: TS-1601.patch if locking failed, then reschedule. > HttpServerSession::release don't close ServerSession if ServerSessionPool > locking contention > > > Key: TS-1601 > URL: https://issues.apache.org/jira/browse/TS-1601 > Project: Traffic Server > Issue Type: Improvement > Components: Network >Affects Versions: 3.2.0 >Reporter: Bin Chen >Assignee: Bin Chen >Priority: Minor > Attachments: TS-1601.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-1579) register_ShowNet calling is high load
[
https://issues.apache.org/jira/browse/TS-1579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bin Chen closed TS-1579.
Resolution: Fixed
> register_ShowNet calling is high load
> -
>
> Key: TS-1579
> URL: https://issues.apache.org/jira/browse/TS-1579
> Project: Traffic Server
> Issue Type: Bug
> Components: Stats
>Affects Versions: 3.2.0
>Reporter: Bin Chen
>Assignee: Bin Chen
> Fix For: 3.3.3
>
>
> a box running ts:
> {code}
> run perf top
> samples pcnt function
>DSO
> ___ _
> _
> __
> 1270.00 7.8% register_ShowNet(Continuation*, HTTPHdr*)
>traffic_server
> 860.00 5.3% copy_user_generic_string
>[kernel.kallsyms]
> 743.00 4.6% ixgbe_notify_dca
>[ixgbe]
> 425.00 2.6% ink_freelist_new
>libtsutil.so.3.2.0
> 260.00 1.6% kmem_cache_free
>[kernel.kallsyms]
> 248.00 1.5% tcp_ack
>[kernel.kallsyms]
> 246.00 1.5% kfree
>[kernel.kallsyms]
> 232.00 1.4% intel_idle
>[kernel.kallsyms]
> 228.00 1.4% __memcpy_ssse3_back
>libc-2.12.so
> 219.00 1.4% PriorityEventQueue::enqueue(Event*, long)
>traffic_server
> 181.00 1.1% _spin_lock
>[kernel.kallsyms]
> 176.00 1.1% ink_freelist_free
>libtsutil.so.3.2.0
> 158.00 1.0% ip_route_input
>[kernel.kallsyms]
> 135.00 0.8% __inet_lookup_established
>[kernel.kallsyms]
> 126.00 0.8% register_stat_callbacks()
>traffic_server
> {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-1579) register_ShowNet calling is high load
[
https://issues.apache.org/jira/browse/TS-1579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bin Chen updated TS-1579:
-
Fix Version/s: (was: 3.3.3)
3.2.0
> register_ShowNet calling is high load
> -
>
> Key: TS-1579
> URL: https://issues.apache.org/jira/browse/TS-1579
> Project: Traffic Server
> Issue Type: Bug
> Components: Stats
>Affects Versions: 3.2.0
>Reporter: Bin Chen
>Assignee: Bin Chen
> Fix For: 3.2.0
>
>
> a box running ts:
> {code}
> run perf top
> samples pcnt function
>DSO
> ___ _
> _
> __
> 1270.00 7.8% register_ShowNet(Continuation*, HTTPHdr*)
>traffic_server
> 860.00 5.3% copy_user_generic_string
>[kernel.kallsyms]
> 743.00 4.6% ixgbe_notify_dca
>[ixgbe]
> 425.00 2.6% ink_freelist_new
>libtsutil.so.3.2.0
> 260.00 1.6% kmem_cache_free
>[kernel.kallsyms]
> 248.00 1.5% tcp_ack
>[kernel.kallsyms]
> 246.00 1.5% kfree
>[kernel.kallsyms]
> 232.00 1.4% intel_idle
>[kernel.kallsyms]
> 228.00 1.4% __memcpy_ssse3_back
>libc-2.12.so
> 219.00 1.4% PriorityEventQueue::enqueue(Event*, long)
>traffic_server
> 181.00 1.1% _spin_lock
>[kernel.kallsyms]
> 176.00 1.1% ink_freelist_free
>libtsutil.so.3.2.0
> 158.00 1.0% ip_route_input
>[kernel.kallsyms]
> 135.00 0.8% __inet_lookup_established
>[kernel.kallsyms]
> 126.00 0.8% register_stat_callbacks()
>traffic_server
> {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-1529) transaction_no_activity_timeout_out do not work correct
[ https://issues.apache.org/jira/browse/TS-1529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen closed TS-1529. Resolution: Invalid > transaction_no_activity_timeout_out do not work correct > > > Key: TS-1529 > URL: https://issues.apache.org/jira/browse/TS-1529 > Project: Traffic Server > Issue Type: Bug > Components: Network >Affects Versions: 3.2.0 >Reporter: Bin Chen >Assignee: Bin Chen > Fix For: 3.3.1 > > Attachments: timeout.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-1081) Eliminate the additional internal copy of the "pristine" URL string
[ https://issues.apache.org/jira/browse/TS-1081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13533691#comment-13533691 ] Bin Chen commented on TS-1081: -- now, t_state.pristine_url is create in HttpSM::do_remap_request(). if request havn`t enter to remap, then t_state.pristine_url will be NULL. > Eliminate the additional internal copy of the "pristine" URL string > --- > > Key: TS-1081 > URL: https://issues.apache.org/jira/browse/TS-1081 > Project: Traffic Server > Issue Type: Improvement > Components: HTTP >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom > Fix For: 3.1.2 > > Attachments: TS-1081.diff > > > We have (at least) two copies of the pristine URL in the code. One is the > actual URL object (as used by the APIs), and one is a string reference to the > URL (char*). The latter is only used in a couple of places, primarily when > the tag is used in a custom log format. I propose that we eliminate > this additional string version of the pristine URL entirely. -- 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-1628) in LogAccessHttp::validate_unmapped_url(), m_http_sm->t_state.pristine_url maybe invalid()
Bin Chen created TS-1628: Summary: in LogAccessHttp::validate_unmapped_url(), m_http_sm->t_state.pristine_url maybe invalid() Key: TS-1628 URL: https://issues.apache.org/jira/browse/TS-1628 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: Bin Chen if ts accept a invalid request, so m_http_sm->t_state.pristine_url won`t be created(which create in do_remap_request). So if ts enable ink_debug_assert, then will assert at URL::string_get_ref(). -- 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-1628) in LogAccessHttp::validate_unmapped_url(), m_http_sm->t_state.pristine_url maybe invalid()
[ https://issues.apache.org/jira/browse/TS-1628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen reassigned TS-1628: Assignee: Bin Chen > in LogAccessHttp::validate_unmapped_url(), m_http_sm->t_state.pristine_url > maybe invalid() > -- > > Key: TS-1628 > URL: https://issues.apache.org/jira/browse/TS-1628 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: Bin Chen >Assignee: Bin Chen > Attachments: TS-1628.patch > > > if ts accept a invalid request, so m_http_sm->t_state.pristine_url won`t be > created(which create in do_remap_request). So if ts enable ink_debug_assert, > then will assert at URL::string_get_ref(). -- 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-1628) in LogAccessHttp::validate_unmapped_url(), m_http_sm->t_state.pristine_url maybe invalid()
[ https://issues.apache.org/jira/browse/TS-1628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen updated TS-1628: - Attachment: TS-1628.patch > in LogAccessHttp::validate_unmapped_url(), m_http_sm->t_state.pristine_url > maybe invalid() > -- > > Key: TS-1628 > URL: https://issues.apache.org/jira/browse/TS-1628 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: Bin Chen > Attachments: TS-1628.patch > > > if ts accept a invalid request, so m_http_sm->t_state.pristine_url won`t be > created(which create in do_remap_request). So if ts enable ink_debug_assert, > then will assert at URL::string_get_ref(). -- 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-1637) nodes as idle/dead if we have not heard from them in awhile
Bin Chen created TS-1637: Summary: 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 Reporter: Bin Chen 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] [Assigned] (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 reassigned TS-1637: Assignee: 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 >Reporter: Bin Chen >Assignee: Bin Chen > > 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: - Affects Version/s: 3.2.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 > > 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.patch improve cluster start when have more node > 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 > Attachments: TS-1637.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-1601) HttpServerSession::release don't close ServerSession if ServerSessionPool locking contention
[ https://issues.apache.org/jira/browse/TS-1601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13544528#comment-13544528 ] Bin Chen commented on TS-1601: -- 3.3.1 commit:27c0f22487b246b327827c4f0b6c340cdaed6bea > HttpServerSession::release don't close ServerSession if ServerSessionPool > locking contention > > > Key: TS-1601 > URL: https://issues.apache.org/jira/browse/TS-1601 > Project: Traffic Server > Issue Type: Improvement > Components: Network >Affects Versions: 3.2.0 >Reporter: Bin Chen >Assignee: Bin Chen >Priority: Minor > Attachments: TS-1601.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-1601) HttpServerSession::release don't close ServerSession if ServerSessionPool locking contention
[ https://issues.apache.org/jira/browse/TS-1601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen closed TS-1601. Resolution: Fixed Fix Version/s: 3.3.1 > HttpServerSession::release don't close ServerSession if ServerSessionPool > locking contention > > > Key: TS-1601 > URL: https://issues.apache.org/jira/browse/TS-1601 > Project: Traffic Server > Issue Type: Improvement > Components: Network >Affects Versions: 3.2.0 >Reporter: Bin Chen >Assignee: Bin Chen >Priority: Minor > Fix For: 3.3.1 > > Attachments: TS-1601.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-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: TS-1405.patch 1. reconstruct event cancel handler > apply time-wheel scheduler about event system > -- > > Key: TS-1405 > URL: https://issues.apache.org/jira/browse/TS-1405 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Affects Versions: 3.2.0 >Reporter: Bin Chen >Assignee: Bin Chen > Fix For: 3.3.1 > > Attachments: linux_time_wheel.patch, linux_time_wheel_v2.patch, > linux_time_wheel_v3.patch, time_wheel_v4.patch, TS-1405.patch > > > when have more and more event in event system scheduler, it's worse. This is > the reason why we use inactivecop to handler keepalive. the new scheduler is > time-wheel. It's have better time complexity(O(1)) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1405) apply time-wheel scheduler about event system
[ https://issues.apache.org/jira/browse/TS-1405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen updated TS-1405: - Attachment: (was: TS-1405.patch) > apply time-wheel scheduler about event system > -- > > Key: TS-1405 > URL: https://issues.apache.org/jira/browse/TS-1405 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Affects Versions: 3.2.0 >Reporter: Bin Chen >Assignee: Bin Chen > Fix For: 3.3.1 > > Attachments: linux_time_wheel.patch, linux_time_wheel_v2.patch, > linux_time_wheel_v3.patch, linux_time_wheel_v4.patch > > > when have more and more event in event system scheduler, it's worse. This is > the reason why we use inactivecop to handler keepalive. the new scheduler is > time-wheel. It's have better time complexity(O(1)) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1405) apply time-wheel scheduler about event system
[ https://issues.apache.org/jira/browse/TS-1405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen updated TS-1405: - Attachment: (was: time_wheel_v4.patch) > apply time-wheel scheduler about event system > -- > > Key: TS-1405 > URL: https://issues.apache.org/jira/browse/TS-1405 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Affects Versions: 3.2.0 >Reporter: Bin Chen >Assignee: Bin Chen > Fix For: 3.3.1 > > Attachments: linux_time_wheel.patch, linux_time_wheel_v2.patch, > linux_time_wheel_v3.patch, linux_time_wheel_v4.patch > > > when have more and more event in event system scheduler, it's worse. This is > the reason why we use inactivecop to handler keepalive. the new scheduler is > time-wheel. It's have better time complexity(O(1)) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1405) apply time-wheel scheduler about event system
[ https://issues.apache.org/jira/browse/TS-1405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen updated TS-1405: - Attachment: linux_time_wheel_v4.patch rename TS-1405 to linux_time_wheel_v4.patch. it's last version > apply time-wheel scheduler about event system > -- > > Key: TS-1405 > URL: https://issues.apache.org/jira/browse/TS-1405 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Affects Versions: 3.2.0 >Reporter: Bin Chen >Assignee: Bin Chen > Fix For: 3.3.1 > > Attachments: linux_time_wheel.patch, linux_time_wheel_v2.patch, > linux_time_wheel_v3.patch, linux_time_wheel_v4.patch > > > when have more and more event in event system scheduler, it's worse. This is > the reason why we use inactivecop to handler keepalive. the new scheduler is > time-wheel. It's have better time complexity(O(1)) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1405) apply time-wheel scheduler about event system
[ https://issues.apache.org/jira/browse/TS-1405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13588925#comment-13588925 ] Bin Chen commented on TS-1405: -- 1. in EThread::set_event_cancel(), only cancel event in this case: a. have be inserted in priority queue (e->in_the_priority_queue) && e->timeout_at > now + event_cancel_delay(s) b. localQueue Event will be process soon, so don't set cancel. This will be less cancel handler. so canclled event won`t in race condition. 2. if cancelled flag can only be set while holding the mutex of the Event, the set_event_cancel() will more sigle. 3. if enable define INACITVATE_TIMEOUT, vc->timeout will be used vc. if free_event immediatly, there still a race condition(some vc use timeout, but this event have be freed by process_cancelled_event). so add event_cancel_delay. > apply time-wheel scheduler about event system > -- > > Key: TS-1405 > URL: https://issues.apache.org/jira/browse/TS-1405 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Affects Versions: 3.2.0 >Reporter: Bin Chen >Assignee: Bin Chen > Fix For: 3.3.1 > > Attachments: linux_time_wheel.patch, linux_time_wheel_v2.patch, > linux_time_wheel_v3.patch, linux_time_wheel_v4.patch > > > when have more and more event in event system scheduler, it's worse. This is > the reason why we use inactivecop to handler keepalive. the new scheduler is > time-wheel. It's have better time complexity(O(1)) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1405) apply time-wheel scheduler about event system
[ https://issues.apache.org/jira/browse/TS-1405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13588932#comment-13588932 ] Bin Chen commented on TS-1405: -- i will update patch by the other comment. 1. modify set_event_cancel(), remove race handler about set cancelled flag. 2. rename some function and variable > apply time-wheel scheduler about event system > -- > > Key: TS-1405 > URL: https://issues.apache.org/jira/browse/TS-1405 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Affects Versions: 3.2.0 >Reporter: Bin Chen >Assignee: Bin Chen > Fix For: 3.3.1 > > Attachments: linux_time_wheel.patch, linux_time_wheel_v2.patch, > linux_time_wheel_v3.patch, linux_time_wheel_v4.patch > > > when have more and more event in event system scheduler, it's worse. This is > the reason why we use inactivecop to handler keepalive. the new scheduler is > time-wheel. It's have better time complexity(O(1)) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [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=13588925#comment-13588925 ] Bin Chen edited comment on TS-1405 at 2/28/13 12:10 AM: # in EThread::set_event_cancel(), only cancel event in this case: * have be inserted in priority queue (e->in_the_priority_queue) && e->timeout_at > now + event_cancel_delay(s) * localQueue Event will be process soon, so don't set cancel. This will be less cancel handler. so canclled event won`t in race condition. # if cancelled flag can only be set while holding the mutex of the Event, the set_event_cancel() will more simple. # if enable define INACITVATE_TIMEOUT, vc->timeout will be used vc. if free_event immediatly, there still a race condition(some vc use timeout, but this event have be freed by process_cancelled_event). so add event_cancel_delay. was (Author: kuotai): 1. in EThread::set_event_cancel(), only cancel event in this case: a. have be inserted in priority queue (e->in_the_priority_queue) && e->timeout_at > now + event_cancel_delay(s) b. localQueue Event will be process soon, so don't set cancel. This will be less cancel handler. so canclled event won`t in race condition. 2. if cancelled flag can only be set while holding the mutex of the Event, the set_event_cancel() will more sigle. 3. if enable define INACITVATE_TIMEOUT, vc->timeout will be used vc. if free_event immediatly, there still a race condition(some vc use timeout, but this event have be freed by process_cancelled_event). so add event_cancel_delay. > apply time-wheel scheduler about event system > -- > > Key: TS-1405 > URL: https://issues.apache.org/jira/browse/TS-1405 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Affects Versions: 3.2.0 >Reporter: Bin Chen >Assignee: Bin Chen > Fix For: 3.3.1 > > Attachments: linux_time_wheel.patch, linux_time_wheel_v2.patch, > linux_time_wheel_v3.patch, linux_time_wheel_v4.patch > > > when have more and more event in event system scheduler, it's worse. This is > the reason why we use inactivecop to handler keepalive. the new scheduler is > time-wheel. It's have better time complexity(O(1)) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [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=13588932#comment-13588932 ] Bin Chen edited comment on TS-1405 at 2/28/13 12:11 AM: i will update patch by the other comment. # modify set_event_cancel(), remove race handler about set cancelled flag. # rename some function and variable was (Author: kuotai): i will update patch by the other comment. 1. modify set_event_cancel(), remove race handler about set cancelled flag. 2. rename some function and variable > apply time-wheel scheduler about event system > -- > > Key: TS-1405 > URL: https://issues.apache.org/jira/browse/TS-1405 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Affects Versions: 3.2.0 >Reporter: Bin Chen >Assignee: Bin Chen > Fix For: 3.3.1 > > Attachments: linux_time_wheel.patch, linux_time_wheel_v2.patch, > linux_time_wheel_v3.patch, linux_time_wheel_v4.patch > > > when have more and more event in event system scheduler, it's worse. This is > the reason why we use inactivecop to handler keepalive. the new scheduler is > time-wheel. It's have better time complexity(O(1)) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [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=13588925#comment-13588925 ] Bin Chen edited comment on TS-1405 at 2/28/13 12:12 AM: * in EThread::set_event_cancel(), only cancel event in this case: ** have be inserted in priority queue (e->in_the_priority_queue) && e->timeout_at > now + event_cancel_delay(s) ** localQueue Event will be process soon, so don't set cancel. This will be less cancel handler. so canclled event won`t in race condition. * if cancelled flag can only be set while holding the mutex of the Event, the set_event_cancel() will more simple. * if enable define INACITVATE_TIMEOUT, vc->timeout will be used vc. if free_event immediatly, there still a race condition(some vc use timeout, but this event have be freed by process_cancelled_event). so add event_cancel_delay. was (Author: kuotai): # in EThread::set_event_cancel(), only cancel event in this case: * have be inserted in priority queue (e->in_the_priority_queue) && e->timeout_at > now + event_cancel_delay(s) * localQueue Event will be process soon, so don't set cancel. This will be less cancel handler. so canclled event won`t in race condition. # if cancelled flag can only be set while holding the mutex of the Event, the set_event_cancel() will more simple. # if enable define INACITVATE_TIMEOUT, vc->timeout will be used vc. if free_event immediatly, there still a race condition(some vc use timeout, but this event have be freed by process_cancelled_event). so add event_cancel_delay. > apply time-wheel scheduler about event system > -- > > Key: TS-1405 > URL: https://issues.apache.org/jira/browse/TS-1405 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Affects Versions: 3.2.0 >Reporter: Bin Chen >Assignee: Bin Chen > Fix For: 3.3.1 > > Attachments: linux_time_wheel.patch, linux_time_wheel_v2.patch, > linux_time_wheel_v3.patch, linux_time_wheel_v4.patch > > > when have more and more event in event system scheduler, it's worse. This is > the reason why we use inactivecop to handler keepalive. the new scheduler is > time-wheel. It's have better time complexity(O(1)) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1750) cpu usage (cluster thread) will more high when some machine being down
Bin Chen created TS-1750: Summary: cpu usage (cluster thread) will more high when some machine being down Key: TS-1750 URL: https://issues.apache.org/jira/browse/TS-1750 Project: Traffic Server Issue Type: Bug Components: Clustering Reporter: Bin Chen when some machine being down, cluster thread will handle clean Event(ClusterHandler::protoZombieEvent). If some cluster_vc isn't close, so the clean Event will be rescheduled. now this delay is CLUSTER_RETRY(HRTIME_MSECONDS(10)). this delay is 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-1750) cpu usage (cluster thread) will more high when some machine being down
[ https://issues.apache.org/jira/browse/TS-1750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen reassigned TS-1750: Assignee: Bin Chen > cpu usage (cluster thread) will more high when some machine being down > -- > > Key: TS-1750 > URL: https://issues.apache.org/jira/browse/TS-1750 > Project: Traffic Server > Issue Type: Bug > Components: Clustering >Reporter: Bin Chen >Assignee: Bin Chen > > when some machine being down, cluster thread will handle clean > Event(ClusterHandler::protoZombieEvent). If some cluster_vc isn't close, so > the clean Event will be rescheduled. now this delay is > CLUSTER_RETRY(HRTIME_MSECONDS(10)). this delay is 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] [Updated] (TS-1750) cpu usage (cluster thread) will more high when some machine being down
[ https://issues.apache.org/jira/browse/TS-1750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen updated TS-1750: - Attachment: TS-1750.patch change event reschedule delay from HRTIME_MSECONDS(10) to HRTIME_SECONDS(1) * 5 > cpu usage (cluster thread) will more high when some machine being down > -- > > Key: TS-1750 > URL: https://issues.apache.org/jira/browse/TS-1750 > Project: Traffic Server > Issue Type: Bug > Components: Clustering >Reporter: Bin Chen >Assignee: Bin Chen > Attachments: TS-1750.patch > > > when some machine being down, cluster thread will handle clean > Event(ClusterHandler::protoZombieEvent). If some cluster_vc isn't close, so > the clean Event will be rescheduled. now this delay is > CLUSTER_RETRY(HRTIME_MSECONDS(10)). this delay is 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] [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_v5.patch modify bt hohn's comments > 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_v2.patch, > linux_time_wheel_v3.patch, linux_time_wheel_v4.patch, > linux_time_wheel_v5.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-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 reassigned TS-1751: Assignee: Bin Chen > 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 > > 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] [Created] (TS-1751) when ts have high cpu usage, cluster thread isn't balance
Bin Chen created TS-1751: Summary: 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 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=13604479#comment-13604479 ] Bin Chen commented on TS-1405: -- this patch based on 3.2. i change to rebase on master. > 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_v2.patch, > linux_time_wheel_v3.patch, linux_time_wheel_v4.patch, > linux_time_wheel_v5.patch > > > when have more and more event in event system scheduler, it's worse. This is > the reason why we use inactivecop to handler keepalive. the new scheduler is > time-wheel. It's have better time complexity(O(1)) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1405) apply time-wheel scheduler about event system
[ https://issues.apache.org/jira/browse/TS-1405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen updated TS-1405: - Attachment: linux_time_wheel_v6.patch rebase on master branch > 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_v2.patch, > linux_time_wheel_v3.patch, linux_time_wheel_v4.patch, > linux_time_wheel_v5.patch, linux_time_wheel_v6.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] [Closed] (TS-1750) cpu usage (cluster thread) will more high when some machine being down
[ https://issues.apache.org/jira/browse/TS-1750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen closed TS-1750. Resolution: Fixed Fix Version/s: 3.3.2 > cpu usage (cluster thread) will more high when some machine being down > -- > > Key: TS-1750 > URL: https://issues.apache.org/jira/browse/TS-1750 > Project: Traffic Server > Issue Type: Bug > Components: Clustering >Reporter: Bin Chen >Assignee: Bin Chen > Fix For: 3.3.2 > > Attachments: TS-1750.patch > > > when some machine being down, cluster thread will handle clean > Event(ClusterHandler::protoZombieEvent). If some cluster_vc isn't close, so > the clean Event will be rescheduled. now this delay is > CLUSTER_RETRY(HRTIME_MSECONDS(10)). this delay is 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-1757) core at LogUtils::escapify_url()
Bin Chen created TS-1757: Summary: 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 NOTE: Traffic Server received Sig 11: Segmentation fault /usr/bin/traffic_server - STACK TRACE: /lib64/libpthread.so.0[0x39ab20f4a0] /usr/bin/traffic_server(_ZN8LogUtils12escapify_urlEP5ArenaPcmPiS2_mPKh+0x60)[0x5b8550] /usr/bin/traffic_server(_ZN13LogAccessHttp4initEv+0xbc)[0x59864c] /usr/bin/traffic_server(_ZN3Log6accessEP9LogAccess+0x11e)[0x59b3ce] /usr/bin/traffic_server(_ZN6HttpSM12update_statsEv+0x630)[0x52be20] /usr/bin/traffic_server(_ZN6HttpSM9kill_thisEv+0x928)[0x5374d8] /usr/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0x198)[0x5377f8] /usr/bin/traffic_server[0x68727b] /usr/bin/traffic_server(_ZN18UnixNetVConnection9mainEventEiP5Event+0x5df)[0x68989f] /usr/bin/traffic_server(_ZN13InactivityCop16check_inactivityEiP5Event+0xa6)[0x6839b6] /usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0xb4)[0x6ac714] /usr/bin/traffic_server(_ZN18PriorityEventQueue11check_readyElP7EThread+0x17b)[0x6aebab] /usr/bin/traffic_server(_ZN7EThread7executeEv+0x12c)[0x6acd0c] /usr/bin/traffic_server[0x6ab2b2] /lib64/libpthread.so.0[0x39ab2077f1] /lib64/libc.so.6(clone+0x6d)[0x39aaee570d] -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1405) apply time-wheel scheduler about event system
[ https://issues.apache.org/jira/browse/TS-1405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen updated TS-1405: - Attachment: linux_time_wheel_v7.patch 1. replace EVENT_FREE to free_event 2. replace 4s to 20ms > 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_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 > > > 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=13607432#comment-13607432 ] Bin Chen commented on TS-1405: -- 1. replace 4s to 20ms: we should pretect some cancelled event not processing(process_event) when some cont reference it. 2. i use event_cancel_list_head switching to pretect the cancelled event only free after delay(20ms) > 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_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 > > > 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=13607436#comment-13607436 ] Bin Chen commented on TS-1405: -- Should ts have no race in Event::cancel_event? > 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_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 > > > when have more and more event in event system scheduler, it's worse. This is > the reason why we use inactivecop to handler keepalive. the new scheduler is > time-wheel. It's have better time complexity(O(1)) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1405) apply time-wheel scheduler about event system
[ https://issues.apache.org/jira/browse/TS-1405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen updated TS-1405: - Attachment: linux_time_wheel_v8.patch remove ink_release_assert > 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_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 > > > 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=13608563#comment-13608563 ] Bin Chen commented on TS-1405: -- if no problem, i should commit this patch. Do you have time to give me some comments about TS-1453? thanks! > 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_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 > > > 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-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:comment-tabpanel&focusedCommentId=13608710#comment-13608710 ] Bin Chen commented on TS-1751: -- 5689 ats 20 0 11.4g 8.1g 6052 S 26.5 17.1 1:44.82 [ET_CLUSTER 11] 5680 ats 20 0 11.4g 8.1g 6052 S 24.2 17.1 1:35.07 [ET_CLUSTER 2] 5683 ats 20 0 11.4g 8.1g 6052 S 23.5 17.1 1:30.06 [ET_CLUSTER 5] 5684 ats 20 0 11.4g 8.1g 6052 S 21.2 17.1 1:24.83 [ET_CLUSTER 6] 5686 ats 20 0 11.4g 8.1g 6052 S 21.2 17.1 1:20.09 [ET_CLUSTER 8] 5687 ats 20 0 11.4g 8.1g 6052 S 19.9 17.1 1:19.56 [ET_CLUSTER 9] 5679 ats 20 0 11.4g 8.1g 6052 S 19.5 17.1 1:15.26 [ET_CLUSTER 1] 5678 ats 20 0 11.4g 8.1g 6052 S 18.6 17.1 1:15.34 [ET_CLUSTER 0] 5681 ats 20 0 11.4g 8.1g 6052 S 16.9 17.1 1:04.98 [ET_CLUSTER 3] 5685 ats 20 0 11.4g 8.1g 6052 S 16.6 17.1 1:04.80 [ET_CLUSTER 7] 5688 ats 20 0 11.4g 8.1g 6052 S 16.6 17.1 1:04.85 [ET_CLUSTER 10] 5682 ats 20 0 11.4g 8.1g 6052 S 15.2 17.1 0:59.80 [ET_CLUSTER 4] > 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 > Attachments: TS-1751.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: - Attachment: TS-1751.patch 1.schedule_every will bound thread, so we use schedule_in. > 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 > Attachments: TS-1751.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-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:comment-tabpanel&focusedCommentId=13608711#comment-13608711 ] Bin Chen commented on TS-1751: -- this patch will improve the balance, but the ClusterHandler::mainClusterEvent() use cpu more. so when schedule this fuction, the dest thread will more cpu usage. > 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 > Attachments: TS-1751.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=13611724#comment-13611724 ] Bin Chen commented on TS-1405: -- not all event will setted cancelled flag by set_event_cancel. So we should set cancelled = true. Some event will be setted twice in cancel_event(). because we delay free event, so twice setting may no problem. > 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_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 > > > 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=13612083#comment-13612083 ] Bin Chen commented on TS-1405: -- I strongly agree this advice. If events using is not corrent, we fix. > 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_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 > > > 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=13614919#comment-13614919 ] Bin Chen commented on TS-1405: -- thank you very much > 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_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_v2.patch why cluster thread not balance: 1、cluster connection fd not balance in cluster. eg. more cluster connection fd in one cluster thread epoll. so new design: 1.balance cluster connection fd to cluster thread > 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.5.0 > > 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] [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=13617469#comment-13617469 ] Bin Chen commented on TS-1405: -- if event in EThrad::process_event() after MUTEX_RELEASE(lock), event is setted cancel flag. then event will free in process_event. Event will be pushed to atomic_list. So event is freeed, but already in atomic list. Use atomic_list to process cancel flag because of reclaiming cancelled event more quick(will use less memory). If we only handle event in_the_priority_queue and recleaim event which not process immediately(eg:event->time_at > 50ms). the design will be simple and the mem using will be aceeptable. > 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_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] [Created] (TS-1793) force cluster connection = cluster number for cluster thread balance
Bin Chen created TS-1793: Summary: 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 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] [Assigned] (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 reassigned TS-1793: Assignee: Bin Chen > 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 > > 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
[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] [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] [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] [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] [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-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] [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] [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-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] [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 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] [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 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] [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] [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] [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
