[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] [Commented] (TS-1700) disable static libraries by default
[ https://issues.apache.org/jira/browse/TS-1700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13583062#comment-13583062 ] Igor Galić commented on TS-1700: I keep forgetting that we still support 32bit systems… Under Solaris we don't compile with -m32.. disable static libraries by default --- Key: TS-1700 URL: https://issues.apache.org/jira/browse/TS-1700 Project: Traffic Server Issue Type: Bug Components: Build Reporter: James Peach Assignee: James Peach Fix For: 3.3.1 Disable building static libraries by default. There's no upside to having static libraries and some potential to improve binary compatibility by removing them. -- 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-1486) drop solaris studio support
[ https://issues.apache.org/jira/browse/TS-1486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13583063#comment-13583063 ] Igor Galić commented on TS-1486: Perhaps I should be documenting here which changes it took.. [098b2f27081104da0c4e30a64e59c51fbe0bddfe|https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;a=commit;h=098b2f27081104da0c4e30a64e59c51fbe0bddfe] drop solaris studio support --- Key: TS-1486 URL: https://issues.apache.org/jira/browse/TS-1486 Project: Traffic Server Issue Type: Bug Components: Core, Portability Reporter: James Peach Assignee: Igor Galić Fix For: 3.3.3 We should drop Solaris Studio support for the 3.4 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] [Commented] (TS-1674) TSStatIntDecrement is broken
[ https://issues.apache.org/jira/browse/TS-1674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13583112#comment-13583112 ] Uri Shachar commented on TS-1674: - James -- You'd win your bet. I did the legwork on this and got the following results: 1) Switching to using global atomic variables *improves* performance by ~0.5% in ATS without plugins 2) In ATS with a simple plugin that does 20 increments/decrements of stat variables in 4 different hookpoints (80 calls total per transaction) I see a ~0.9% performance *degradation*. -- Once there are a lot of counters the memory barriers/collisions start to take a heavy toll I'll attach a patch for posterity, but considering these results I wouldn't recommend integrating it :-) TSStatIntDecrement is broken Key: TS-1674 URL: https://issues.apache.org/jira/browse/TS-1674 Project: Traffic Server Issue Type: Bug Components: TS API Reporter: Brian Geffon Assignee: Brian Geffon Fix For: 3.3.1 ATS keeps a thread-local copy of the stat value and aggregates it periodically and on demand when stats are being collected. However the decrement function doesn't let a value go negative. So in a thread that has not incremented this stat previously, the decrement call fails. This negative value check is logically flawed as it doesn't account for the per-thread distribution of the stats. -- 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-1674) TSStatIntDecrement is broken
[ https://issues.apache.org/jira/browse/TS-1674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uri Shachar updated TS-1674: Attachment: remove_per_thread_stats.patch Adding a patch that removes per-thread stats (it isn't very clean) TSStatIntDecrement is broken Key: TS-1674 URL: https://issues.apache.org/jira/browse/TS-1674 Project: Traffic Server Issue Type: Bug Components: TS API Reporter: Brian Geffon Assignee: Brian Geffon Fix For: 3.3.1 Attachments: remove_per_thread_stats.patch ATS keeps a thread-local copy of the stat value and aggregates it periodically and on demand when stats are being collected. However the decrement function doesn't let a value go negative. So in a thread that has not incremented this stat previously, the decrement call fails. This negative value check is logically flawed as it doesn't account for the per-thread distribution of the stats. -- 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-1718) iconv incorrectly recognized on Solaris
Igor Galić created TS-1718: -- Summary: iconv incorrectly recognized on Solaris Key: TS-1718 URL: https://issues.apache.org/jira/browse/TS-1718 Project: Traffic Server Issue Type: Bug Components: Build Reporter: Igor Galić A solaris system can have multiple installations of iconv (the most obvious being that of its {{libc}}). However, once {{configure}} has successfully identified an iconv, we don't really do anything with that information. Instead we try to replicate it (poorly) in our code. Here's an example from {{ink_string.cc}}: {code} #if !defined(kfreebsd) (defined(freebsd) || (!defined(__GNUC__) defined(solaris))) if (iconv(ic, in, inbytesleft, out, outbytesleft) == (size_t) - 1) #else if (iconv(ic, (char **) in, inbytesleft, out, outbytesleft) == (size_t) - 1) #endif {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-1715) Possibly range related crashing since upgrading to 3.2.4
[ https://issues.apache.org/jira/browse/TS-1715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Carlin updated TS-1715: - Description: This might be related to TS-1574 I upgraded one box to 3.2.4, and and I am experiencing the following crash approximately twice a day: Backtraces - the first happens more frequently: #0 RangeTransform::transform_to_range (this=0x2b40e40973d0) at Transform.cc:843 #1 0x004e52e8 in RangeTransform::handle_event (this=0x2b40e40973d0, event=value optimized out, edata=value optimized out) at Transform.cc:816 #2 0x006970f4 in handleEvent (this=0x2b40b9762010, e=0x2b40dc47f9e0, calling_code=1) at I_Continuation.h:146 #3 EThread::process_event (this=0x2b40b9762010, e=0x2b40dc47f9e0, calling_code=1) at UnixEThread.cc:142 #4 0x00697b6b in EThread::execute (this=0x2b40b9762010) at UnixEThread.cc:191 #5 0x006960c2 in spawn_thread_internal (a=0x15e04a0) at Thread.cc:88 #6 0x0031f8c07851 in start_thread () from /lib64/libpthread.so.0 #7 0x0031f88e76dd in clone () from /lib64/libc.so.6 #0 RangeTransform::transform_to_range (this=0x2b11441773f0) at Transform.cc:843 #1 0x004e52e8 in RangeTransform::handle_event (this=0x2b11441773f0, event=value optimized out, edata=value optimized out) at Transform.cc:816 #2 0x006970f4 in handleEvent (this=0x2b109f266010, e=0x2b110006f360, calling_code=1) at I_Continuation.h:146 #3 EThread::process_event (this=0x2b109f266010, e=0x2b110006f360, calling_code=1) at UnixEThread.cc:142 #4 0x00697b6b in EThread::execute (this=0x2b109f266010) at UnixEThread.cc:191 #5 0x004c28c9 in main (argc=value optimized out, argv=value optimized out) at Main.cc:1822 From /var/log/messages: Feb 16 11:43:26 l4 kernel: [ET_NET 18][16876]: segfault at 155 ip 00567571 sp 2b04d1412b40 error 4 in traffic_server[40+341000] From traffic.out: /home/y/bin/traffic_server - STACK TRACE: /lib64/libpthread.so.0[0x31f8c0f500] /home/y/bin/traffic_server(_ZN14RangeTransform18transform_to_rangeEv+0x83)[0x4e4b63] /home/y/bin/traffic_server(_ZN14RangeTransform12handle_eventEiPv+0x158)[0x4e52e8] /home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0xb4)[0x6970f4] /home/y/bin/traffic_server(_ZN7EThread7executeEv+0x5ab)[0x697b6b] /home/y/bin/traffic_server[0x6960c2] /lib64/libpthread.so.0[0x31f8c07851] /lib64/libc.so.6(clone+0x6d)[0x31f88e76dd] was: This might be related to TS-1574 I upgraded one box to 3.2.4, and and I am experiencing the following crash approximately twice a day: Backtraces - the first happens more frequently: #0 RangeTransform::transform_to_range (this=0x2b40e40973d0) at Transform.cc:843 #1 0x004e52e8 in RangeTransform::handle_event (this=0x2b40e40973d0, event=value optimized out, edata=value optimized out) at Transform.cc:816 #2 0x006970f4 in handleEvent (this=0x2b40b9762010, e=0x2b40dc47f9e0, calling_code=1) at I_Continuation.h:146 #3 EThread::process_event (this=0x2b40b9762010, e=0x2b40dc47f9e0, calling_code=1) at UnixEThread.cc:142 #4 0x00697b6b in EThread::execute (this=0x2b40b9762010) at UnixEThread.cc:191 #5 0x006960c2 in spawn_thread_internal (a=0x15e04a0) at Thread.cc:88 #6 0x0031f8c07851 in start_thread () from /lib64/libpthread.so.0 #7 0x0031f88e76dd in clone () from /lib64/libc.so.6 #0 RangeTransform::transform_to_range (this=0x2b11441773f0) at Transform.cc:843 #1 0x004e52e8 in RangeTransform::handle_event (this=0x2b11441773f0, event=value optimized out, edata=value optimized out) at Transform.cc:816 #2 0x006970f4 in handleEvent (this=0x2b109f266010, e=0x2b110006f360, calling_code=1) at I_Continuation.h:146 #3 EThread::process_event (this=0x2b109f266010, e=0x2b110006f360, calling_code=1) at UnixEThread.cc:142 #4 0x00697b6b in EThread::execute (this=0x2b109f266010) at UnixEThread.cc:191 #5 0x004c28c9 in main (argc=value optimized out, argv=value optimized out) at Main.cc:1822 From /var/log/messages: Feb 16 11:43:26 l4 kernel: [ET_NET 18][16876]: segfault at 155 ip 00567571 sp 2b04d1412b40 error 4 in traffic_server[40+341000] From traffic.out: NOTE: Traffic Server received Sig 11: Segmentation fault /home/y/bin/traffic_server - STACK TRACE: /lib64/libpthread.so.0[0x31f8c0f500] /home/y/bin/traffic_server(_ZN10HttpTunnel15chain_abort_allEP18HttpTunnelPr oducer+0xe1)[0x567571] /home/y/bin/traffic_server(_ZN6HttpSM17tunnel_handler_uaEiP18HttpTunnelCons umer+0x354)[0x5205b4] /home/y/bin/traffic_server(_ZN10HttpTunnel16consumer_handlerEiP18HttpTunnel Consumer+0x96)[0x56b716] /home/y/bin/traffic_server(_ZN10HttpTunnel12main_handlerEiPv+0x11d)[0x56bf6 d] /home/y/bin/traffic_server(_ZN6HttpSM28state_watch_for_client_abortEiPv+0x2 aa)[0x523d2a] /home/y/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0xe8)[0x52b2f8] /home/y/bin/traffic_server[0x672b5b]
[jira] [Commented] (TS-1717) static library build fails with duplicate symbols
[ https://issues.apache.org/jira/browse/TS-1717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13583383#comment-13583383 ] Igor Galić commented on TS-1717: Are you gonna, or should someone else pick it up? static library build fails with duplicate symbols - Key: TS-1717 URL: https://issues.apache.org/jira/browse/TS-1717 Project: Traffic Server Issue Type: Bug Components: Build Reporter: James Peach fish:trafficserver.git jpeach$ ./config.nice --disable-shared --enable-static make -j sudo make install ... CXXLDtraffic_manager AR libmgmt_p.a duplicate symbol _diags in: Main.o ../lib/ts/.libs/libtsutil.a(Diags.o) ld: 1 duplicate symbol for architecture x86_64 example/app-template/app-template.cc://Diags *diags = NULL; iocore/aio/test_AIO.i:Diags *diags; iocore/cluster/test_I_Cluster.cc:Diags *diags; iocore/cluster/test_P_Cluster.cc:Diags *diags; iocore/dns/test_I_DNS.cc:Diags *diags; iocore/dns/test_P_DNS.cc:Diags *diags; iocore/eventsystem/test_Buffer.cc:Diags *diags; iocore/eventsystem/test_Event.i:Diags *diags; iocore/hostdb/test_I_HostDB.cc:Diags *diags; iocore/hostdb/test_P_HostDB.cc:Diags *diags; iocore/net/test_I_Net.cc:Diags *diags; iocore/net/test_I_UDPNet.cc:Diags *diags; iocore/net/test_P_Net.cc:Diags *diags; iocore/net/test_P_UDPNet.cc:Diags *diags; iocore/utils/diags.i://Diags *diags; lib/records/I_RecCore.h:int RecSetDiags(Diags * diags); lib/records/I_RecLocal.h:int RecLocalInit(Diags * diags = NULL); lib/records/I_RecProcess.h:int RecProcessInit(RecModeT mode_type, Diags * diags = NULL); lib/records/P_RecCore.h:int RecCoreInit(RecModeT mode_type, Diags * diags); lib/records/RecCore.cc:Diags *g_diags = NULL; lib/records/RecCore.cc:RecCoreInit(RecModeT mode_type, Diags *_diags) lib/records/RecCore.cc:RecSetDiags(Diags * _diags) lib/records/RecLocal.cc:RecLocalInit(Diags * _diags) lib/records/RecProcess.cc:RecProcessInit(RecModeT mode_type, Diags *_diags) lib/records/RecUtils.cc:extern Diags *g_diags; lib/records/test_I_RecLocal.cc:Diags *diags = NULL; lib/records/test_RecProcess.i:Diags *diags = NULL; lib/ts/Diags.cc:inkcoreapi Diags *diags = NULL; lib/ts/Diags.h:extern inkcoreapi Diags *diags; mgmt/Main.cc:inkcoreapi Diags *diags; proxy/DiagsConfig.h: Diags *diags; proxy/Initialize.h:extern Diags *diags; proxy/Main.cc://inkcoreapi Diags *diags = NULL; proxy/hdrs/load_http_hdr.cc://Diags *diags; proxy/logging/LogStandalone.cc:Diags *diags = NULL; Additionally, AFAICT diags.i is not used and can be removed. -- 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-1674) TSStatIntDecrement is broken
[ https://issues.apache.org/jira/browse/TS-1674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13583396#comment-13583396 ] James Peach commented on TS-1674: - Thanks Uri! TSStatIntDecrement is broken Key: TS-1674 URL: https://issues.apache.org/jira/browse/TS-1674 Project: Traffic Server Issue Type: Bug Components: TS API Reporter: Brian Geffon Assignee: Brian Geffon Fix For: 3.3.1 Attachments: remove_per_thread_stats.patch ATS keeps a thread-local copy of the stat value and aggregates it periodically and on demand when stats are being collected. However the decrement function doesn't let a value go negative. So in a thread that has not incremented this stat previously, the decrement call fails. This negative value check is logically flawed as it doesn't account for the per-thread distribution of the stats. -- 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-1718) iconv incorrectly recognized on Solaris
[ https://issues.apache.org/jira/browse/TS-1718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13583566#comment-13583566 ] Igor Galić commented on TS-1718: Generally, yeah: But autoconf already knows that, our code doesn't. -- Sent from my phone. Please excuse my brevity. iconv incorrectly recognized on Solaris --- Key: TS-1718 URL: https://issues.apache.org/jira/browse/TS-1718 Project: Traffic Server Issue Type: Bug Components: Build Reporter: Igor Galić A solaris system can have multiple installations of iconv (the most obvious being that of its {{libc}}). However, once {{configure}} has successfully identified an iconv, we don't really do anything with that information. Instead we try to replicate it (poorly) in our code. Here's an example from {{ink_string.cc}}: {code} #if !defined(kfreebsd) (defined(freebsd) || (!defined(__GNUC__) defined(solaris))) if (iconv(ic, in, inbytesleft, out, outbytesleft) == (size_t) - 1) #else if (iconv(ic, (char **) in, inbytesleft, out, outbytesleft) == (size_t) - 1) #endif {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-1640) SSL certificate reconfiguration only works once
[ https://issues.apache.org/jira/browse/TS-1640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13583875#comment-13583875 ] jaekyung oh commented on TS-1640: - Hi James Peach. can i get patch or diff? i'm using 3.2.4 on OpenSuse. op team can't reload the new ssl config by traffic_line -x. SSL certificate reconfiguration only works once --- Key: TS-1640 URL: https://issues.apache.org/jira/browse/TS-1640 Project: Traffic Server Issue Type: Bug Components: Core, Management, SSL Reporter: James Peach Assignee: James Peach Fix For: 3.3.1 Using traffic_line -x to update the SSL certificate configuration only works the first time. This indicates a problem with the ConfigUpdateHandler 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