[jira] [Updated] (TS-1898) improve cluster read/write performance
[ https://issues.apache.org/jira/browse/TS-1898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen updated TS-1898: - Attachment: TS-1898_v2.patch rebase on master improve cluster read/write performance -- Key: TS-1898 URL: https://issues.apache.org/jira/browse/TS-1898 Project: Traffic Server Issue Type: Improvement Components: Cache, Clustering Affects Versions: 3.3.2 Reporter: Zhao Yongming Assignee: Bin Chen Fix For: 3.5.0 Attachments: TS-1898.patch, TS-1898_v2.patch we find out that cluster read and write performace is very poor, and even worse whe the conten is 2MB larger, we should improve that. a typical testing of 10MB file in cluster is about 10+s we have a patch that will improve to 300-800ms, all testing in local network -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1898) improve cluster read/write performance
[ https://issues.apache.org/jira/browse/TS-1898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13710814#comment-13710814 ] ASF subversion and git services commented on TS-1898: - Commit 3c0d910dd7d67ab8878ae8fac8a5c998e279753d in branch refs/heads/master from [~chenbing] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=3c0d910 ] TS-1898: improve cluster read/write performance improve cluster read/write performance -- Key: TS-1898 URL: https://issues.apache.org/jira/browse/TS-1898 Project: Traffic Server Issue Type: Improvement Components: Cache, Clustering Affects Versions: 3.3.2 Reporter: Zhao Yongming Assignee: Bin Chen Fix For: 3.5.0 Attachments: TS-1898.patch, TS-1898_v2.patch we find out that cluster read and write performace is very poor, and even worse whe the conten is 2MB larger, we should improve that. a typical testing of 10MB file in cluster is about 10+s we have a patch that will improve to 300-800ms, all testing in local network -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1898) improve cluster read/write performance
[ https://issues.apache.org/jira/browse/TS-1898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13710818#comment-13710818 ] ASF subversion and git services commented on TS-1898: - Commit 3af64e48fcc6efaa08e1e9915b4e968feba13076 in branch refs/heads/master from [~kuotai] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=3af64e4 ] update CHANGES about TS-1898 improve cluster read/write performance -- Key: TS-1898 URL: https://issues.apache.org/jira/browse/TS-1898 Project: Traffic Server Issue Type: Improvement Components: Cache, Clustering Affects Versions: 3.3.2 Reporter: Zhao Yongming Assignee: Bin Chen Fix For: 3.5.0 Attachments: TS-1898.patch, TS-1898_v2.patch we find out that cluster read and write performace is very poor, and even worse whe the conten is 2MB larger, we should improve that. a typical testing of 10MB file in cluster is about 10+s we have a patch that will improve to 300-800ms, all testing in local network -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TS-1898) improve cluster read/write performance
[ https://issues.apache.org/jira/browse/TS-1898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen closed TS-1898. Resolution: Fixed improve cluster read/write performance -- Key: TS-1898 URL: https://issues.apache.org/jira/browse/TS-1898 Project: Traffic Server Issue Type: Improvement Components: Cache, Clustering Affects Versions: 3.3.2 Reporter: Zhao Yongming Assignee: Bin Chen Fix For: 3.5.0 Attachments: TS-1898.patch, TS-1898_v2.patch we find out that cluster read and write performace is very poor, and even worse whe the conten is 2MB larger, we should improve that. a typical testing of 10MB file in cluster is about 10+s we have a patch that will improve to 300-800ms, all testing in local network -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-2036) Management update API for plugins doesn't work
[ https://issues.apache.org/jira/browse/TS-2036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13711789#comment-13711789 ] Leif Hedstrom commented on TS-2036: --- Marking this as resolved, since it's how our process (currently) work. I'm open for suggestions how to modify our process (on dev@), one suggestion is to add additional steps to the workflow to allow the bug to stay open, but e.g. in a Verification process. I will close this bug once v3.3.5 is released. Management update API for plugins doesn't work -- Key: TS-2036 URL: https://issues.apache.org/jira/browse/TS-2036 Project: Traffic Server Issue Type: Bug Components: Management API Reporter: Nick Kew Assignee: Nick Kew Fix For: 3.3.5 Functions registered with TSMgmtUpdateRegister are never called. -- 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-2038) Add CoAdvisor automation in our CI
Leif Hedstrom created TS-2038: - Summary: Add CoAdvisor automation in our CI Key: TS-2038 URL: https://issues.apache.org/jira/browse/TS-2038 Project: Traffic Server Issue Type: New Feature Components: Quality Reporter: Leif Hedstrom -- 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-2039) Add Coverity automation (weekly) into our CI
Leif Hedstrom created TS-2039: - Summary: Add Coverity automation (weekly) into our CI Key: TS-2039 URL: https://issues.apache.org/jira/browse/TS-2039 Project: Traffic Server Issue Type: New Feature Components: Quality Reporter: Leif Hedstrom -- 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-1996) Remove TSHttpTxnNewCacheLookupDo API
[ https://issues.apache.org/jira/browse/TS-1996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1996: -- Fix Version/s: (was: 3.3.5) 3.3.6 Remove TSHttpTxnNewCacheLookupDo API Key: TS-1996 URL: https://issues.apache.org/jira/browse/TS-1996 Project: Traffic Server Issue Type: Improvement Components: TS API Reporter: Leif Hedstrom Assignee: Leif Hedstrom Labels: A Fix For: 3.3.6 -- 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-1996) Remove TSHttpTxnNewCacheLookupDo API
[ https://issues.apache.org/jira/browse/TS-1996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13711802#comment-13711802 ] Leif Hedstrom commented on TS-1996: --- Moving this out to v3.3.6, since it's in experimental, we can delay breaking the stale-while-revalidate until after v3.4.0 is out (but, I'm also marking the API in the code with a big fat DON'T USE). Remove TSHttpTxnNewCacheLookupDo API Key: TS-1996 URL: https://issues.apache.org/jira/browse/TS-1996 Project: Traffic Server Issue Type: Improvement Components: TS API Reporter: Leif Hedstrom Assignee: Leif Hedstrom Labels: A Fix For: 3.3.6 -- 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-1996) Remove TSHttpTxnNewCacheLookupDo API
[ https://issues.apache.org/jira/browse/TS-1996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13711805#comment-13711805 ] ASF subversion and git services commented on TS-1996: - Commit 2528ac7b78538a9826c04739fe477cedd1694299 in branch refs/heads/master from [~zwoop] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=2528ac7 ] TS-1996 Mark the APIs for future removal Remove TSHttpTxnNewCacheLookupDo API Key: TS-1996 URL: https://issues.apache.org/jira/browse/TS-1996 Project: Traffic Server Issue Type: Improvement Components: TS API Reporter: Leif Hedstrom Assignee: Leif Hedstrom Labels: A Fix For: 3.3.6 -- 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-1298) http_parser_parse_req appears inconsistent
[ https://issues.apache.org/jira/browse/TS-1298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13711820#comment-13711820 ] Leif Hedstrom commented on TS-1298: --- Alan: Is this still a candidate for v3.3.5 / v3.4.0, or should we move out ? http_parser_parse_req appears inconsistent -- Key: TS-1298 URL: https://issues.apache.org/jira/browse/TS-1298 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 3.0.2 Reporter: Aidan McGurn Assignee: Alan M. Carroll Fix For: 3.3.5 when using IPT setup i test as follows: 1. telnet OS IP 80 from client machine //this will be routed via ATS as IPT env 2. write test in telnet window and hit return 3. i *correctly* get a PARSE ERROR inside HTTP.cc/http_parser_parse_req 1051if (!method_start || !method_end) (gdb) 1052 return PARSE_ERROR; (gdb) p method_end $4 = 0x0 (gdb) p method_start $5 = 0x12741000 test\r\n However of i repeat step 2, with test 2 method_end gets set and i end up with a PARSE_DONE and it thinks *INCORRECTLY* therefore this is a HTTP request. Assume this is a bug and we are missing validation here or is this making assumption the request is correct HTTP header format? thanks for any assistance, /aidan -- 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-1330) Logging related segfault in 3.2.0
[
https://issues.apache.org/jira/browse/TS-1330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13711821#comment-13711821
]
Leif Hedstrom commented on TS-1330:
---
Bryan: Any updates? Should we just move this out to v3.3.6 (and hence, v3.5.0) ?
Logging related segfault in 3.2.0
-
Key: TS-1330
URL: https://issues.apache.org/jira/browse/TS-1330
Project: Traffic Server
Issue Type: Bug
Components: Logging
Affects Versions: 3.2.0
Environment: ATS 3.2.0 on RHEL 6.2 64-bit
Reporter: David Carlin
Assignee: Bryan Call
Priority: Critical
Labels: A, crash
Fix For: 3.3.5
I observed the following crash once on one of our ATS boxes - possibly
related to TS-1240
Jul 2 13:56:56 l2 traffic_server[25853]: {0x2b0a391e1700} ERROR:
[SSL_NetVConnection::ssl_read_from_net] SSL_ERROR_SYSCALL, underlying IO
error: Connection reset by peer
Jul 2 13:59:56 l2 kernel: [ET_NET 1][25855]: segfault at c ip
0058e083 sp 2b0a2982b740 error 6
Jul 2 13:59:56 l2 kernel: [ET_NET 3][25857]: segfault at 84 ip
0058e083 sp 2b0a29a31740 error 6 in traffic_server[40+34]
Jul 2 13:59:56 l2 kernel: in traffic_server[40+34]
Jul 2 14:02:59 l2 traffic_cop[25901]: (test) read timeout [18 ]
Jul 2 14:02:59 l2 traffic_cop[25901]: server heartbeat failed [1]
Jul 2 14:03:08 l2 traffic_manager[25826]: {0x7f3f088607e0} FATAL:
[LocalManager::pollMgmtProcessServer] Error in read (errno: 104)
Jul 2 14:03:09 l2 traffic_manager[25826]: {0x7f3f088607e0} FATAL: (last
system error 104: Connection reset by peer)
Jul 2 14:03:09 l2 traffic_cop[25901]: cannot find traffic_server [1]
Jul 2 14:03:09 l2 traffic_manager[25826]: {0x7f3f088607e0} ERROR:
[LocalManager::sendMgmtMsgToProcesses] Error writing message
Jul 2 14:03:09 l2 traffic_manager[25826]: {0x7f3f088607e0} ERROR: (last
system error 32: Broken pipe)
Jul 2 14:03:12 l2 traffic_cop[25901]: cop received child status signal
[25826 35584]
Jul 2 14:03:12 l2 traffic_cop[25901]: traffic_manager not running, making
sure traffic_server is dead
Jul 2 14:03:12 l2 traffic_cop[25901]: spawning traffic_manager
Jul 2 14:03:13 l2 traffic_manager[18267]: NOTE: --- Manager Starting ---
Jul 2 14:03:13 l2 traffic_manager[18267]: NOTE: Manager Version: Apache
Traffic Server - traffic_manager - 3.2.0 - (build # 52518 on Jun 25 2012 at
18:22:12)
Jul 2 14:03:13 l2 traffic_manager[18267]: {0x7fe63de3f7e0} STATUS: opened
/home/y/logs/trafficserver/manager.log
Jul 2 14:03:15 l2 traffic_server[18322]: NOTE: --- Server Starting ---
Jul 2 14:03:15 l2 traffic_server[18322]: NOTE: Server Version: Apache
Traffic Server - traffic_server - 3.2.0 - (build # 52518 on Jun 25 2012 at
18:22:31)
Jul 2 14:03:15 l2 traffic_server[18322]: {0x2b77573ab860} STATUS: opened
/home/y/logs/trafficserver/diags.log
Jul 2 14:03:15 l2 traffic_server[18322]: {0x2b77573ab860} ERROR: Cannot
insert duplicate!
Jul 2 14:03:22 l2 traffic_cop[25901]: server heartbeat succeeded
[Jul 2 13:56:56.304] Server {0x2b0a391e1700} ERROR:
[SSL_NetVConnection::ssl_read_from_net] SSL_ERROR_SYSCALL, underlying IO
error: Connection reset by peer
NOTE: Traffic Server received Sig 11: Segmentation fault
NOTE: Traffic Server received Sig 11: Segmentation fault
/home/y/bin/traffic_server - STACK TRACE:
/home/y/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0[0x3b54e0f4a0]
/lib64/libpthread.so.0[0x3b54e0f4a0]
/home/y/bin/traffic_server(_ZN9LogBuffer14checkout_writeEPmm+0x153)[0x58e083]
/home/y/bin/traffic_server(_ZN9LogObject15_checkout_writeEPmm+0xa8)[0x5a64c8]
/home/y/bin/traffic_server(_ZN9LogObject3logEP9LogAccessPc+0x2f0)[0x5a7e30]
/home/y/bin/traffic_server(_ZN9LogBuffer14checkout_writeEPmm+0x153)[0x58e083]
/home/y/bin/traffic_server(_ZN9LogObject15_checkout_writeEPmm+0xa8)[0x5a64c8]
/home/y/bin/traffic_server(_ZN9LogObject3logEP9LogAccessPc+0x2f0)[0x5a7e30]
/home/y/bin/traffic_server(_ZN3Log6accessEP9LogAccess+0x146)[0x58f506]
/home/y/bin/traffic_server(_ZN6HttpSM12update_statsEv+0x630)[0x526c50]
/home/y/bin/traffic_server(_ZN3Log6accessEP9LogAccess+0x146)[0x58f506]
/home/y/bin/traffic_server(_ZN6HttpSM9kill_thisEv+0x928)[0x52b548]
/home/y/bin/traffic_server(_ZN6HttpSM12update_statsEv+0x630)[0x526c50]
/home/y/bin/traffic_server(_ZN6HttpSM9kill_thisEv+0x928)[0x52b548]
/home/y/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0x198)[0x52b868]
/home/y/bin/traffic_server(_ZN10HttpTunnel12main_handlerEiPv+0xde)[0x56c3ee]
/home/y/bin/traffic_server[0x6736a1]
/home/y/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0x198)[0x52b868]
/home/y/bin/traffic_server(_Z15write_to_net_ioP10NetHandlerP18UnixNetVConnectionP7EThread+0x847)[0x675517]
[jira] [Commented] (TS-1311) Range hit in cluster will crash server
[
https://issues.apache.org/jira/browse/TS-1311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13711823#comment-13711823
]
Leif Hedstrom commented on TS-1311:
---
Yongming: Any updates? Should we just move this out to v3.3.6 (and hence,
v3.5.0) ?
Range hit in cluster will crash server
--
Key: TS-1311
URL: https://issues.apache.org/jira/browse/TS-1311
Project: Traffic Server
Issue Type: Bug
Components: Clustering, HTTP, Network
Affects Versions: 3.3.0, 3.2.0
Environment: cluster type 1, and range request hit, where the content
is on the other hosts.
Reporter: Zhao Yongming
Assignee: Zhao Yongming
Fix For: 3.3.5
with the changes in TS-475, the single ranged request will be handled by
tunnel and pread. while this will crash in cluster env:
{code}
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0[0x309f00f4a0]
/usr/bin/traffic_server(HttpTunnel::consumer_handler(int,
HttpTunnelConsumer*)+0x188)[0x555668]
/usr/bin/traffic_server(HttpTunnel::main_handler(int, void*)+0x11d)[0x5554cd]
/usr/bin/traffic_server[0x63fdab]
/usr/bin/traffic_server(write_to_net_io(NetHandler*, UnixNetVConnection*,
EThread*)+0x353)[0x643a13]
/usr/bin/traffic_server(NetHandler::mainNetEvent(int, Event*)+0x2fe)[0x63befe]
/usr/bin/traffic_server(EThread::process_event(Event*, int)+0xb4)[0x660a74]
/usr/bin/traffic_server(EThread::execute()+0x4c3)[0x661403]
/usr/bin/traffic_server[0x65fd82]
/lib64/libpthread.so.0[0x309f0077f1]
/lib64/libc.so.6(clone+0x6d)[0x309ece570d]
{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-1244) Crash report: cores in Arena::reset
[
https://issues.apache.org/jira/browse/TS-1244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13711826#comment-13711826
]
Leif Hedstrom commented on TS-1244:
---
Brian or Manny: Any updates? Should we just move this out to v3.3.6 (and hence,
v3.5.0) ?
Crash report: cores in Arena::reset
Key: TS-1244
URL: https://issues.apache.org/jira/browse/TS-1244
Project: Traffic Server
Issue Type: Bug
Components: Core
Affects Versions: 3.0.4
Reporter: Manjesh Nilange
Assignee: Brian Geffon
Fix For: 3.3.5
I have two slightly different stack traces, but both involving Arena::reset
#0 0x003736032a45 in raise () from /lib64/libc.so.6
#1 0x003736034225 in abort () from /lib64/libc.so.6
#2 0x00373606fdfb in __libc_message () from /lib64/libc.so.6
#3 0x003736075716 in malloc_printerr () from /lib64/libc.so.6
#4 0x003724e0d38d in xfree (this=0x2b8c2c1b6bb8) at ink_resource.h:89
#5 blk_free (this=0x2b8c2c1b6bb8) at Arena.cc:69
#6 Arena::reset (this=0x2b8c2c1b6bb8) at Arena.cc:156
#7 0x0050e3e3 in destroy (this=0x2b8c2c1b6b40) at HttpTransact.h:1235
#8 HttpSM::cleanup (this=0x2b8c2c1b6b40) at HttpSM.cc:346
#9 0x0050e719 in HttpSM::destroy (this=0x2b8c2c1b6b40) at
HttpSM.cc:368
#10 0x00515a56 in HttpSM::kill_this (this=0x2b8c2c1b6b40) at
HttpSM.cc:6023
#11 0x00515e08 in HttpSM::main_handler (this=0x2b8c2c1b6b40,
event=2301, data=0x2b8c2c1b8828)
at HttpSM.cc:2452
...
(gdb) f 4
#4 0x003724e0d38d in xfree (this=0x2b8c2c1b6bb8) at ink_resource.h:89
89ink_free(mem);
(gdb) p mem
$1 = value optimized out
(gdb) f 5
#5 blk_free (this=0x2b8c2c1b6bb8) at Arena.cc:69
69xfree(blk);
(gdb) p blk
$2 = value optimized out
(gdb) f 6
#6 Arena::reset (this=0x2b8c2c1b6bb8) at Arena.cc:156
156 blk_free(m_blocks);
(gdb) p m_blocks
$3 = (ArenaBlock *) 0x2b8b9822b870
(gdb) p *m_blocks
$4 = {next = 0x3b323531322e3630, m_heap_end = 0x2554454e2e303225 Address
0x2554454e2e303225 out of bounds,
m_water_level = 0x303225524c433032 Address 0x303225524c433032 out of
bounds, data = 3.5.3072}
(gdb) p *m_blocks-next
Cannot access memory at address 0x3b323531322e3630
It looks m_blocks is corrupted.
and the other stack trace
#3 0x004d03aa in signal_handler (sig=11) at signals.cc:225
#4 signal handler called
#5 blk_free (this=0x2afc58072f88) at Arena.cc:65
#6 Arena::reset (this=0x2afc58072f88) at Arena.cc:156
#7 0x0050e3e3 in destroy (this=0x2afc58072f10) at HttpTransact.h:1235
#8 HttpSM::cleanup (this=0x2afc58072f10) at HttpSM.cc:346
#9 0x0050e719 in HttpSM::destroy (this=0x2afc58072f10) at
HttpSM.cc:368
#10 0x00515a56 in HttpSM::kill_this (this=0x2afc58072f10) at
HttpSM.cc:6023
#11 0x00515e08 in HttpSM::main_handler (this=0x2afc58072f10,
event=2301, data=0x2afc58074bf8)
at HttpSM.cc:2452
...
(gdb) f 5
#5 blk_free (this=0x2afc58072f88) at Arena.cc:65
65 size = blk-m_heap_end - blk-data[0];
(gdb) p blk
$1 = value optimized out
(gdb) f 6
#6 Arena::reset (this=0x2afc58072f88) at Arena.cc:156
156 blk_free(m_blocks);
(gdb) p m_blocks
$2 = (ArenaBlock *) 0x373439333634
(gdb) p *m_blocks
Cannot access memory at address 0x373439333634
Our environment:
$ uname -a
Linux xxx.prod 2.6.32-131.4.1.el6.x86_64 #1 SMP Fri Jun 10 10:54:26 EDT 2011
x86_64 x86_64 x86_64 GNU/Linux
$ file /usr/bin/traffic_server
/usr/bin/traffic_server: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
dynamically linked (uses shared libs), for GNU/Linux 2.6.18, stripped
--
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-1535) FetchSM process_fetch_write should ignore event TS_EVENT_VCONN_WRITE_READY
[ https://issues.apache.org/jira/browse/TS-1535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13711824#comment-13711824 ] Leif Hedstrom commented on TS-1535: --- Yongming: Any updates? Should we just move this out to v3.3.6 (and hence, v3.5.0) ? FetchSM process_fetch_write should ignore event TS_EVENT_VCONN_WRITE_READY -- Key: TS-1535 URL: https://issues.apache.org/jira/browse/TS-1535 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 3.3.0 Reporter: Zhao Yongming Assignee: Zhao Yongming Fix For: 3.3.5 or you can not POST much data -- 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-2040) Add Clang static code analysis to our CI
[ https://issues.apache.org/jira/browse/TS-2040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2040: -- Fix Version/s: Infrastructure Add Clang static code analysis to our CI Key: TS-2040 URL: https://issues.apache.org/jira/browse/TS-2040 Project: Traffic Server Issue Type: New Feature Components: Quality Reporter: Leif Hedstrom Fix For: Infrastructure -- 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-2038) Add CoAdvisor automation in our CI
[ https://issues.apache.org/jira/browse/TS-2038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2038: -- Fix Version/s: Infrastructure Add CoAdvisor automation in our CI -- Key: TS-2038 URL: https://issues.apache.org/jira/browse/TS-2038 Project: Traffic Server Issue Type: New Feature Components: Quality Reporter: Leif Hedstrom Fix For: Infrastructure -- 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-2039) Add Coverity automation (weekly) into our CI
[ https://issues.apache.org/jira/browse/TS-2039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2039: -- Fix Version/s: Infrastructure Add Coverity automation (weekly) into our CI Key: TS-2039 URL: https://issues.apache.org/jira/browse/TS-2039 Project: Traffic Server Issue Type: New Feature Components: Quality Reporter: Leif Hedstrom Fix For: Infrastructure -- 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-2031) Two SSL certs with overlapping CNs stomps over each other without warnings
[
https://issues.apache.org/jira/browse/TS-2031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2031:
--
Description: If you have two certs that has the same CNs, the last one
wins in the SNI negotiation. This even takes precedence over assigned IPs
(SNI trumps IP). We should at least warn on this. (was: I have a case, where
two IPs have different certificate, but the second certificate is a wildcard.
So, certificate 1) is more specificic (www.example) whereas the second cert is
a *.example.com). My config is e.g.
{code}
dest_ip=1.2.3.4 ssl_cert_name=www.example.com.pem
dest_ip=2.3.4.5 ssl_cert_name=example.com.pem
{code}
The IP for www.example.com is 1.2.3.4, yet, it will present the wrong cert. A
wild guess is that the lookup matches the second cert first, and it fails to
take the IP into consideration?
)
Priority: Minor (was: Major)
Fix Version/s: sometime
Summary: Two SSL certs with overlapping CNs stomps over each other
without warnings (was: SSL can pick the wrong certificate)
Two SSL certs with overlapping CNs stomps over each other without warnings
--
Key: TS-2031
URL: https://issues.apache.org/jira/browse/TS-2031
Project: Traffic Server
Issue Type: Bug
Components: SSL
Reporter: Leif Hedstrom
Priority: Minor
Fix For: sometime
If you have two certs that has the same CNs, the last one wins in the SNI
negotiation. This even takes precedence over assigned IPs (SNI trumps IP).
We should at least warn on this.
--
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-1995) After TS-1740, traffic_shell and traffic_line starts to show zero stats in some fields.
[ https://issues.apache.org/jira/browse/TS-1995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-1995. --- Resolution: Duplicate Marking as dupe of TS-1805 for now, please reopen if still an issue. After TS-1740, traffic_shell and traffic_line starts to show zero stats in some fields. --- Key: TS-1995 URL: https://issues.apache.org/jira/browse/TS-1995 Project: Traffic Server Issue Type: Bug Components: Stats Reporter: Tommy Lee In 3.3.1-dev traffic_shell and traffic_line shows this output: % show:proxy-stats Document Hit Rate 2.868852 %* Ram cache Hit Rate --- 0.00 %* Bandwidth Saving - 0.330866 %* Cache Percent Free --- 70.415193 % Open Server Connections -- 17 Open Client Connections -- 11 Open Cache Connections --- 1 Client Throughput 0.048656 MBit/Sec Transaction Per Second --- 0.299951 But after apply TS-1740 patch the output is always this: % show:proxy-stats Document Hit Rate 0.00 %* Ram cache Hit Rate --- 0.00 %* Bandwidth Saving - 0.00 %* Cache Percent Free --- 0.00 % Open Server Connections -- 43 Open Client Connections -- 19 Open Cache Connections --- 0 Client Throughput 9123.543945 MBit/Sec Transaction Per Second --- 0.00 I'm trying to exclude only this patch with 3.3.2-dev but without luck. -- 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-2041) override records.config setting from the environment
[ https://issues.apache.org/jira/browse/TS-2041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-2041: Fix Version/s: (was: 3.3.5) 3.3.6 override records.config setting from the environment Key: TS-2041 URL: https://issues.apache.org/jira/browse/TS-2041 Project: Traffic Server Issue Type: Improvement Components: Configuration Reporter: James Peach Fix For: 3.3.6 For some deployment workflows it would be convenient to be able to override records.config settings from the environment. After reading records.config, we should process environment overrides based on a transformed environment name, for example proxy.config.bin_path would be set from the PROXY_CONFIG_BIN_PATH variable. -- 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-2041) override records.config setting from the environment
James Peach created TS-2041: --- Summary: override records.config setting from the environment Key: TS-2041 URL: https://issues.apache.org/jira/browse/TS-2041 Project: Traffic Server Issue Type: Improvement Components: Configuration Reporter: James Peach For some deployment workflows it would be convenient to be able to override records.config settings from the environment. After reading records.config, we should process environment overrides based on a transformed environment name, for example proxy.config.bin_path would be set from the PROXY_CONFIG_BIN_PATH variable. -- 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-2041) override records.config setting from the environment
[ https://issues.apache.org/jira/browse/TS-2041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-2041: Fix Version/s: 3.3.5 override records.config setting from the environment Key: TS-2041 URL: https://issues.apache.org/jira/browse/TS-2041 Project: Traffic Server Issue Type: Improvement Components: Configuration Reporter: James Peach Fix For: 3.3.5 For some deployment workflows it would be convenient to be able to override records.config settings from the environment. After reading records.config, we should process environment overrides based on a transformed environment name, for example proxy.config.bin_path would be set from the PROXY_CONFIG_BIN_PATH variable. -- 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-2042) Remove remnants of unused vingid command line option
[ https://issues.apache.org/jira/browse/TS-2042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2042: -- Fix Version/s: 3.3.5 Assignee: Leif Hedstrom Remove remnants of unused vingid command line option Key: TS-2042 URL: https://issues.apache.org/jira/browse/TS-2042 Project: Traffic Server Issue Type: Improvement Components: Core Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 3.3.5 -- 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-2042) Remove remnants of unused vingid command line option
Leif Hedstrom created TS-2042: - Summary: Remove remnants of unused vingid command line option Key: TS-2042 URL: https://issues.apache.org/jira/browse/TS-2042 Project: Traffic Server Issue Type: Improvement Components: Core Reporter: Leif Hedstrom -- 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-2042) Remove remnants of unused vingid command line option
[ https://issues.apache.org/jira/browse/TS-2042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13711862#comment-13711862 ] ASF subversion and git services commented on TS-2042: - Commit 64a6c828de0ca82a404a11ba6ff12d3f5f4ca273 in branch refs/heads/master from [~zwoop] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=64a6c82 ] TS-2042 Remove remnants of unused vingid command line option Remove remnants of unused vingid command line option Key: TS-2042 URL: https://issues.apache.org/jira/browse/TS-2042 Project: Traffic Server Issue Type: Improvement Components: Core Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 3.3.5 -- 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-2043) Setup CI builds, RAT reports etc. for v3.4 branch
[ https://issues.apache.org/jira/browse/TS-2043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2043: -- Fix Version/s: Infrastructure Setup CI builds, RAT reports etc. for v3.4 branch - Key: TS-2043 URL: https://issues.apache.org/jira/browse/TS-2043 Project: Traffic Server Issue Type: Improvement Components: Quality Reporter: Leif Hedstrom Fix For: Infrastructure -- 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-2042) Remove remnants of unused vingid command line option
[ https://issues.apache.org/jira/browse/TS-2042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-2042. --- Resolution: Fixed Remove remnants of unused vingid command line option Key: TS-2042 URL: https://issues.apache.org/jira/browse/TS-2042 Project: Traffic Server Issue Type: Improvement Components: Core Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 3.3.5 -- 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-2043) Setup CI builds, RAT reports etc. for v3.4 branch
Leif Hedstrom created TS-2043: - Summary: Setup CI builds, RAT reports etc. for v3.4 branch Key: TS-2043 URL: https://issues.apache.org/jira/browse/TS-2043 Project: Traffic Server Issue Type: Improvement Components: Quality Reporter: Leif Hedstrom -- 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
