[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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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] [Assigned] (TS-1661) Cluster Communications fails without retries ..
[ https://issues.apache.org/jira/browse/TS-1661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zhao Yongming reassigned TS-1661: - Assignee: Bin Chen (was: Zhao Yongming) I'd not like that situation, let Bin Chen check this later Cluster Communications fails without retries .. --- Key: TS-1661 URL: https://issues.apache.org/jira/browse/TS-1661 Project: Traffic Server Issue Type: Bug Components: Clustering Reporter: Dow Buzzell Assignee: Bin Chen Fix For: sometime Attachments: dropped-packet.png, dropped-packet.png, refuse-reconnect.png It has been observed that once a lost packet is seen in the TCP cache calls to fetch a object from a member of the cache cluster, that the connection is fin'ed and refused reconnect attempts with resets .. Is this the expected behavior.. a private cache network with perfect delivery solves this problem, however, seems like this might help if the member would accept reconnect attempts. -- This message is automatically generated by JIRA. 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-1717) static library build fails with duplicate symbols
[ https://issues.apache.org/jira/browse/TS-1717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uri Shachar reassigned TS-1717: --- Assignee: Uri Shachar (was: James Peach) 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 Assignee: Uri Shachar Fix For: 3.3.2 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] [Updated] (TS-1717) static library build fails with duplicate symbols
[ https://issues.apache.org/jira/browse/TS-1717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uri Shachar updated TS-1717: Assignee: James Peach (was: Uri Shachar) 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 Assignee: James Peach Fix For: 3.3.2 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-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-tabpanelfocusedCommentId=13608928#comment-13608928 ] portl4t commented on TS-1751: - if not bound thread, will this increase cache miss ? 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-1759) encouter Sig 11 while enable cluster
[
https://issues.apache.org/jira/browse/TS-1759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13608958#comment-13608958
]
hu xiao commented on TS-1759:
-
With -O0, gdb trace:
(gdb) ptype
type = const class PtrProxyMutex {
public:
ProxyMutex *m_ptr;
void Ptr(ProxyMutex *);
void Ptr(const PtrProxyMutex );
~Ptr(int);
void clear();
PtrProxyMutex operator=(PtrProxyMutex const);
PtrProxyMutex operator=(ProxyMutex*);
ProxyMutex * to_ptr();
operator ProxyMutex*() const;
ProxyMutex * operator-() const;
ProxyMutex operator*() const;
int operator==(ProxyMutex const*);
int operator==(PtrProxyMutex const);
int operator!=(ProxyMutex const*);
int operator!=(PtrProxyMutex const);
RefCountObj * _ptr();
}
(gdb) bt
#0 0x004cb524 in PtrProxyMutex::operator= (this=0x845e49748,
src=@0x25d0) at Ptr.h:414
#1 0x006badde in UnixNetVConnection::do_io_write (this=0x845e495a0,
c=0x25b8, nbytes=0, reader=0x0, owner=false)
at UnixNetVConnection.cc:549
#2 0x00564927 in HttpServerSession::do_io_write (this=0x843b4bc60,
c=0x25b8, nbytes=0, buf=0x0, owner=false)
at HttpServerSession.cc:105
#3 0x00566429 in HttpSessionManager::release_session (this=0x9ecf60,
to_release=0x843b4bc60) at HttpSessionManager.cc:315
#4 0x00564b5d in HttpServerSession::release (this=0x843b4bc60) at
HttpServerSession.cc:173
#5 0x005733d3 in HttpSM::tunnel_handler_server (this=0x846ac2350,
event=102, p=0x846ac40d8) at HttpSM.cc:2893
#6 0x005affa7 in HttpTunnel::producer_handler (this=0x846ac3ee0,
event=102, p=0x846ac40d8) at HttpTunnel.cc:1161
#7 0x005b0104 in HttpTunnel::main_handler (this=0x846ac3ee0,
event=100, data=0x845e496a8) at HttpTunnel.cc:1477
#8 0x005b041d in chunked_reenable (p=0x846ac40d8, tunnel=0x846ac3ee0)
at HttpTunnel.cc:73
#9 0x005b05d7 in HttpTunnel::consumer_handler (this=0x846ac3ee0,
event=101, c=0x846ac3f88) at HttpTunnel.cc:1223
#10 0x005b0136 in HttpTunnel::main_handler (this=0x846ac3ee0,
event=101, data=0x846ff2320) at HttpTunnel.cc:1481
#11 0x004e696f in Continuation::handleEvent (this=0x846ac3ee0,
event=101, data=0x846ff2320) at I_Continuation.h:146
#12 0x0065b1cf in ClusterHandler::cluster_signal_and_update
(this=0x816ca5500, event=101, vc=0x846ff2240, s=0x846ff2318)
at ClusterHandlerBase.cc:594
#13 0x006542e6 in ClusterHandler::valid_for_data_write
(this=0x816ca5500, vc=0x846ff2240) at ClusterHandler.cc:2047
#14 0x0065467d in ClusterHandler::build_write_descriptors
(this=0x816ca5500) at ClusterHandler.cc:1602
#15 0x00654abc in ClusterHandler::process_write (this=0x816ca5500,
now=1363869982166845120, only_write_control_msgs=false)
at ClusterHandler.cc:2880
#16 0x00655545 in ClusterHandler::mainClusterEvent (this=0x816ca5500,
event=5, e=0x81c356f60) at ClusterHandler.cc:2507
#17 0x004e696f in Continuation::handleEvent (this=0x816ca5500, event=5,
data=0x81c356f60) at I_Continuation.h:146
#18 0x006c in EThread::process_event (this=0x843247000,
e=0x81c356f60, calling_code=5) at UnixEThread.cc:142
#19 0x006de27e in EThread::execute (this=0x843247000) at
UnixEThread.cc:266
#20 0x006dd729 in spawn_thread_internal (a=0x80512d070) at Thread.cc:88
#21 0x000800e1bd14 in pthread_getprio () from /lib/libthr.so.3
#22 0x in ?? ()
encouter Sig 11 while enable cluster
Key: TS-1759
URL: https://issues.apache.org/jira/browse/TS-1759
Project: Traffic Server
Issue Type: Bug
Components: Clustering
Reporter: hu xiao
I have two box running ATS and they are nomally when running separately.
But if enable cluster, they are random reboot, and have Sig 11 in
traffic.out.
The core.dump in gdb :
Core was generated by `traffic_server'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/local/trafficserver/lib/libtsutil.so.6...done.
Loaded symbols for /usr/local/trafficserver/lib/libtsutil.so.6
Reading symbols from /lib/libthr.so.3...done.
Loaded symbols for /lib/libthr.so.3
Reading symbols from /usr/lib/librt.so.1...done.
Loaded symbols for /usr/lib/librt.so.1
Reading symbols from /usr/local/lib/libpcre.so.3...done.
Loaded symbols for /usr/local/lib/libpcre.so.3
Reading symbols from /usr/lib/libssl.so.6...done.
Loaded symbols for /usr/lib/libssl.so.6
Reading symbols from /lib/libcrypto.so.6...done.
Loaded symbols for /lib/libcrypto.so.6
Reading symbols from /usr/local/lib/libtcl85.so.1...done.
Loaded symbols for /usr/local/lib/libtcl85.so.1
Reading symbols from /usr/local/lib/libexpat.so.6...done.
Loaded symbols for /usr/local/lib/libexpat.so.6
Reading symbols from
[jira] [Commented] (TS-1635) url parse BUGS IN Apache Traffic Sever 3.3.1
[ https://issues.apache.org/jira/browse/TS-1635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13608967#comment-13608967 ] Alan M. Carroll commented on TS-1635: - I understand the problem here. It is in fact a logging issue, the same one that leads to host names being lost during logging. In this case, however, it finds another URL and logs that. I'll try to work on this today. url parse BUGS IN Apache Traffic Sever 3.3.1 - Key: TS-1635 URL: https://issues.apache.org/jira/browse/TS-1635 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: evilbandon Assignee: weijin Fix For: 3.3.3 url parse BUGS IN Apache Traffic Sever 3.3.1 the request URL is http://a.b.com/xx.jpg?newpath=http://b.c.com but the Apache Traffic Sever 3.3.1 parse this url as http://b.c.com -- This message is automatically generated by JIRA. 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-1635) url parse BUGS IN Apache Traffic Sever 3.3.1
[ https://issues.apache.org/jira/browse/TS-1635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13608977#comment-13608977 ] evilbandon commented on TS-1635: hi Alan M. Carroll ,weijin it is not only affect the logging, but also make remap incorrect. 贝奇小天狼星's patch can fix it url parse BUGS IN Apache Traffic Sever 3.3.1 - Key: TS-1635 URL: https://issues.apache.org/jira/browse/TS-1635 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: evilbandon Assignee: weijin Fix For: 3.3.3 url parse BUGS IN Apache Traffic Sever 3.3.1 the request URL is http://a.b.com/xx.jpg?newpath=http://b.c.com but the Apache Traffic Sever 3.3.1 parse this url as http://b.c.com -- This message is automatically generated by JIRA. 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-1546) endless loop in unmashual may cause throttling
[ https://issues.apache.org/jira/browse/TS-1546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13609044#comment-13609044 ] weijin commented on TS-1546: after dig it more, we found the root cause of the endless loop is the cache was polluted. So I think maybe we can close it now. endless loop in unmashual may cause throttling -- Key: TS-1546 URL: https://issues.apache.org/jira/browse/TS-1546 Project: Traffic Server Issue Type: Sub-task Components: Cache, HTTP Affects Versions: 3.3.0 Reporter: Zhao Yongming Assignee: weijin Fix For: 3.3.2 we get a thread looping in the HdrHeap::unmarshal, while m_length is 0. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1546) endless loop in unmarshal may cause throttling
[ https://issues.apache.org/jira/browse/TS-1546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-1546: Summary: endless loop in unmarshal may cause throttling (was: endless loop in unmashual may cause throttling) endless loop in unmarshal may cause throttling -- Key: TS-1546 URL: https://issues.apache.org/jira/browse/TS-1546 Project: Traffic Server Issue Type: Sub-task Components: Cache, HTTP Affects Versions: 3.3.0 Reporter: Zhao Yongming Assignee: weijin Fix For: 3.3.2 we get a thread looping in the HdrHeap::unmarshal, while m_length is 0. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1546) endless loop in unmarshal may cause throttling
[ https://issues.apache.org/jira/browse/TS-1546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1546: -- Fix Version/s: (was: 3.3.2) endless loop in unmarshal may cause throttling -- Key: TS-1546 URL: https://issues.apache.org/jira/browse/TS-1546 Project: Traffic Server Issue Type: Sub-task Components: Cache, HTTP Affects Versions: 3.3.0 Reporter: Zhao Yongming Assignee: weijin we get a thread looping in the HdrHeap::unmarshal, while m_length is 0. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-1546) endless loop in unmarshal may cause throttling
[ https://issues.apache.org/jira/browse/TS-1546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-1546. --- Resolution: Invalid endless loop in unmarshal may cause throttling -- Key: TS-1546 URL: https://issues.apache.org/jira/browse/TS-1546 Project: Traffic Server Issue Type: Sub-task Components: Cache, HTTP Affects Versions: 3.3.0 Reporter: Zhao Yongming Assignee: weijin we get a thread looping in the HdrHeap::unmarshal, while m_length is 0. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1405) apply time-wheel scheduler about event system
[ https://issues.apache.org/jira/browse/TS-1405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13609122#comment-13609122 ] John Plevyak commented on TS-1405: -- Why is it segfaulting? Can we backout the commit(s) which which caused the 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-1746) Crash report: UnixNetVConnection::reenable ink_atomiclist_push ink_atomic_cas
[
https://issues.apache.org/jira/browse/TS-1746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13609166#comment-13609166
]
ASF subversion and git services commented on TS-1746:
-
Commit bd8fd4fbb5ee4026f107365bcab6d546fc855f83 in branch refs/heads/master
from James Peach jpe...@apache.org
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=bd8fd4f ]
TS-1746: disable 128bit compare and swap
Disable the use of 128bit compare and swap that was introduced in
TS-1742. That change was causing crashes in the freelist.
Crash report: UnixNetVConnection::reenable ink_atomiclist_push
ink_atomic_cas
--
Key: TS-1746
URL: https://issues.apache.org/jira/browse/TS-1746
Project: Traffic Server
Issue Type: Bug
Components: Core
Reporter: Zhao Yongming
Assignee: Brian Geffon
I think the recent changes cause this crash, and here is the stack trace:
{code}
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x72492700 (LWP 23610)]
0x77bb30a5 in ink_atomic_cas__int128 (mem=0x73cae288,
prev=0x0001,
next=0x7fffd4014501)
at ink_atomic.h:153
153 return __sync_bool_compare_and_swap(mem, prev, next);
(gdb) bt
#0 0x77bb30a5 in ink_atomic_cas__int128 (mem=0x73cae288,
prev=0x0001,
next=0x7fffd4014501)
at ink_atomic.h:153
#1 0x77bb2e29 in ink_atomiclist_push (l=0x73cae288,
item=0x7fffd4014500) at ink_queue.cc:481
#2 0x006d8961 in AtomicSLLUnixNetVConnection,
UnixNetVConnection::Link_read_enable_link::push (this=0x73cae288,
c=0x7fffd4014500)
at ../../lib/ts/List.h:477
#3 0x006d6767 in UnixNetVConnection::reenable (this=0x7fffd4014500,
vio=0x7fffd4014610) at UnixNetVConnection.cc:721
#4 0x005195d5 in VIO::reenable (this=0x7fffd4014610) at
../iocore/eventsystem/P_VIO.h:124
#5 0x005c73b1 in HttpTunnel::consumer_handler (this=0x7fffdbefb888,
event=101, c=0x7fffdbefb8c8) at HttpTunnel.cc:1237
#6 0x005c7c1f in HttpTunnel::main_handler (this=0x7fffdbefb888,
event=101, data=0x7fffc4008870) at HttpTunnel.cc:1481
#7 0x004f8aa6 in Continuation::handleEvent (this=0x7fffdbefb888,
event=101, data=0x7fffc4008870) at ../iocore/eventsystem/I_Continuation.h:146
#8 0x0050a612 in TSContCall (contp=0x7fffdbefb888,
event=TS_EVENT_VCONN_WRITE_READY, edata=0x7fffc4008870) at InkAPI.cc:4400
#9 0x0055f302 in handle_transform (contp=0x7fffc40087c0) at
InkAPITest.cc:6435
#10 0x0055f4be in transformtest_transform (contp=0x7fffc40087c0,
event=TS_EVENT_IMMEDIATE, edata=0x1166920) at InkAPITest.cc:6501
#11 0x00501922 in INKVConnInternal::handle_event
(this=0x7fffc40087c0, event=1, edata=0x1166920) at InkAPI.cc:1045
#12 0x004f8aa6 in Continuation::handleEvent (this=0x7fffc40087c0,
event=1, data=0x1166920) at ../iocore/eventsystem/I_Continuation.h:146
#13 0x006f823d in EThread::process_event (this=0x73aa9010,
e=0x1166920, calling_code=1) at UnixEThread.cc:142
#14 0x006f8491 in EThread::execute (this=0x73aa9010) at
UnixEThread.cc:193
#15 0x006f744c in spawn_thread_internal (a=0x1090810) at Thread.cc:88
#16 0x7793dea7 in start_thread () from /lib64/libpthread.so.0
#17 0x751c114d in clone () from /lib64/libc.so.6
(gdb) l
148 // ink_atomic_cas(mem, prev, next)
149 // Atomically store the value @next into the pointer @mem, but only
if the current value at @mem is @prev.
150 // Returns true if @next was successfully stored.
151 template typename T static inline bool
152 ink_atomic_cas(volatile T * mem, T prev, T next) {
153 return __sync_bool_compare_and_swap(mem, prev, next);
154 }
155
156 // ink_atomic_increment(ptr, count)
157 // Increment @ptr by @count, returning the previous value.
(gdb) f 1
#1 0x77bb2e29 in ink_atomiclist_push (l=0x73cae288,
item=0x7fffd4014500) at ink_queue.cc:481
481result = ink_atomic_cas((__int128_t*) l-head, head.data,
item_pair.data);
(gdb) p head.data
$1 = 0x0001
(gdb) p head
$2 = {s = {pointer = 0x1, version = 0}, data =
0x0001}
(gdb)
{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-1746) Crash report: UnixNetVConnection::reenable ink_atomiclist_push ink_atomic_cas
[
https://issues.apache.org/jira/browse/TS-1746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach updated TS-1746:
Fix Version/s: 3.3.2
Crash report: UnixNetVConnection::reenable ink_atomiclist_push
ink_atomic_cas
--
Key: TS-1746
URL: https://issues.apache.org/jira/browse/TS-1746
Project: Traffic Server
Issue Type: Bug
Components: Core
Reporter: Zhao Yongming
Assignee: Brian Geffon
Fix For: 3.3.2
I think the recent changes cause this crash, and here is the stack trace:
{code}
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x72492700 (LWP 23610)]
0x77bb30a5 in ink_atomic_cas__int128 (mem=0x73cae288,
prev=0x0001,
next=0x7fffd4014501)
at ink_atomic.h:153
153 return __sync_bool_compare_and_swap(mem, prev, next);
(gdb) bt
#0 0x77bb30a5 in ink_atomic_cas__int128 (mem=0x73cae288,
prev=0x0001,
next=0x7fffd4014501)
at ink_atomic.h:153
#1 0x77bb2e29 in ink_atomiclist_push (l=0x73cae288,
item=0x7fffd4014500) at ink_queue.cc:481
#2 0x006d8961 in AtomicSLLUnixNetVConnection,
UnixNetVConnection::Link_read_enable_link::push (this=0x73cae288,
c=0x7fffd4014500)
at ../../lib/ts/List.h:477
#3 0x006d6767 in UnixNetVConnection::reenable (this=0x7fffd4014500,
vio=0x7fffd4014610) at UnixNetVConnection.cc:721
#4 0x005195d5 in VIO::reenable (this=0x7fffd4014610) at
../iocore/eventsystem/P_VIO.h:124
#5 0x005c73b1 in HttpTunnel::consumer_handler (this=0x7fffdbefb888,
event=101, c=0x7fffdbefb8c8) at HttpTunnel.cc:1237
#6 0x005c7c1f in HttpTunnel::main_handler (this=0x7fffdbefb888,
event=101, data=0x7fffc4008870) at HttpTunnel.cc:1481
#7 0x004f8aa6 in Continuation::handleEvent (this=0x7fffdbefb888,
event=101, data=0x7fffc4008870) at ../iocore/eventsystem/I_Continuation.h:146
#8 0x0050a612 in TSContCall (contp=0x7fffdbefb888,
event=TS_EVENT_VCONN_WRITE_READY, edata=0x7fffc4008870) at InkAPI.cc:4400
#9 0x0055f302 in handle_transform (contp=0x7fffc40087c0) at
InkAPITest.cc:6435
#10 0x0055f4be in transformtest_transform (contp=0x7fffc40087c0,
event=TS_EVENT_IMMEDIATE, edata=0x1166920) at InkAPITest.cc:6501
#11 0x00501922 in INKVConnInternal::handle_event
(this=0x7fffc40087c0, event=1, edata=0x1166920) at InkAPI.cc:1045
#12 0x004f8aa6 in Continuation::handleEvent (this=0x7fffc40087c0,
event=1, data=0x1166920) at ../iocore/eventsystem/I_Continuation.h:146
#13 0x006f823d in EThread::process_event (this=0x73aa9010,
e=0x1166920, calling_code=1) at UnixEThread.cc:142
#14 0x006f8491 in EThread::execute (this=0x73aa9010) at
UnixEThread.cc:193
#15 0x006f744c in spawn_thread_internal (a=0x1090810) at Thread.cc:88
#16 0x7793dea7 in start_thread () from /lib64/libpthread.so.0
#17 0x751c114d in clone () from /lib64/libc.so.6
(gdb) l
148 // ink_atomic_cas(mem, prev, next)
149 // Atomically store the value @next into the pointer @mem, but only
if the current value at @mem is @prev.
150 // Returns true if @next was successfully stored.
151 template typename T static inline bool
152 ink_atomic_cas(volatile T * mem, T prev, T next) {
153 return __sync_bool_compare_and_swap(mem, prev, next);
154 }
155
156 // ink_atomic_increment(ptr, count)
157 // Increment @ptr by @count, returning the previous value.
(gdb) f 1
#1 0x77bb2e29 in ink_atomiclist_push (l=0x73cae288,
item=0x7fffd4014500) at ink_queue.cc:481
481result = ink_atomic_cas((__int128_t*) l-head, head.data,
item_pair.data);
(gdb) p head.data
$1 = 0x0001
(gdb) p head
$2 = {s = {pointer = 0x1, version = 0}, data =
0x0001}
(gdb)
{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-tabpanelfocusedCommentId=13609204#comment-13609204 ] James Peach commented on TS-1405: - I just disabled TS-1742, which was causing freelist segfaults. 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-1742) Freelists to use 64bit version w/ Double Word Compare and Swap
[
https://issues.apache.org/jira/browse/TS-1742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13609244#comment-13609244
]
ASF subversion and git services commented on TS-1742:
-
Commit ae085945184c43195d825a6be72a259b84d9df33 in branch refs/heads/master
from weijin taorui...@taobao.com
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=ae08594 ]
TS-1742 just make the regression test passed if cas128 enabled
Freelists to use 64bit version w/ Double Word Compare and Swap
--
Key: TS-1742
URL: https://issues.apache.org/jira/browse/TS-1742
Project: Traffic Server
Issue Type: Improvement
Reporter: Brian Geffon
Assignee: Brian Geffon
Fix For: 3.3.2
Attachments: 128bit_cas.patch, 128bit_cas.patch.2
So to those of you familiar with the freelists you know that it works this
way the head pointer uses the upper 16 bits for a version to prevent the ABA
problem. The big drawback to this is that it requires the following macros to
get at the pointer or the version:
{code}
#define FREELIST_POINTER(_x) ((void*)(intptr_t)(_x).data)16)16) | \
(((~intptr_t)(_x).data)1663)-1))48)48))) // sign extend
#define FREELIST_VERSION(_x) (((intptr_t)(_x).data)48)
#define SET_FREELIST_POINTER_VERSION(_x,_p,_v) \
(_x).data = intptr_t)(_p))0xULL) | (((_v)0xULL)
48))
{code}
Additionally, since this only leaves 16 bits it limits the number of versions
you can have, well more and more x86_64 processors support DCAS (double word
compare and swap / 128bit CAS). This means that we can use 64bits for a
version which basically makes the versions unlimited but more importantly it
takes those macros above and simplifies them to:
{code}
#define FREELIST_POINTER(_x) (_x).s.pointer
#define FREELIST_VERSION(_x) (_x).s.version
#define SET_FREELIST_POINTER_VERSION(_x,_p,_v) \
(_x).s.pointer = _p; (_x).s.version = _v
{code}
As you can imagine this will have a performance improvement, in my simple
tests I measured a performance improvement of around 6%. Unfortunately, I'm
not an expert with this stuff and I would really appreciate more community
feedback before I commit this patch.
Note: this only applies if you're not using a reclaimable freelist.
--
This message is automatically generated by JIRA.
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-1735) reclaimable freelist causes core in osx
[ https://issues.apache.org/jira/browse/TS-1735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13609331#comment-13609331 ] ASF subversion and git services commented on TS-1735: - Commit dbf7124a945f38204b0548b1d2fdc54f51ed84ce in branch refs/heads/master from [~john.v.kew...@gmail.com] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=dbf7124 ] TS-1735: Remove dead code that invokes missing vmap_config tool Virtual IPs were once managed such that within a cluster they would automatically rebalance themselves between nodes by bringing subinterfaces up and down. After ATS was open sourced the original setuid tool, vip_config (or traffic_vip_config) was inadvertently removed; but the code which depended on this tool was not cleaned up. Since modern deployments either do not use this tool at all (because it was broken for a few years) and modern deployments also have some central system for managing cluster state reliably, we do not need VMap to implement some scheme for automatically rebalancing the ips. This patch keeps much of the code for detecting ip address conflicts and for receiving the multicast messages from the cluster; but we remove all instances where we either bring up/down an interface. Deployments should manage this through external state systems. Note: VIPs do not actually bind to the specific addresses in vaddrs; this is just an operations convience to ensure that a cluster has no ip conflicts or unmanaged vips. This feature becomes even less useful. LocalManager.cc would have to be modified in some way to set this up properly. reclaimable freelist causes core in osx --- Key: TS-1735 URL: https://issues.apache.org/jira/browse/TS-1735 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Bryan Call Fix For: 3.3.2 Attachments: 0001-TS-1735-fix-initialization-of-_g_mattr.attr-V2.patch Global variable dependency and ininitialtion order can cause reclaimable freelist to core. Reclaimable freelist depends on a global mutex attribute. (gdb) bt #0 0x7fff8fa17d46 in __kill () #1 0x7fff84824df0 in abort () #2 0x0001009ce697 in reclaimable_freelist_init (fl=value temporarily unavailable, due to optimizations, name=value temporarily unavailable, due to optimizations, type_size=value temporarily unavailable, due to optimizations, chunk_size=value temporarily unavailable, due to optimizations, alignment=value temporarily unavailable, due to optimizations) at ink_mutex.h:80 #3 0x7fff5fc13378 in __dyld__ZN16ImageLoaderMachO18doModInitFunctionsERKN11ImageLoader11LinkContextE () #4 0x7fff5fc13762 in __dyld__ZN16ImageLoaderMachO16doInitializationERKN11ImageLoader11LinkContextE () #5 0x7fff5fc1006e in __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEjRNS_21InitializerTimingListE () #6 0x7fff5fc0ffc4 in __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEjRNS_21InitializerTimingListE () #7 0x7fff5fc0feba in __dyld__ZN11ImageLoader15runInitializersERKNS_11LinkContextERNS_21InitializerTimingListE () #8 0x7fff5fc01fc0 in __dyld__ZN4dyld24initializeMainExecutableEv () #9 0x7fff5fc05b04 in __dyld__ZN4dyld5_mainEPK12macho_headermiPPKcS5_S5_Pm () #10 0x7fff5fc01397 in __dyld__ZN13dyldbootstrap5startEPK12macho_headeriPPKclS2_Pm () #11 0x7fff5fc0105e in __dyld__dyld_start () -- This message is automatically generated by JIRA. 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-1734) VMap functionality is missing a the vmap_config tool for bringing ip addresses up and down; but appears to be largely dead code
[ https://issues.apache.org/jira/browse/TS-1734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13609339#comment-13609339 ] ASF subversion and git services commented on TS-1734: - Commit 1a2ebccb112987acf450a5d678b6185c5d98257f in branch refs/heads/master from James Peach jpe...@apache.org [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=1a2ebcc ] TS-1734: fix wrong jira number VMap functionality is missing a the vmap_config tool for bringing ip addresses up and down; but appears to be largely dead code --- Key: TS-1734 URL: https://issues.apache.org/jira/browse/TS-1734 Project: Traffic Server Issue Type: Bug Components: Management Affects Versions: 3.3.4, 3.3.0, 3.2.4 Reporter: John Kew Assignee: Igor Galić Fix For: 3.3.2 Attachments: remove_vip_rebalance.patch Virtual IPs were once managed such that within a cluster they would automatically rebalance themselves between nodes by bringing subinterfaces up and down. After ATS was open sourced the original setuid tool, vip_config (or traffic_vip_config) was inadvertently removed; but the code which depended on this tool was not cleaned up. Since modern deployments either do not use this tool at all (because it was broken for a few years) and modern deployments also have some central system for managing cluster state reliably, we do not need VMap to implement some scheme for automatically rebalancing the ips. This patch keeps much of the code for detecting ip address conflicts and for receiving the multicast messages from the cluster; but we remove all instances where we either bring up/down an interface. Deployments should manage this through external state systems. Note: VIPs do not actually bind to the specific addresses in vaddrs; this is just an operations convience to ensure that a cluster has no ip conflicts or unmanaged vips. This feature becomes even less useful. LocalManager.cc would have to be modified in some way to set this up properly. Note: The *right* thing to do here may be to recall that old tool and let VMap do it's thing. Note: Another *right* thing to do may be to remove VMap entirely, along with the associated cluster messages. At least with this exiting changeset we can detect ip address conflicts. -- This message is automatically generated by JIRA. 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-1734) VMap functionality is missing a the vmap_config tool for bringing ip addresses up and down; but appears to be largely dead code
[ https://issues.apache.org/jira/browse/TS-1734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13609341#comment-13609341 ] James Peach commented on TS-1734: - Commit dbf7124a945f38204b0548b1d2fdc54f51ed84ce in branch refs/heads/master from John Kew [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=dbf7124 ] (commit was mis-labeled for TS-1735 ... sign) VMap functionality is missing a the vmap_config tool for bringing ip addresses up and down; but appears to be largely dead code --- Key: TS-1734 URL: https://issues.apache.org/jira/browse/TS-1734 Project: Traffic Server Issue Type: Bug Components: Management Affects Versions: 3.3.4, 3.3.0, 3.2.4 Reporter: John Kew Assignee: Igor Galić Fix For: 3.3.2 Attachments: remove_vip_rebalance.patch Virtual IPs were once managed such that within a cluster they would automatically rebalance themselves between nodes by bringing subinterfaces up and down. After ATS was open sourced the original setuid tool, vip_config (or traffic_vip_config) was inadvertently removed; but the code which depended on this tool was not cleaned up. Since modern deployments either do not use this tool at all (because it was broken for a few years) and modern deployments also have some central system for managing cluster state reliably, we do not need VMap to implement some scheme for automatically rebalancing the ips. This patch keeps much of the code for detecting ip address conflicts and for receiving the multicast messages from the cluster; but we remove all instances where we either bring up/down an interface. Deployments should manage this through external state systems. Note: VIPs do not actually bind to the specific addresses in vaddrs; this is just an operations convience to ensure that a cluster has no ip conflicts or unmanaged vips. This feature becomes even less useful. LocalManager.cc would have to be modified in some way to set this up properly. Note: The *right* thing to do here may be to recall that old tool and let VMap do it's thing. Note: Another *right* thing to do may be to remove VMap entirely, along with the associated cluster messages. At least with this exiting changeset we can detect ip address conflicts. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Deleted] (TS-1735) reclaimable freelist causes core in osx
[ https://issues.apache.org/jira/browse/TS-1735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-1735: Comment: was deleted (was: Commit dbf7124a945f38204b0548b1d2fdc54f51ed84ce in branch refs/heads/master from [~john.v.kew...@gmail.com] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=dbf7124 ] TS-1735: Remove dead code that invokes missing vmap_config tool Virtual IPs were once managed such that within a cluster they would automatically rebalance themselves between nodes by bringing subinterfaces up and down. After ATS was open sourced the original setuid tool, vip_config (or traffic_vip_config) was inadvertently removed; but the code which depended on this tool was not cleaned up. Since modern deployments either do not use this tool at all (because it was broken for a few years) and modern deployments also have some central system for managing cluster state reliably, we do not need VMap to implement some scheme for automatically rebalancing the ips. This patch keeps much of the code for detecting ip address conflicts and for receiving the multicast messages from the cluster; but we remove all instances where we either bring up/down an interface. Deployments should manage this through external state systems. Note: VIPs do not actually bind to the specific addresses in vaddrs; this is just an operations convience to ensure that a cluster has no ip conflicts or unmanaged vips. This feature becomes even less useful. LocalManager.cc would have to be modified in some way to set this up properly. ) reclaimable freelist causes core in osx --- Key: TS-1735 URL: https://issues.apache.org/jira/browse/TS-1735 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Bryan Call Fix For: 3.3.2 Attachments: 0001-TS-1735-fix-initialization-of-_g_mattr.attr-V2.patch Global variable dependency and ininitialtion order can cause reclaimable freelist to core. Reclaimable freelist depends on a global mutex attribute. (gdb) bt #0 0x7fff8fa17d46 in __kill () #1 0x7fff84824df0 in abort () #2 0x0001009ce697 in reclaimable_freelist_init (fl=value temporarily unavailable, due to optimizations, name=value temporarily unavailable, due to optimizations, type_size=value temporarily unavailable, due to optimizations, chunk_size=value temporarily unavailable, due to optimizations, alignment=value temporarily unavailable, due to optimizations) at ink_mutex.h:80 #3 0x7fff5fc13378 in __dyld__ZN16ImageLoaderMachO18doModInitFunctionsERKN11ImageLoader11LinkContextE () #4 0x7fff5fc13762 in __dyld__ZN16ImageLoaderMachO16doInitializationERKN11ImageLoader11LinkContextE () #5 0x7fff5fc1006e in __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEjRNS_21InitializerTimingListE () #6 0x7fff5fc0ffc4 in __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEjRNS_21InitializerTimingListE () #7 0x7fff5fc0feba in __dyld__ZN11ImageLoader15runInitializersERKNS_11LinkContextERNS_21InitializerTimingListE () #8 0x7fff5fc01fc0 in __dyld__ZN4dyld24initializeMainExecutableEv () #9 0x7fff5fc05b04 in __dyld__ZN4dyld5_mainEPK12macho_headermiPPKcS5_S5_Pm () #10 0x7fff5fc01397 in __dyld__ZN13dyldbootstrap5startEPK12macho_headeriPPKclS2_Pm () #11 0x7fff5fc0105e in __dyld__dyld_start () -- This message is automatically generated by JIRA. 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-1742) Freelists to use 64bit version w/ Double Word Compare and Swap
[
https://issues.apache.org/jira/browse/TS-1742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13609346#comment-13609346
]
Brian Geffon commented on TS-1742:
--
Thanks for the help on this one everyone, I'm going to keep hacking away at
this on the precise64 vagrant box until I can figure out what's going on then
we'll try it again.
Freelists to use 64bit version w/ Double Word Compare and Swap
--
Key: TS-1742
URL: https://issues.apache.org/jira/browse/TS-1742
Project: Traffic Server
Issue Type: Improvement
Reporter: Brian Geffon
Assignee: Brian Geffon
Fix For: 3.3.2
Attachments: 128bit_cas.patch, 128bit_cas.patch.2
So to those of you familiar with the freelists you know that it works this
way the head pointer uses the upper 16 bits for a version to prevent the ABA
problem. The big drawback to this is that it requires the following macros to
get at the pointer or the version:
{code}
#define FREELIST_POINTER(_x) ((void*)(intptr_t)(_x).data)16)16) | \
(((~intptr_t)(_x).data)1663)-1))48)48))) // sign extend
#define FREELIST_VERSION(_x) (((intptr_t)(_x).data)48)
#define SET_FREELIST_POINTER_VERSION(_x,_p,_v) \
(_x).data = intptr_t)(_p))0xULL) | (((_v)0xULL)
48))
{code}
Additionally, since this only leaves 16 bits it limits the number of versions
you can have, well more and more x86_64 processors support DCAS (double word
compare and swap / 128bit CAS). This means that we can use 64bits for a
version which basically makes the versions unlimited but more importantly it
takes those macros above and simplifies them to:
{code}
#define FREELIST_POINTER(_x) (_x).s.pointer
#define FREELIST_VERSION(_x) (_x).s.version
#define SET_FREELIST_POINTER_VERSION(_x,_p,_v) \
(_x).s.pointer = _p; (_x).s.version = _v
{code}
As you can imagine this will have a performance improvement, in my simple
tests I measured a performance improvement of around 6%. Unfortunately, I'm
not an expert with this stuff and I would really appreciate more community
feedback before I commit this patch.
Note: this only applies if you're not using a reclaimable freelist.
--
This message is automatically generated by JIRA.
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-1767) Cache Lookup Regex using incorrect urls
[ https://issues.apache.org/jira/browse/TS-1767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13609521#comment-13609521 ] Scott Harris commented on TS-1767: -- thanks for the suggestion, which works, but I have some sites that require the original host header to be passed through. Cache Lookup Regex using incorrect urls --- Key: TS-1767 URL: https://issues.apache.org/jira/browse/TS-1767 Project: Traffic Server Issue Type: Bug Components: Web UI Reporter: Scott Harris When using the cache regex lookup returned urls contain origin server not of incoming mapping to ats. Ie using map http://incoming http://10.1.1.1:8080 returned regex urls are : http://10.1.1.1:8080/blah instead of http://incoming/blah Selecting any of these results in Cache Lookup Failed, or missing in cluster Doing url lookup with incoming url returns valid result. Using version 3.2.4 running as a reverse proxy -- This message is automatically generated by JIRA. 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-1721) tstop Makefile not generated
[ https://issues.apache.org/jira/browse/TS-1721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13609682#comment-13609682 ] James Peach commented on TS-1721: - I have a patch awaiting approval. tstop Makefile not generated Key: TS-1721 URL: https://issues.apache.org/jira/browse/TS-1721 Project: Traffic Server Issue Type: Bug Components: Build Reporter: Phil Sorber Assignee: James Peach Fix For: 3.3.2 Summary says it all -- This message is automatically generated by JIRA. 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-1125) POST's with Expect: 100-continue are slowed by delayed 100 response.
[ https://issues.apache.org/jira/browse/TS-1125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13609817#comment-13609817 ] William Bardwell commented on TS-1125: -- I haven't worked on this. POST's with Expect: 100-continue are slowed by delayed 100 response. Key: TS-1125 URL: https://issues.apache.org/jira/browse/TS-1125 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 3.0.2 Environment: TS 3.0.2 going to Apache 2.2 web server Reporter: William Bardwell Priority: Minor Fix For: 3.3.3 Sending a post like: POST / HTTP/1.1 Host: www.example.com Content-Length: 10 Expect: 100-continue directly to the web server immediately sends back: HTTP/1.1 100 Continue And then when the post data is sent, a status 200 response comes back. But when going through ATS the HTTP/1.1 100 Continue is not sent immediately, and instead is sent after the POST data has been received. This is legal, but it makes clients that are hoping for a 100 continue to wait a little while hoping to get that, ATS should forward that response through immediately. Note: I see curl using Expect: 100-continue with 1024 bytes of post data, but web searching indicates that some Microsoft products also use it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
