[jira] [Commented] (TS-721) incorrect http hit ratio in stats
[ https://issues.apache.org/jira/browse/TS-721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021478#comment-13021478 ] Zhao Yongming commented on TS-721: -- yeah, I think that is fine for my usage, I'd check the stats and cleanup it later. zym@zym6400 ~/Desktop/TS $ echo -e "GET http://cdn.zymlinux.net/stat/ HTTP/1.0\r\n\r\n" | netcat -i 1 10.62.163.237 80 | grep cache_hit_ratio proxy.node.cache_hit_ratio=0.67 proxy.node.cache_hit_ratio_int_pct=67 proxy.node.cache_hit_ratio_avg_10s_int_pct=100 proxy.node.cache_hit_ratio_avg_10s=1.00 proxy.cluster.cache_hit_ratio=0.672414 proxy.cluster.cache_hit_ratio_int_pct=167 proxy.cluster.cache_hit_ratio_avg_10s=0.965517 zym@zym6400 ~/Desktop/TS $ echo -e "GET http://cdn.zymlinux.net/stat/ HTTP/1.0\r\n\r\n" | netcat -i 1 10.62.163.238 80 | grep cache_hit_ratio proxy.node.cache_hit_ratio=0.999215 proxy.node.cache_hit_ratio_int_pct=100 proxy.node.cache_hit_ratio_avg_10s_int_pct=100 proxy.node.cache_hit_ratio_avg_10s=1.00 proxy.cluster.cache_hit_ratio=0.999227 proxy.cluster.cache_hit_ratio_int_pct=200 proxy.cluster.cache_hit_ratio_avg_10s=0.95 > incorrect http hit ratio in stats > - > > Key: TS-721 > URL: https://issues.apache.org/jira/browse/TS-721 > Project: Traffic Server > Issue Type: Bug > Components: HTTP, Stats >Affects Versions: 2.1.7 >Reporter: Zhao Yongming >Assignee: Leif Hedstrom > Fix For: 2.1.8 > > > in my production, the proxy.node.http.cache_hit_ratio is always 0, it should > be the same as proxy.node.cache_hit_ratio, that make my cluster wide stats > error too: > [root@cache190 ~]# lynx -source http://localhost:81/stat/ | grep ratio > proxy.config.cluster.cluster_configuration=cluster.config > proxy.config.cluster.cluster_load_clear_duration=24 > proxy.config.cluster.cluster_load_exceed_duration=4 > proxy.config.icp.icp_configuration=icp.config > proxy.config.update.update_configuration=update.config > proxy.node.http.cache_hit_ratio=0.00 > proxy.node.http.cache_hit_ratio_int_pct=0 > proxy.node.http.bandwidth_hit_ratio=0.904612 > proxy.node.http.bandwidth_hit_ratio_int_pct=90 > proxy.node.bandwidth_hit_ratio=0.904612 > proxy.node.bandwidth_hit_ratio_int_pct=90 > proxy.node.hostdb.hit_ratio=0.049913 > proxy.node.hostdb.hit_ratio_int_pct=5 > proxy.node.cache_hit_ratio=0.883374 > proxy.node.cache_hit_ratio_int_pct=88 > proxy.node.cache_hit_ratio_avg_10s_int_pct=93 > proxy.node.bandwidth_hit_ratio_avg_10s_int_pct=93 > proxy.node.bandwidth_hit_ratio_avg_10s=0.934583 > proxy.node.cache_hit_ratio_avg_10s=0.930153 > proxy.node.hostdb.hit_ratio_avg_10s=0.996169 > proxy.cluster.bandwidth_hit_ratio=0.898589 > proxy.cluster.bandwidth_hit_ratio_int_pct=1023958400 > proxy.cluster.bandwidth_hit_ratio_avg_10s=0.938777 > proxy.cluster.http.cache_hit_ratio=0.900161 > proxy.cluster.http.cache_hit_ratio_int_pct=1063552512 > proxy.cluster.http.bandwidth_hit_ratio=0.915798 > proxy.cluster.http.bandwidth_hit_ratio_int_pct=1063552576 > proxy.cluster.cache_hit_ratio=0.900161 > proxy.cluster.cache_hit_ratio_int_pct=180 > proxy.cluster.cache_hit_ratio_avg_10s=0.935070 > proxy.cluster.hostdb.hit_ratio=0.047426 > proxy.cluster.hostdb.hit_ratio_int_pct=6 > proxy.cluster.hostdb.hit_ratio_avg_10s=0.337434 > proxy.process.cluster.configuration_changes=1 > [root@cache190 ~]# traffic_line -r proxy.node.http.cache_hit_ratio > 0.00 > in my situation: > proxy.node.http.cache_hit_ratio=0.00 > proxy.node.http.cache_hit_ratio_int_pct=0 > should be same as: > proxy.node.cache_hit_ratio=0.883374 > proxy.node.cache_hit_ratio_int_pct=88 > there is some strange error in cluster too: > proxy.cluster.bandwidth_hit_ratio_int_pct=1023958400 > proxy.cluster.http.cache_hit_ratio_int_pct=1063552512 > proxy.cluster.http.bandwidth_hit_ratio_int_pct=1063552576 > proxy.cluster.cache_hit_ratio_int_pct=180 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-702) FATAL: MIME.cc:1250: failed assert `j < block_count`
[
https://issues.apache.org/jira/browse/TS-702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yakov Markovitch updated TS-702:
Attachment: trafficserver.2.1.7.too.many.mimefields.patch
Fix for the bug in MIME header blocks relocation after copy MIME headers copy.
> FATAL: MIME.cc:1250: failed assert `j < block_count`
> -
>
> Key: TS-702
> URL: https://issues.apache.org/jira/browse/TS-702
> Project: Traffic Server
> Issue Type: Bug
> Components: MIME
>Affects Versions: 2.0.1
> Environment: Sun Blade X6240 (64G Ram), Running Linux Debian Lenny,
> Kernel 2.6.26-2-amd64
>Reporter: Ricky Chan
>Priority: Critical
> Attachments: trafficserver.2.1.7.too.many.mimefields.patch
>
>
> I have 20 servers in a CDN farm which I brought live recently, I have noticed
> with in a day 5 servers had this error reported in traffic.out. Essentially
> aborting due to assertion failure. The server restarts (from traffic_cop).
> This platform has not had any load go through it yet, it's running around
> 5MB/s a second with around 25 connection per second. So doing much.
> I was going to migrate more traffic onto it, but holding off due to this
> assertion issue.
> Looking at the code, we have:
> for (j=0; j < block_count; j++) {
> ... with a condition which breaks out ..
> }
> ink_release_assert(j < block_count)
> So for this assert to be hit the entire list must be gone through without
> triggering the break clause, i.e. j == block_count
> I don't know this code well, is this a real bug or should the assert be there
> (or j <= block_count)?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-702) FATAL: MIME.cc:1250: failed assert `j < block_count`
[
https://issues.apache.org/jira/browse/TS-702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021570#comment-13021570
]
Yakov Markovitch commented on TS-702:
-
This bug is in the algorithm of adjusting pointers inside MIME field blocks
after copying MIME headers. mime_hdr_copy_onto, which is directly called from
TSMimeHdrCopy and indirectly from TSMimeHdrClone, copies MIME headers as raw
memory blocks and then calls mime_hdr_field_block_list_adjust to adjust fields'
internal pointers to duplicates (MIMEField::m_next_dup).
The algorithm of mime_hdr_field_block_list_adjust is both complicated and
incorrect, since it implicitly assumes relative offsets between original and
copied blocks do not change. Worse is, they most often actually do not change,
accidentally: the source blocks allocated continuously, as well as target
blocks. The bug is very insidious and hard to reproduce, to manifest itself it
needs _all_ the following:
1. There must be more than one block allocated for a header, i.e. the header
must contain more than MIME_FIELD_BLOCK_SLOTS (==16) fields.
2. There must be duplicated fields in the header, and at least some of those
fields must be allocated not in the first block.
3. Relative offsets between target heap blocks must not match offsets between
source blocks.
I've attached a patch that fixes the bug. The patch was tested in production
environment.
> FATAL: MIME.cc:1250: failed assert `j < block_count`
> -
>
> Key: TS-702
> URL: https://issues.apache.org/jira/browse/TS-702
> Project: Traffic Server
> Issue Type: Bug
> Components: MIME
>Affects Versions: 2.0.1
> Environment: Sun Blade X6240 (64G Ram), Running Linux Debian Lenny,
> Kernel 2.6.26-2-amd64
>Reporter: Ricky Chan
>Priority: Critical
> Attachments: trafficserver.2.1.7.too.many.mimefields.patch
>
>
> I have 20 servers in a CDN farm which I brought live recently, I have noticed
> with in a day 5 servers had this error reported in traffic.out. Essentially
> aborting due to assertion failure. The server restarts (from traffic_cop).
> This platform has not had any load go through it yet, it's running around
> 5MB/s a second with around 25 connection per second. So doing much.
> I was going to migrate more traffic onto it, but holding off due to this
> assertion issue.
> Looking at the code, we have:
> for (j=0; j < block_count; j++) {
> ... with a condition which breaks out ..
> }
> ink_release_assert(j < block_count)
> So for this assert to be hit the entire list must be gone through without
> triggering the break clause, i.e. j == block_count
> I don't know this code well, is this a real bug or should the assert be there
> (or j <= block_count)?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-716) Crash in Continuation::handleEvent
[
https://issues.apache.org/jira/browse/TS-716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021644#comment-13021644
]
John Plevyak commented on TS-716:
-
I have committed 1095127, which fixes a problem with the DNS HostEnt and
DNSEntry continuations, but it is consistent with only some of the stack traces
seen here, so this bug stays open until we confirm a fix.
> Crash in Continuation::handleEvent
> ---
>
> Key: TS-716
> URL: https://issues.apache.org/jira/browse/TS-716
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.1.7
> Environment: CentOS 5.4 x86_64, 6 * 2T SATA Disks, 48G Memory
>Reporter: Kissdev
>Assignee: John Plevyak
>Priority: Critical
> Fix For: 2.1.8
>
> Attachments: crasher.patch
>
>
> ATS crashes with the following configuration:
> - reverse proxy , storage: 6 raw devices (6*2T), 1 partition (2T)
> - remap config:regex_map http://(.*) http://$1
> The load : about 100Mbps, requests for top 4000 internet sites, mainly
> html,js,pictures,flashes
> Detail of crashes by core dump:
> crash #1:
> {code}
> #0 0x004dd17a in Continuation::handleEvent (this=0x2aaaba364cb0,
> event=1, data=0x90f7170) at I_Continuation.h:146
> 146 I_Continuation.h: No such file or directory.
> in I_Continuation.h
> (gdb) bt
> #0 0x004dd17a in Continuation::handleEvent (this=0x2aaaba364cb0,
> event=1, data=0x90f7170) at I_Continuation.h:146
> #1 0x00702b80 in EThread::process_event (this=0x2b101010,
> e=0x90f7170, calling_code=1) at UnixEThread.cc:140
> #2 0x00702fa1 in EThread::execute (this=0x2b101010) at
> UnixEThread.cc:232
> #3 0x007024d2 in spawn_thread_internal (a=0x8d94a70) at Thread.cc:85
> #4 0x0036ebc064a7 in start_thread () from /lib64/libpthread.so.0
> #5 0x0036eb0d3c2d in clone () from /lib64/libc.so.6
> (gdb) frame 0
> #0 0x004dd17a in Continuation::handleEvent (this=0x2aaaba364cb0,
> event=1, data=0x90f7170) at I_Continuation.h:146
> 146 in I_Continuation.h
> (gdb) print *this
> $1 = { = {_vptr.force_VFPT_to_top = 0x2aaaba360a11},
> handler = &virtual table offset -1157442765409226770, this adjustment
> -1157442765409226769,
> handler_name = 0xefefefefefefefef bounds>, mutex = {m_ptr = 0xefefefefefefefef}, link = {>
> = {
> next = 0xefefefefefefefef}, prev = 0xefefefefefefefef}}
> {code}
> crash #2:
> {code}
> (gdb) bt
> #0 0x004dd17a in Continuation::handleEvent (this=0x2aaabc0bce80,
> event=1, data=0x154b5a80) at I_Continuation.h:146
> #1 0x006db290 in InactivityCop::check_inactivity (this=0x154c8730,
> event=2, e=0x154b5a80) at UnixNet.cc:57
> #2 0x004dd1bb in Continuation::handleEvent (this=0x154c8730,
> event=2, data=0x154b5a80) at I_Continuation.h:146
> #3 0x00702b80 in EThread::process_event (this=0x2b606010,
> e=0x154b5a80, calling_code=2) at UnixEThread.cc:140
> #4 0x00702ec2 in EThread::execute (this=0x2b606010) at
> UnixEThread.cc:217
> #5 0x007024d2 in spawn_thread_internal (a=0x154852c0) at Thread.cc:85
> #6 0x0036ebc064a7 in start_thread () from /lib64/libpthread.so.0
> #7 0x0036eb0d3c2d in clone () from /lib64/libc.so.6
> (gdb) frame 0
> #0 0x004dd17a in Continuation::handleEvent (this=0x2aaabc0bce80,
> event=1, data=0x154b5a80) at I_Continuation.h:146
> 146 in I_Continuation.h
> (gdb) print *this
> $1 = { = {_vptr.force_VFPT_to_top = 0x16280061},
> handler = &virtual table offset -1157442765409226770, this adjustment
> -1157442765409226769,
> handler_name = 0xefefefefefefefef bounds>, mutex = {m_ptr = 0xefefefefefefefef}, link = {>
> = {
> next = 0xefefefefefefefef}, prev = 0xefefefefefefefef}}
> (gdb)
> {code}
> crash #3:
> {code}
> (gdb) bt
> #0 0x004dd17a in Continuation::handleEvent (this=0x2aaab45d3a10,
> event=2, data=0x5631120) at I_Continuation.h:146
> #1 0x00702b80 in EThread::process_event (this=0x2abfc010,
> e=0x5631120, calling_code=2) at UnixEThread.cc:140
> #2 0x00702ec2 in EThread::execute (this=0x2abfc010) at
> UnixEThread.cc:217
> #3 0x0050917c in main (argc=3, argv=0x7fff0af6e3b8) at Main.cc:1962
> (gdb) frame 0
> #0 0x004dd17a in Continuation::handleEvent (this=0x2aaab45d3a10,
> event=2, data=0x5631120) at I_Continuation.h:146
> 146 in I_Continuation.h
> (gdb) print *this
> $1 = { = {_vptr.force_VFPT_to_top = 0x2aaab45df291},
> handler = &virtual table offset -1157442765409226770, this adjustment
> -1157442765409226769,
> handler_name = 0xefefefefefefefef bounds>, mutex = {m_ptr = 0xefefefefefefefef}, link = {>
> = {
> next = 0xefefefefefefefef}, prev = 0xefefefefefefefef}}
> {code}
--
This message
[jira] [Resolved] (TS-721) incorrect http hit ratio in stats
[ https://issues.apache.org/jira/browse/TS-721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-721. -- Resolution: Fixed Closing as fixed, please reopen if there are still issues. > incorrect http hit ratio in stats > - > > Key: TS-721 > URL: https://issues.apache.org/jira/browse/TS-721 > Project: Traffic Server > Issue Type: Bug > Components: HTTP, Stats >Affects Versions: 2.1.7 >Reporter: Zhao Yongming >Assignee: Leif Hedstrom > Fix For: 2.1.8 > > > in my production, the proxy.node.http.cache_hit_ratio is always 0, it should > be the same as proxy.node.cache_hit_ratio, that make my cluster wide stats > error too: > [root@cache190 ~]# lynx -source http://localhost:81/stat/ | grep ratio > proxy.config.cluster.cluster_configuration=cluster.config > proxy.config.cluster.cluster_load_clear_duration=24 > proxy.config.cluster.cluster_load_exceed_duration=4 > proxy.config.icp.icp_configuration=icp.config > proxy.config.update.update_configuration=update.config > proxy.node.http.cache_hit_ratio=0.00 > proxy.node.http.cache_hit_ratio_int_pct=0 > proxy.node.http.bandwidth_hit_ratio=0.904612 > proxy.node.http.bandwidth_hit_ratio_int_pct=90 > proxy.node.bandwidth_hit_ratio=0.904612 > proxy.node.bandwidth_hit_ratio_int_pct=90 > proxy.node.hostdb.hit_ratio=0.049913 > proxy.node.hostdb.hit_ratio_int_pct=5 > proxy.node.cache_hit_ratio=0.883374 > proxy.node.cache_hit_ratio_int_pct=88 > proxy.node.cache_hit_ratio_avg_10s_int_pct=93 > proxy.node.bandwidth_hit_ratio_avg_10s_int_pct=93 > proxy.node.bandwidth_hit_ratio_avg_10s=0.934583 > proxy.node.cache_hit_ratio_avg_10s=0.930153 > proxy.node.hostdb.hit_ratio_avg_10s=0.996169 > proxy.cluster.bandwidth_hit_ratio=0.898589 > proxy.cluster.bandwidth_hit_ratio_int_pct=1023958400 > proxy.cluster.bandwidth_hit_ratio_avg_10s=0.938777 > proxy.cluster.http.cache_hit_ratio=0.900161 > proxy.cluster.http.cache_hit_ratio_int_pct=1063552512 > proxy.cluster.http.bandwidth_hit_ratio=0.915798 > proxy.cluster.http.bandwidth_hit_ratio_int_pct=1063552576 > proxy.cluster.cache_hit_ratio=0.900161 > proxy.cluster.cache_hit_ratio_int_pct=180 > proxy.cluster.cache_hit_ratio_avg_10s=0.935070 > proxy.cluster.hostdb.hit_ratio=0.047426 > proxy.cluster.hostdb.hit_ratio_int_pct=6 > proxy.cluster.hostdb.hit_ratio_avg_10s=0.337434 > proxy.process.cluster.configuration_changes=1 > [root@cache190 ~]# traffic_line -r proxy.node.http.cache_hit_ratio > 0.00 > in my situation: > proxy.node.http.cache_hit_ratio=0.00 > proxy.node.http.cache_hit_ratio_int_pct=0 > should be same as: > proxy.node.cache_hit_ratio=0.883374 > proxy.node.cache_hit_ratio_int_pct=88 > there is some strange error in cluster too: > proxy.cluster.bandwidth_hit_ratio_int_pct=1023958400 > proxy.cluster.http.cache_hit_ratio_int_pct=1063552512 > proxy.cluster.http.bandwidth_hit_ratio_int_pct=1063552576 > proxy.cluster.cache_hit_ratio_int_pct=180 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-702) FATAL: MIME.cc:1250: failed assert `j < block_count`
[
https://issues.apache.org/jira/browse/TS-702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-702:
-
Fix Version/s: 2.1.8
> FATAL: MIME.cc:1250: failed assert `j < block_count`
> -
>
> Key: TS-702
> URL: https://issues.apache.org/jira/browse/TS-702
> Project: Traffic Server
> Issue Type: Bug
> Components: MIME
>Affects Versions: 2.0.1
> Environment: Sun Blade X6240 (64G Ram), Running Linux Debian Lenny,
> Kernel 2.6.26-2-amd64
>Reporter: Ricky Chan
>Priority: Critical
> Fix For: 2.1.8
>
> Attachments: trafficserver.2.1.7.too.many.mimefields.patch
>
>
> I have 20 servers in a CDN farm which I brought live recently, I have noticed
> with in a day 5 servers had this error reported in traffic.out. Essentially
> aborting due to assertion failure. The server restarts (from traffic_cop).
> This platform has not had any load go through it yet, it's running around
> 5MB/s a second with around 25 connection per second. So doing much.
> I was going to migrate more traffic onto it, but holding off due to this
> assertion issue.
> Looking at the code, we have:
> for (j=0; j < block_count; j++) {
> ... with a condition which breaks out ..
> }
> ink_release_assert(j < block_count)
> So for this assert to be hit the entire list must be gone through without
> triggering the break clause, i.e. j == block_count
> I don't know this code well, is this a real bug or should the assert be there
> (or j <= block_count)?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-702) FATAL: MIME.cc:1250: failed assert `j < block_count`
[
https://issues.apache.org/jira/browse/TS-702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021674#comment-13021674
]
Leif Hedstrom commented on TS-702:
--
Awesome, nicely done! I've asked Vijay to review this patch, but I'll also take
a look at it. I'm assigning this for v2.1.8 inclusion.
> FATAL: MIME.cc:1250: failed assert `j < block_count`
> -
>
> Key: TS-702
> URL: https://issues.apache.org/jira/browse/TS-702
> Project: Traffic Server
> Issue Type: Bug
> Components: MIME
>Affects Versions: 2.0.1
> Environment: Sun Blade X6240 (64G Ram), Running Linux Debian Lenny,
> Kernel 2.6.26-2-amd64
>Reporter: Ricky Chan
>Priority: Critical
> Fix For: 2.1.8
>
> Attachments: trafficserver.2.1.7.too.many.mimefields.patch
>
>
> I have 20 servers in a CDN farm which I brought live recently, I have noticed
> with in a day 5 servers had this error reported in traffic.out. Essentially
> aborting due to assertion failure. The server restarts (from traffic_cop).
> This platform has not had any load go through it yet, it's running around
> 5MB/s a second with around 25 connection per second. So doing much.
> I was going to migrate more traffic onto it, but holding off due to this
> assertion issue.
> Looking at the code, we have:
> for (j=0; j < block_count; j++) {
> ... with a condition which breaks out ..
> }
> ink_release_assert(j < block_count)
> So for this assert to be hit the entire list must be gone through without
> triggering the break clause, i.e. j == block_count
> I don't know this code well, is this a real bug or should the assert be there
> (or j <= block_count)?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-702) FATAL: MIME.cc:1250: failed assert `j < block_count`
[
https://issues.apache.org/jira/browse/TS-702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021676#comment-13021676
]
Leif Hedstrom commented on TS-702:
--
One nitpicky comment: Do we really need the templatized rebase() ? I see it
only used once, so why not just change it to use MIMEField* ? Or do you foresee
using it in future patches / additions?
> FATAL: MIME.cc:1250: failed assert `j < block_count`
> -
>
> Key: TS-702
> URL: https://issues.apache.org/jira/browse/TS-702
> Project: Traffic Server
> Issue Type: Bug
> Components: MIME
>Affects Versions: 2.0.1
> Environment: Sun Blade X6240 (64G Ram), Running Linux Debian Lenny,
> Kernel 2.6.26-2-amd64
>Reporter: Ricky Chan
>Priority: Critical
> Fix For: 2.1.8
>
> Attachments: trafficserver.2.1.7.too.many.mimefields.patch
>
>
> I have 20 servers in a CDN farm which I brought live recently, I have noticed
> with in a day 5 servers had this error reported in traffic.out. Essentially
> aborting due to assertion failure. The server restarts (from traffic_cop).
> This platform has not had any load go through it yet, it's running around
> 5MB/s a second with around 25 connection per second. So doing much.
> I was going to migrate more traffic onto it, but holding off due to this
> assertion issue.
> Looking at the code, we have:
> for (j=0; j < block_count; j++) {
> ... with a condition which breaks out ..
> }
> ink_release_assert(j < block_count)
> So for this assert to be hit the entire list must be gone through without
> triggering the break clause, i.e. j == block_count
> I don't know this code well, is this a real bug or should the assert be there
> (or j <= block_count)?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-652) SSL random buffer initialization should be checked
[ https://issues.apache.org/jira/browse/TS-652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-652: Assignee: Leif Hedstrom > SSL random buffer initialization should be checked > -- > > Key: TS-652 > URL: https://issues.apache.org/jira/browse/TS-652 > Project: Traffic Server > Issue Type: Wish > Components: SSL >Reporter: John Plevyak >Assignee: Leif Hedstrom > Fix For: 2.1.8 > > Attachments: TS-652.diff > > > The way the SSL random buffers are initialized is interesting... it could > also be made more efficient > with the new 64-bit random number generator. It looks like it is using > whatever is on the stack > and then hashing it with 2 different random number generators and skipping > the first few bytes... > why, no idea. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-654) request for support of Layer7 http health checking for Origin Servers
[ https://issues.apache.org/jira/browse/TS-654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-654: - Fix Version/s: (was: 2.1.8) 2.1.9 Moving these out for v2.1.9 for now. > request for support of Layer7 http health checking for Origin Servers > - > > Key: TS-654 > URL: https://issues.apache.org/jira/browse/TS-654 > Project: Traffic Server > Issue Type: New Feature > Components: HTTP >Affects Versions: 2.1.5 >Reporter: Zhao Yongming > Fix For: 2.1.9 > > Attachments: Passive-L7-Health-Check.patch, TS-654-v2.patch > > > this ticket is for the L7 health checking project: > https://cwiki.apache.org/confluence/display/TS/HttpHealthCheck -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-726) Crash Report: DNSEntry::post in 2.1.7
[
https://issues.apache.org/jira/browse/TS-726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-726:
-
Fix Version/s: (was: 2.1.8)
2.1.9
Moving these out for v2.1.9 for now.
> Crash Report: DNSEntry::post in 2.1.7
> -
>
> Key: TS-726
> URL: https://issues.apache.org/jira/browse/TS-726
> Project: Traffic Server
> Issue Type: Bug
> Components: DNS
>Affects Versions: 2.1.7
> Environment: 2.1.7
>Reporter: Zhao Yongming
> Labels: crash
> Fix For: 2.1.9
>
>
> reported from user, for tracking.
> {code:none}
> NOTE: Traffic Server received Sig 11: Segmentation fault
> /usr/local/ts/bin/traffic_server - STACK TRACE:
> [0x4001c420]
> /usr/local/ts/bin/traffic_server(DNSEntry::post(DNSHandler*, HostEnt*,
> bool)+0x5d5)[0x82503e5]
> [0x0]
> /usr/local/ts/bin/traffic_server(EThread::process_event(Event*,
> int)+0x1ff)[0x8320e9f]
> /usr/local/ts/bin/traffic_server(EThread::execute()+0x4be)[0x83216be]
> /usr/local/ts/bin/traffic_server(main+0x1245)[0x8104505]
> /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe0)[0x4050]
> /usr/local/ts/bin/traffic_server[0x80bdec1]
> /usr/local/ts/bin/traffic_server[0x80bdec1]
> {code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-725) Crash Report: url_host_set in 2.1.6
[
https://issues.apache.org/jira/browse/TS-725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-725:
-
Fix Version/s: (was: 2.1.8)
2.1.9
Moving these out for v2.1.9 for now.
> Crash Report: url_host_set in 2.1.6
> ---
>
> Key: TS-725
> URL: https://issues.apache.org/jira/browse/TS-725
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
>Affects Versions: 2.1.6
>Reporter: Zhao Yongming
> Labels: crash
> Fix For: 2.1.9
>
>
> reported by user:
> {code:none}
> NOTE: Traffic Server received Sig 11: Segmentation fault
> /usr/local/ts/bin/traffic_server - STACK TRACE:
> [0x4001c420]
> /lib/tls/i686/cmov/libc.so.6(memcpy+0x15)[0x404a19b5]
> [0xf]
> /usr/local/ts/bin/traffic_server(url_host_set(HdrHeap*, URLImpl*, char
> const*, int, bool)+0x51)[0x8229631]
> NOTE: Traffic Server received Sig 11: Segmentation fault
> /usr/local/ts/bin/traffic_server - STACK TRACE:
> [0x4001c420]
> /lib/tls/i686/cmov/libc.so.6(memcpy+0x15)[0x404a19b5]
> [0xf]
> /usr/local/ts/bin/traffic_server(url_host_set(HdrHeap*, URLImpl*, char
> const*, int, bool)+0x51)[0x8229631]
> /usr/local/ts/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void
> (*)(HttpTransact::State*))+0xab)[0x816a8eb]
> /usr/local/ts/bin/traffic_server(HttpSM::state_read_client_request_header(int,
> void*)+0x321)[0x817acc1]
> /usr/local/ts/bin/traffic_server(HttpSM::main_handler(int,
> void*)+0x1a4)[0x8184894]
> /usr/local/ts/bin/traffic_server[0x82f880c]
> /usr/local/ts/bin/traffic_server(NetHandler::mainNetEvent(int,
> Event*)+0x4ce)[0x82edffe]
> /usr/local/ts/bin/traffic_server(EThread::process_event(Event*,
> int)+0x1ff)[0x83226bf]
> /usr/local/ts/bin/traffic_server(EThread::execute()+0x449)[0x8322e69]
> /usr/local/ts/bin/traffic_server[0x8321abc]
> /lib/tls/i686/cmov/libpthread.so.0[0x400284fb]
> /lib/tls/i686/cmov/libc.so.6(clone+0x5e)[0x40504e5e]
> /lib/tls/i686/cmov/libc.so.6(clone+0x5e)[0x40504e5e]
> [Mar 8 11:02:52.960] Manager {3080226496} ERROR:
> [LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig
> 11: Segmenta
> tion fault
> [Mar 8 11:02:52.960] Manager {3080226496} ERROR: (last system error 2: No
> such file or directory)
> [Mar 8 11:02:52.961] Manager {3080226496} ERROR: [Alarms::signalAlarm]
> Server Process was reset
> [Mar 8 11:02:52.961] Manager {3080226496} ERROR: (last system error 2: No
> such file or directory)
> [Mar 8 11:02:53.964] Manager {3080226496} NOTE: [LocalManager::startProxy]
> Launching ts process
> [TrafficServer] using root directory '/usr/local/ts'
> [Mar 8 11:02:53.973] Manager {3080226496} NOTE:
> [LocalManager::pollMgmtProcessServer] New process connecting fd '12'
> [Mar 8 11:02:53.973] Manager {3080226496} NOTE: [Alarms::signalAlarm] Server
> Process born
> [Mar 8 11:02:55.015] {1079500240} STATUS: opened
> /usr/local/ts/var/log/trafficserver/diags.log
> [Mar 8 11:02:55.015] {1079500240} NOTE: updated diags config
> [Mar 8 11:02:55.024] Server {1079500240} NOTE: cache clustering disabled
> [Mar 8 11:02:55.069] Server {1079500240} NOTE: cache clustering disabled
> [Mar 8 11:02:55.274] Server {1079500240} STATUS: Rolling disabled for
> /usr/local/ts/var/log/trafficserver/access.log.pipe
> [Mar 8 11:02:55.325] Server {1079500240} NOTE: logging initialized[7],
> logging_mode = 3
> [Mar 8 11:02:55.368] Server {1079500240} NOTE: traffic server running
> [Mar 8 11:02:58.584] Server {1096645520} NOTE: cache enabled
> {code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-738) 'make check` fails on x86
[
https://issues.apache.org/jira/browse/TS-738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-738:
-
Fix Version/s: (was: 2.1.8)
2.1.9
Moving these out for v2.1.9 for now.
> 'make check` fails on x86
> -
>
> Key: TS-738
> URL: https://issues.apache.org/jira/browse/TS-738
> Project: Traffic Server
> Issue Type: Bug
> Components: Build
>Affects Versions: 2.1.7
> Environment: ATS 2.1.7 on x86, gcc 4.5.2
>Reporter: Arno Toell
>Priority: Minor
> Fix For: 2.1.9
>
>
> The `make check' target of the Makefile fails to build on x86, AMD64 is fine.
> Output is (stripped to relevant parts only):
> {code}
> root@build:/home/arno/build-area/trafficserver-2.1.7-unstable# make check
> Making check in proxy/api/ts
> ...
> Create thread 59
> Create thread 60
> Create thread 61
> Create thread 62
> Create thread 63
> 0x08724a60 0x08724a60 0x08724a60
> FAIL: test_freelist
> PASS: test_arena
> test_List PASSED
> PASS: test_List
> =
> 1 of 4 tests failed
> Please report to d...@trafficserver.apache.org
> =
> {code}
> or
> {code}
> /bin/bash: line 5: 29956 Segmentation fault ${dir}$tst
> FAIL: test_freelist
> {code}
> or it even succeeds. This might be a race condition therefore. A backtrace
> from a core dump of a crashed {{LD_PRELOAD=./.libs/libtsutil.so.2
> ./.libs/test_freelist}} run shows:
> {code}
> Core was generated by `./.libs/test_freelist'.
> Program terminated with signal 11, Segmentation fault.
> #0 ink_freelist_new (f=0x94ff018) at ink_queue.cc:322
> 322 SET_FREELIST_POINTER_VERSION(next,
> *ADDRESS_OF_NEXT(TO_PTR(FREELIST_POINTER(item)), f->offset),
> (gdb) bt
> #0 ink_freelist_new (f=0x94ff018) at ink_queue.cc:322
> #1 0x08048996 in test (d=0x1f) at test_freelist.cc:50
> #2 0xf772f7b0 in start_thread () from /lib/libpthread.so.0
> #3 0xf74688fe in clone () from /lib/libc.so.6
> {code}
> I'm not familiar with ATS' data structures, but gdb indicates the following
> values:
> {code}
> $2 = {s = {pointer = 0x1f1f1f1f, version = 165962584}, data =
> 712803871161786143}
> (gdb) print f
> $3 = (InkFreeList *) 0x94ff018
> (gdb) print f->offset
> $4 = 0
> {code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-562) Custom paths for zlib, openssl, pcre don't work if in non-standard locations without adding --rpath
[ https://issues.apache.org/jira/browse/TS-562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-562: - Fix Version/s: (was: 2.1.8) 2.1.9 Moving these out for v2.1.9 for now. > Custom paths for zlib, openssl, pcre don't work if in non-standard locations > without adding --rpath > --- > > Key: TS-562 > URL: https://issues.apache.org/jira/browse/TS-562 > Project: Traffic Server > Issue Type: Improvement >Affects Versions: 2.1.5 > Environment: Linux >Reporter: Marcus Clyne >Assignee: Igor Brezac >Priority: Minor > Fix For: 2.1.9 > > > When compiling with custom paths for OpenSSL, PCRE, Zlib etc where the paths > are in non-standard locations, even if the configure script passes, the > libraries may not be linked if their lib path is not in the standard path > checked by ld. > The libraries can be found if extra linker options are passed like > -Wl,--rpath=/path/to/lib/dir, but it would make sense to add this > automatically on systems that support it if the path is passed to the > configure script using --with-openssl=... etc. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-679) Make SDK APIs use struct sockaddr_storage instead of "unsigned int" for IPs
[ https://issues.apache.org/jira/browse/TS-679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-679: - Fix Version/s: (was: 2.1.8) 2.1.9 Moving these out for v2.1.9 for now. > Make SDK APIs use struct sockaddr_storage instead of "unsigned int" for IPs > --- > > Key: TS-679 > URL: https://issues.apache.org/jira/browse/TS-679 > Project: Traffic Server > Issue Type: Improvement > Components: TS API >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom > Fix For: 2.1.9 > > > We should at a minimum make the necessary SDK changes to make the IP related > APIs IPv6 "compatible". Meaning, when we properly support IPv6, the APIs > should not have to change (again). > For some useful tips, see http://www.akkadia.org/drepper/userapi-ipv6.html -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-686) Change location in the APIs to be type specific
[ https://issues.apache.org/jira/browse/TS-686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-686: - Fix Version/s: (was: 2.1.8) 2.1.9 Moving these out for v2.1.9 for now. > Change location in the APIs to be type specific > --- > > Key: TS-686 > URL: https://issues.apache.org/jira/browse/TS-686 > Project: Traffic Server > Issue Type: Improvement > Components: TS API >Affects Versions: 2.1.6 >Reporter: Bryan Call >Priority: Minor > Fix For: 2.1.9 > > > Change arguments for APIs to use type specific combinations of buffer and > location instead of having generic types (e.g., TSMBuffer, TSMLoc) that can > be interchanged. > Leif and I talked about this more after I sent and email to dev@ and we > agreed that combining the buffer and location would be better unless there > are a lot of APIs that require then to passed in separately. Looking over > the APIs I don't think this is the case. > Also, we talked about possibly having request and response being the same > type, so there wouldn't be two version of some of the APIs (e.g., > TSHttpHdrUrlGet()) > Parts of my email to dev@: > Looking at the three APIs below it is hard to tell the location/offset > really point to: > tsapi TSReturnCode TSHttpTxnClientReqGet(TSHttpTxn txnp, TSMBuffer* > bufp, TSMLoc* offset); > tsapi TSReturnCode TSHttpHdrUrlGet(TSMBuffer bufp, TSMLoc offset, > TSMLoc* locp); > tsapi const char* TSUrlSchemeGet(TSMBuffer bufp, TSMLoc offset, int > *length); > In a specific case that happened last week a person was taking bufp and > offset from TSHttpTxnClientReqGet() and passing the values to > TSUrlSchemeGet(). Since it didn't give him compile errors he only saw > the problem when the server was under load and it would core dump. > One way to fix this would be to change locations to specific types. If > we want to take it a step further the buffer and location could be > combined and given a specific type simplifying the APIs. > Example of combining buffer and location and making specific types (IMO > cleaner): > tsapi TSReturnCode TSHttpTxnClientReqGet(TSHttpTxn txnp, TSRequest > *request); > tsapi TSReturnCode TSHttpHdrUrlGet(TSRequest request, TSUrl *url); > tsapi const char* TSUrlSchemeGet(TSUrl url, int *length); -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-739) Crash in ::write
[
https://issues.apache.org/jira/browse/TS-739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-739:
-
Fix Version/s: (was: 2.1.8)
2.1.9
Moving these out for v2.1.9 for now.
> Crash in ::write
>
>
> Key: TS-739
> URL: https://issues.apache.org/jira/browse/TS-739
> Project: Traffic Server
> Issue Type: Bug
>Reporter: Leif Hedstrom
>Priority: Critical
> Fix For: 2.1.9
>
>
> Opening another bug for this, it can still happen regardless of ccache on or
> off.
> My setup is fairly simple, mostly standard configs, but setup as a forward
> proxy. When pointing my browser to use ATS as the proxy, and I go to
> search.google.com and start typing in the search box, we sometimes segfault.
> {code}
> (gdb) bt
> #0 0x003f2e60e1fd in write () from /lib64/libpthread.so.0
> #1 0x006102d8 in write (this=0x7fffe000bd70, towrite=1260,
> wattempted=@0x76c11c78, total_wrote=@0x76c11c80,
> buf=) at
> ../../iocore/eventsystem/P_UnixSocketManager.h:207
> #2 UnixNetVConnection::load_buffer_and_write (this=0x7fffe000bd70,
> towrite=1260, wattempted=@0x76c11c78,
> total_wrote=@0x76c11c80, buf=) at
> UnixNetVConnection.cc:833
> #3 0x0061443b in write_to_net_io (nh=0x76d15628,
> vc=0x7fffe000bd70, thread=0x76d14010)
> at UnixNetVConnection.cc:439
> #4 0x0060c42a in NetHandler::mainNetEvent (this=0x76d15628,
> event=, e=)
> at UnixNet.cc:419
> #5 0x006325e4 in handleEvent (this=0x76d14010, e=0xe846a0,
> calling_code=5) at I_Continuation.h:146
> #6 EThread::process_event (this=0x76d14010, e=0xe846a0, calling_code=5)
> at UnixEThread.cc:140
> #7 0x00632f73 in EThread::execute (this=0x76d14010) at
> UnixEThread.cc:262
> #8 0x0063142a in spawn_thread_internal (a=0xe770f0) at Thread.cc:85
> #9 0x003f2e6068e0 in start_thread () from /lib64/libpthread.so.0
> #10 0x003f2dee0c9d in clone () from /lib64/libc.so.6
> #11 0x in ?? ()
> (gdb) frame 1
> #1 0x006102d8 in write (this=0x7fffe000bd70, towrite=1260,
> wattempted=@0x76c11c78, total_wrote=@0x76c11c80,
> buf=) at
> ../../iocore/eventsystem/P_UnixSocketManager.h:207
> 207 if (likely((r =::write(fd, buf, size)) >= 0))
> (gdb) print fd
> $3 = 45
> (gdb) print buf
> $4 = (void *) 0x7fffc9860b14
> (gdb) print size
> $5 =
> (gdb) frame 2
> #2 UnixNetVConnection::load_buffer_and_write (this=0x7fffe000bd70,
> towrite=1260, wattempted=@0x76c11c78,
> total_wrote=@0x76c11c80, buf=) at
> UnixNetVConnection.cc:833
> 833 r = socketManager.write(con.fd, tiovec[0].iov_base,
> tiovec[0].iov_len);
> (gdb) print con.fd
> $6 = 45
> (gdb) print tiovec[0].iov_base
> $7 = (void *) 0x7fffc9860b14
> (gdb) print tiovec[0].iov_len
> $8 = 1260
> (gdb) frame 1
> #1 0x006102d8 in write (this=0x7fffe000bd70, towrite=1260,
> wattempted=@0x76c11c78, total_wrote=@0x76c11c80,
> buf=) at
> ../../iocore/eventsystem/P_UnixSocketManager.h:207
> 207 if (likely((r =::write(fd, buf, size)) >= 0))
> (gdb) print buf
> $9 = (void *) 0x7fffc9860b14
> (gdb) print *buf
> Attempt to dereference a generic pointer.
> (gdb) frame 2
> #2 UnixNetVConnection::load_buffer_and_write (this=0x7fffe000bd70,
> towrite=1260, wattempted=@0x76c11c78,
> total_wrote=@0x76c11c80, buf=) at
> UnixNetVConnection.cc:833
> 833 r = socketManager.write(con.fd, tiovec[0].iov_base,
> tiovec[0].iov_len);
> (gdb) print tiovec[0].iov_base
> $10 = (void *) 0x7fffc9860b14
> (gdb) print *((char*)tiovec[0].iov_base)
> $11 = 120 'x'
> (gdb) frame 1
> #1 0x006102d8 in write (this=0x7fffe000bd70, towrite=1260,
> wattempted=@0x76c11c78, total_wrote=@0x76c11c80,
> buf=) at
> ../../iocore/eventsystem/P_UnixSocketManager.h:207
> 207 if (likely((r =::write(fd, buf, size)) >= 0))
> (gdb) print *((char*)buf)
> $12 = 120 'x'
> {code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-724) disk IO balance in v2.1.7
[
https://issues.apache.org/jira/browse/TS-724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-724:
-
Fix Version/s: (was: 2.1.8)
2.1.9
Moving these out for v2.1.9 for now.
> disk IO balance in v2.1.7
> -
>
> Key: TS-724
> URL: https://issues.apache.org/jira/browse/TS-724
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.1.7
> Environment: reporting from users, and confirm within my testing evn.
> v2.1.7 only
>Reporter: Zhao Yongming
>Priority: Critical
> Fix For: 2.1.9
>
>
> when multiple disk enabled, the disk IO will show much diff in v2.1.7, here
> is my result on a 7 disk system result:
> {code:none}
> [root@cache189 ~]# iostat -x 5
> Linux 2.6.18-164.11.1.el5 (cache189.cn8) 03/29/2011
> avg-cpu: %user %nice %system %iowait %steal %idle
>0.510.000.541.770.00 97.18
> Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz
> avgqu-sz await svctm %util
> sdb 0.00 0.00 11.80 0.00 360.80 0.0030.58
> 0.075.73 5.56 6.56
> sdc 0.00 0.00 12.00 0.00 413.80 0.0034.48
> 0.075.42 5.30 6.36
> sdd 0.00 0.00 11.60 1.40 375.80 820.8092.05
> 0.075.06 4.66 6.06
> sde 0.00 0.00 13.00 14.00 722.60 8192.00 330.17
> 0.124.50 2.99 8.06
> sdf 0.00 0.00 14.60 0.00 579.40 0.0039.68
> 0.117.48 7.04 10.28
> sdg 0.00 0.00 49.20 0.00 18268.60 0.00 371.31
> 0.081.66 0.54 2.66
> sdb 0.00 0.00 11.60 0.00 253.60 0.0021.86
> 0.065.45 5.12 5.94
> sdc 0.00 0.00 15.80 0.00 738.20 0.0046.72
> 0.085.22 4.76 7.52
> sdd 0.00 0.00 10.80 0.00 728.40 0.0067.44
> 0.065.81 5.48 5.92
> sde 0.00 0.00 11.60 2.00 377.60 1027.20 103.29
> 0.075.18 4.75 6.46
> sdf 0.00 0.00 14.60 0.00 473.60 0.0032.44
> 0.095.90 5.78 8.44
> sdg 0.00 0.00 87.00 0.00 37454.80 0.00 430.51
> 0.374.26 0.82 7.12
> sdb 0.00 0.00 15.80 0.00 786.40 0.0049.77
> 0.106.56 5.76 9.10
> sdc 0.00 0.00 10.20 1.60 217.60 911.2095.66
> 0.064.93 4.51 5.32
> sdd 0.00 0.00 13.00 0.00 665.00 0.0051.15
> 0.086.12 5.80 7.54
> sde 0.00 0.00 11.60 0.00 419.40 0.0036.16
> 0.065.43 5.17 6.00
> sdf 0.00 0.00 11.00 1.40 315.00 826.8092.08
> 0.075.27 4.89 6.06
> sdg 0.00 0.00 27.00 0.00 8629.60 0.00 319.61
> 0.020.87 0.37 1.00
> sdb 0.00 0.00 12.80 0.00 380.00 0.0029.69
> 0.075.22 4.98 6.38
> sdc 0.00 0.00 14.80 0.00 495.80 0.0033.50
> 0.085.39 5.19 7.68
> sdd 0.00 0.00 10.40 0.00 267.40 0.0025.71
> 0.065.87 5.46 5.68
> sde 0.00 0.00 12.20 0.00 691.20 0.0056.66
> 0.075.93 5.48 6.68
> sdf 0.00 0.00 11.80 0.00 544.40 0.0046.14
> 0.075.83 5.63 6.64
> sdg 0.00 0.00 57.00 0.00 22033.00 0.00 386.54
> 0.061.07 0.38 2.16
> sdb 0.00 0.00 13.20 0.00 546.40 0.0041.39
> 0.085.73 5.73 7.56
> sdc 0.00 0.00 14.00 0.00 583.60 0.0041.69
> 0.085.57 5.34 7.48
> sdd 0.00 0.00 12.80 0.00 639.20 0.0049.94
> 0.075.61 5.14 6.58
> sde 0.00 0.00 12.40 0.00 403.20 0.0032.52
> 0.26 20.98 11.03 13.68
> sdf 0.00 0.00 15.00 0.00 475.80 0.0031.72
> 0.095.71 5.37 8.06
> sdg 0.00 0.00 91.80 0.00 39239.00 0.00 427.44
> 0.576.24 0.76 6.94
> sdb 0.00 0.00 10.60 0.00 326.60 0.0030.81
> 0.065.60 5.04 5.34
> sdc 0.00 0.00 12.80 0.00 644.40 0.0050.34
> 0.075.72 5.27 6.74
> sdd 0.00 0.00 14.80 0.00 624.00 0.0042.16
> 0.085.61 5.50 8.14
> sde 0.00 0.00 9.20 0.00 283.00 0.0030.76
> 0.055.83 5.67 5.22
> sdf 0.00 0.00 13.40 0.00 578.00 0.0043.13
> 0.075.39 5.15 6.90
> sdg 0.00 0.00 12.80 0.
[jira] [Updated] (TS-718) can not reuse SSL connections on RHEL5/CentOS5
[
https://issues.apache.org/jira/browse/TS-718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-718:
-
Attachment: TS-718-v2.patch
Slight cleanup, and a few important changes.
> can not reuse SSL connections on RHEL5/CentOS5
> --
>
> Key: TS-718
> URL: https://issues.apache.org/jira/browse/TS-718
> Project: Traffic Server
> Issue Type: Bug
> Components: SSL
>Affects Versions: 2.1.7
> Environment: RHEL5 system with TS 2.1.6 2.1.7
> compared with Apache httpd
>Reporter: Zhao Yongming
>Assignee: qianshi
> Fix For: 2.1.8
>
> Attachments: TS-718-v2.patch, TS-718.patch
>
>
> when with apache httpd default mod_ssl:
> {noformat}
> [root@ts1 httpd]# echo | openssl s_client -reconnect -connect localhost:443
> 2>&1
> CONNECTED(0003)
> depth=0
> /C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ts1.test.cnz.alimama.com/emailAddress=r...@ts1.test.cnz.alimama.com
> verify error:num=18:self signed certificate
> verify return:1
> depth=0
> /C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ts1.test.cnz.alimama.com/emailAddress=r...@ts1.test.cnz.alimama.com
> verify return:1
> ---
> Certificate chain
> 0
> s:/C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ts1.test.cnz.alimama.com/emailAddress=r...@ts1.test.cnz.alimama.com
>
> i:/C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ts1.test.cnz.alimama.com/emailAddress=r...@ts1.test.cnz.alimama.com
> ---
> Server certificate
> -BEGIN CERTIFICATE-
> MIIDSzCCArSgAwIBAgICUWcwDQYJKoZIhvcNAQEFBQAwgcExCzAJBgNVBAYTAi0t
> MRIwEAYDVQQIDAlTb21lU3RhdGUxETAPBgNVBAcMCFNvbWVDaXR5MRkwFwYDVQQK
> DBBTb21lT3JnYW5pemF0aW9uMR8wHQYDVQQLDBZTb21lT3JnYW5pemF0aW9uYWxV
> bml0MSEwHwYDVQQDDBh0czEudGVzdC5jbnouYWxpbWFtYS5jb20xLDAqBgkqhkiG
> 9w0BCQEWHXJvb3RAdHMxLnRlc3QuY256LmFsaW1hbWEuY29tMB4XDTExMDMyNDEw
> Mjk1MVoXDTEyMDMyMzEwMjk1MVowgcExCzAJBgNVBAYTAi0tMRIwEAYDVQQIDAlT
> b21lU3RhdGUxETAPBgNVBAcMCFNvbWVDaXR5MRkwFwYDVQQKDBBTb21lT3JnYW5p
> emF0aW9uMR8wHQYDVQQLDBZTb21lT3JnYW5pemF0aW9uYWxVbml0MSEwHwYDVQQD
> DBh0czEudGVzdC5jbnouYWxpbWFtYS5jb20xLDAqBgkqhkiG9w0BCQEWHXJvb3RA
> dHMxLnRlc3QuY256LmFsaW1hbWEuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB
> iQKBgQDg0xr6MMfTUooenmxTyXiaSiHMfrkbGGhjgE0slP1iWfBf62Qal1daSSb8
> hSSFCZI78RWAp/bcadHGPo43xDWBmohLyTnlWksKKcbSJ9atdijC2L2CJNXiWgKC
> cu+2jOTLAw0YJVOufuJmm8QaqmHl4y3UGE626VDN8lPGBCrQcwIDAQABo1AwTjAd
> BgNVHQ4EFgQUIAfaVLkaRWgWp+zxPtp0bWfbbsgwHwYDVR0jBBgwFoAUIAfaVLka
> RWgWp+zxPtp0bWfbbsgwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQUFAAOBgQA1
> qYMZB0MuCQz2yCAx25C3+UtoZuxdmQxekmOPjtRAm2CRccW7r0ne57BcVU79Qk2s
> 6KTU4fO7lJ1tz49ZkX5zts5WuqsWDSb4cfyDb3ybubcZwUu+eSkqVkx/7GAuVgcl
> weoLXdgpQ779T45SovOR212BXQpYI0piMDNIB9p0mA==
> -END CERTIFICATE-
> subject=/C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ts1.test.cnz.alimama.com/emailAddress=r...@ts1.test.cnz.alimama.com
> issuer=/C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ts1.test.cnz.alimama.com/emailAddress=r...@ts1.test.cnz.alimama.com
> ---
> No client certificate CA names sent
> ---
> SSL handshake has read 1418 bytes and written 319 bytes
> ---
> New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
> Server public key is 1024 bit
> Secure Renegotiation IS supported
> Compression: NONE
> Expansion: NONE
> SSL-Session:
> Protocol : TLSv1
> Cipher: DHE-RSA-AES256-SHA
> Session-ID:
> 8A72957E09AF60AD3807C1D06CE3F9BD88914886B7F1F646B03E8BDA783FAB8B
> Session-ID-ctx:
> Master-Key:
> 42808C5CDF016480F1BC7FF6F764A4886886E430F8E23400D82A9E6A6DE377A30369541E52BA06E1DC878F18DAFC2ECA
> Key-Arg : None
> Krb5 Principal: None
> Start Time: 1300962675
> Timeout : 300 (sec)
> Verify return code: 18 (self signed certificate)
> ---
> drop connection and then reconnect
> CONNECTED(0003)
> ---
> Reused, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
> Secure Renegotiation IS supported
> Compression: zlib compression
> Expansion: zlib compression
> SSL-Session:
> Protocol : TLSv1
> Cipher: DHE-RSA-AES256-SHA
> Session-ID:
> 8A72957E09AF60AD3807C1D06CE3F9BD88914886B7F1F646B03E8BDA783FAB8B
> Session-ID-ctx:
> Master-Key:
> 42808C5CDF016480F1BC7FF6F764A4886886E430F8E23400D82A9E6A6DE377A30369541E52BA06E1DC878F18DAFC2ECA
> Key-Arg : None
> Krb5 Principal: None
>Compression: 1 (zlib compression)
> Start Time: 1300962675
> Timeout : 300 (sec)
> Verify return code: 18 (self signed certificate)
> ---
> drop connection and then reconnect
> CONNECTED(0003)
> ---
> Reused, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
> Secure Renegotiation IS supported
> Compression: zlib compression
> Expansion: zlib compression
> SSL-Sessio
[jira] [Commented] (TS-718) can not reuse SSL connections on RHEL5/CentOS5
[
https://issues.apache.org/jira/browse/TS-718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021817#comment-13021817
]
Leif Hedstrom commented on TS-718:
--
So, I'm a little confused about this patch, and have some concerns.
1) First of all, I was never able to reproduce the problem with SSL sessions
not being reused. The default in OpenSSL seems to be to use the "internal"
server session handling. What's even more confusing is that even if I
explicitly try to turn off the session reuse cache, OpenSSL still seems to do
the reuse (according to that openssl s_client command at least). And even more
confusing is that I don't see it trigger the Debug() code (and I debugged it in
gdb too, I don't see the callbacks being called when doing the tests).
2) I'm attaching a slightly modified patch, which cleans up things a little bit
(but, see #3 and #4 for more fixes that I think needs to be done).
3) I don't think the usage of the ink_hash is correct. I do not think it's
atomic like the code seems to assume, i.e. you can't have two threads adding or
deleting from the hash at the same time. Some sort of locking would be required
around this, I'm pretty sure. I.e. we'd have to add a g_session_lock or
something like that, and do appropriate locking around all additions / deletes
from the hash.
4) I think we should add an additional configuration option, call it
proxy.config.ssl.session_reuse, and let it take the following values (for now,
can be added with more options later);
0 - Turn off all session reuse (SSL_SESS_CACHE_OFF)
1 - Turn on normal server cache (SSL_SESS_CACHE_SERVER). This should be the
default.
2 - Enable the hash based session cache
(SSL_SESS_CACHE_SERVER|SSL_SESS_CACHE_NO_INTERNAL)
I have not done any attempts to fix / implement #3 and #4 above, wanted to
discuss it here first.
> can not reuse SSL connections on RHEL5/CentOS5
> --
>
> Key: TS-718
> URL: https://issues.apache.org/jira/browse/TS-718
> Project: Traffic Server
> Issue Type: Bug
> Components: SSL
>Affects Versions: 2.1.7
> Environment: RHEL5 system with TS 2.1.6 2.1.7
> compared with Apache httpd
>Reporter: Zhao Yongming
>Assignee: qianshi
> Fix For: 2.1.8
>
> Attachments: TS-718-v2.patch, TS-718.patch
>
>
> when with apache httpd default mod_ssl:
> {noformat}
> [root@ts1 httpd]# echo | openssl s_client -reconnect -connect localhost:443
> 2>&1
> CONNECTED(0003)
> depth=0
> /C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ts1.test.cnz.alimama.com/emailAddress=r...@ts1.test.cnz.alimama.com
> verify error:num=18:self signed certificate
> verify return:1
> depth=0
> /C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ts1.test.cnz.alimama.com/emailAddress=r...@ts1.test.cnz.alimama.com
> verify return:1
> ---
> Certificate chain
> 0
> s:/C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ts1.test.cnz.alimama.com/emailAddress=r...@ts1.test.cnz.alimama.com
>
> i:/C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ts1.test.cnz.alimama.com/emailAddress=r...@ts1.test.cnz.alimama.com
> ---
> Server certificate
> -BEGIN CERTIFICATE-
> MIIDSzCCArSgAwIBAgICUWcwDQYJKoZIhvcNAQEFBQAwgcExCzAJBgNVBAYTAi0t
> MRIwEAYDVQQIDAlTb21lU3RhdGUxETAPBgNVBAcMCFNvbWVDaXR5MRkwFwYDVQQK
> DBBTb21lT3JnYW5pemF0aW9uMR8wHQYDVQQLDBZTb21lT3JnYW5pemF0aW9uYWxV
> bml0MSEwHwYDVQQDDBh0czEudGVzdC5jbnouYWxpbWFtYS5jb20xLDAqBgkqhkiG
> 9w0BCQEWHXJvb3RAdHMxLnRlc3QuY256LmFsaW1hbWEuY29tMB4XDTExMDMyNDEw
> Mjk1MVoXDTEyMDMyMzEwMjk1MVowgcExCzAJBgNVBAYTAi0tMRIwEAYDVQQIDAlT
> b21lU3RhdGUxETAPBgNVBAcMCFNvbWVDaXR5MRkwFwYDVQQKDBBTb21lT3JnYW5p
> emF0aW9uMR8wHQYDVQQLDBZTb21lT3JnYW5pemF0aW9uYWxVbml0MSEwHwYDVQQD
> DBh0czEudGVzdC5jbnouYWxpbWFtYS5jb20xLDAqBgkqhkiG9w0BCQEWHXJvb3RA
> dHMxLnRlc3QuY256LmFsaW1hbWEuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB
> iQKBgQDg0xr6MMfTUooenmxTyXiaSiHMfrkbGGhjgE0slP1iWfBf62Qal1daSSb8
> hSSFCZI78RWAp/bcadHGPo43xDWBmohLyTnlWksKKcbSJ9atdijC2L2CJNXiWgKC
> cu+2jOTLAw0YJVOufuJmm8QaqmHl4y3UGE626VDN8lPGBCrQcwIDAQABo1AwTjAd
> BgNVHQ4EFgQUIAfaVLkaRWgWp+zxPtp0bWfbbsgwHwYDVR0jBBgwFoAUIAfaVLka
> RWgWp+zxPtp0bWfbbsgwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQUFAAOBgQA1
> qYMZB0MuCQz2yCAx25C3+UtoZuxdmQxekmOPjtRAm2CRccW7r0ne57BcVU79Qk2s
> 6KTU4fO7lJ1tz49ZkX5zts5WuqsWDSb4cfyDb3ybubcZwUu+eSkqVkx/7GAuVgcl
> weoLXdgpQ779T45SovOR212BXQpYI0piMDNIB9p0mA==
> -END CERTIFICATE-
> subject=/C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ts1.test.cnz.alimama.com/emailAddress=r...@ts1.test.cnz.alimama.com
> issuer=/C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ts1.test.cnz.alimama.com/emailAddress=r...@ts1.test.cnz.alimama.com
> ---
> No client certificate
[jira] [Commented] (TS-718) can not reuse SSL connections on RHEL5/CentOS5
[
https://issues.apache.org/jira/browse/TS-718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021830#comment-13021830
]
Leif Hedstrom commented on TS-718:
--
Also, for #4 above, for setting 1, we should use this API to set the internal
session cache size:
SSL_CTX_sess_set_cache_size()
this should use the same setting as added in the original patch (i.e.
proxy.config.ssl.max.sessions).
I'm still very, very confused as to why the hash is necessary at all, is there
something broken with the internal session cache in RHEL5??
> can not reuse SSL connections on RHEL5/CentOS5
> --
>
> Key: TS-718
> URL: https://issues.apache.org/jira/browse/TS-718
> Project: Traffic Server
> Issue Type: Bug
> Components: SSL
>Affects Versions: 2.1.7
> Environment: RHEL5 system with TS 2.1.6 2.1.7
> compared with Apache httpd
>Reporter: Zhao Yongming
>Assignee: qianshi
> Fix For: 2.1.8
>
> Attachments: TS-718-v2.patch, TS-718.patch
>
>
> when with apache httpd default mod_ssl:
> {noformat}
> [root@ts1 httpd]# echo | openssl s_client -reconnect -connect localhost:443
> 2>&1
> CONNECTED(0003)
> depth=0
> /C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ts1.test.cnz.alimama.com/emailAddress=r...@ts1.test.cnz.alimama.com
> verify error:num=18:self signed certificate
> verify return:1
> depth=0
> /C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ts1.test.cnz.alimama.com/emailAddress=r...@ts1.test.cnz.alimama.com
> verify return:1
> ---
> Certificate chain
> 0
> s:/C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ts1.test.cnz.alimama.com/emailAddress=r...@ts1.test.cnz.alimama.com
>
> i:/C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ts1.test.cnz.alimama.com/emailAddress=r...@ts1.test.cnz.alimama.com
> ---
> Server certificate
> -BEGIN CERTIFICATE-
> MIIDSzCCArSgAwIBAgICUWcwDQYJKoZIhvcNAQEFBQAwgcExCzAJBgNVBAYTAi0t
> MRIwEAYDVQQIDAlTb21lU3RhdGUxETAPBgNVBAcMCFNvbWVDaXR5MRkwFwYDVQQK
> DBBTb21lT3JnYW5pemF0aW9uMR8wHQYDVQQLDBZTb21lT3JnYW5pemF0aW9uYWxV
> bml0MSEwHwYDVQQDDBh0czEudGVzdC5jbnouYWxpbWFtYS5jb20xLDAqBgkqhkiG
> 9w0BCQEWHXJvb3RAdHMxLnRlc3QuY256LmFsaW1hbWEuY29tMB4XDTExMDMyNDEw
> Mjk1MVoXDTEyMDMyMzEwMjk1MVowgcExCzAJBgNVBAYTAi0tMRIwEAYDVQQIDAlT
> b21lU3RhdGUxETAPBgNVBAcMCFNvbWVDaXR5MRkwFwYDVQQKDBBTb21lT3JnYW5p
> emF0aW9uMR8wHQYDVQQLDBZTb21lT3JnYW5pemF0aW9uYWxVbml0MSEwHwYDVQQD
> DBh0czEudGVzdC5jbnouYWxpbWFtYS5jb20xLDAqBgkqhkiG9w0BCQEWHXJvb3RA
> dHMxLnRlc3QuY256LmFsaW1hbWEuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB
> iQKBgQDg0xr6MMfTUooenmxTyXiaSiHMfrkbGGhjgE0slP1iWfBf62Qal1daSSb8
> hSSFCZI78RWAp/bcadHGPo43xDWBmohLyTnlWksKKcbSJ9atdijC2L2CJNXiWgKC
> cu+2jOTLAw0YJVOufuJmm8QaqmHl4y3UGE626VDN8lPGBCrQcwIDAQABo1AwTjAd
> BgNVHQ4EFgQUIAfaVLkaRWgWp+zxPtp0bWfbbsgwHwYDVR0jBBgwFoAUIAfaVLka
> RWgWp+zxPtp0bWfbbsgwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQUFAAOBgQA1
> qYMZB0MuCQz2yCAx25C3+UtoZuxdmQxekmOPjtRAm2CRccW7r0ne57BcVU79Qk2s
> 6KTU4fO7lJ1tz49ZkX5zts5WuqsWDSb4cfyDb3ybubcZwUu+eSkqVkx/7GAuVgcl
> weoLXdgpQ779T45SovOR212BXQpYI0piMDNIB9p0mA==
> -END CERTIFICATE-
> subject=/C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ts1.test.cnz.alimama.com/emailAddress=r...@ts1.test.cnz.alimama.com
> issuer=/C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ts1.test.cnz.alimama.com/emailAddress=r...@ts1.test.cnz.alimama.com
> ---
> No client certificate CA names sent
> ---
> SSL handshake has read 1418 bytes and written 319 bytes
> ---
> New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
> Server public key is 1024 bit
> Secure Renegotiation IS supported
> Compression: NONE
> Expansion: NONE
> SSL-Session:
> Protocol : TLSv1
> Cipher: DHE-RSA-AES256-SHA
> Session-ID:
> 8A72957E09AF60AD3807C1D06CE3F9BD88914886B7F1F646B03E8BDA783FAB8B
> Session-ID-ctx:
> Master-Key:
> 42808C5CDF016480F1BC7FF6F764A4886886E430F8E23400D82A9E6A6DE377A30369541E52BA06E1DC878F18DAFC2ECA
> Key-Arg : None
> Krb5 Principal: None
> Start Time: 1300962675
> Timeout : 300 (sec)
> Verify return code: 18 (self signed certificate)
> ---
> drop connection and then reconnect
> CONNECTED(0003)
> ---
> Reused, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
> Secure Renegotiation IS supported
> Compression: zlib compression
> Expansion: zlib compression
> SSL-Session:
> Protocol : TLSv1
> Cipher: DHE-RSA-AES256-SHA
> Session-ID:
> 8A72957E09AF60AD3807C1D06CE3F9BD88914886B7F1F646B03E8BDA783FAB8B
> Session-ID-ctx:
> Master-Key:
> 42808C5CDF016480F1BC7FF6F764A4886886E430F8E23400D82A9E6A6DE377A30369541E52BA06E1DC878F18DAFC2ECA
> Key-Arg : None
> Krb5 Principal: None
>Compression: 1 (zlib co
[jira] [Commented] (TS-718) can not reuse SSL connections on RHEL5/CentOS5
[
https://issues.apache.org/jira/browse/TS-718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021833#comment-13021833
]
Leif Hedstrom commented on TS-718:
--
Also, we might want to add some statistics around this, to show session cache
hit ratios. E.g. (for setting 1, using internal cache) we'd use
SSL_CTX_sess_number()
SSL_CTX_sess_hits()
SSL_CTX_sess_misses()
SSL_CTX_sess_timeouts()
SSL_CTX_sess_cache_full()
> can not reuse SSL connections on RHEL5/CentOS5
> --
>
> Key: TS-718
> URL: https://issues.apache.org/jira/browse/TS-718
> Project: Traffic Server
> Issue Type: Bug
> Components: SSL
>Affects Versions: 2.1.7
> Environment: RHEL5 system with TS 2.1.6 2.1.7
> compared with Apache httpd
>Reporter: Zhao Yongming
>Assignee: qianshi
> Fix For: 2.1.8
>
> Attachments: TS-718-v2.patch, TS-718.patch
>
>
> when with apache httpd default mod_ssl:
> {noformat}
> [root@ts1 httpd]# echo | openssl s_client -reconnect -connect localhost:443
> 2>&1
> CONNECTED(0003)
> depth=0
> /C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ts1.test.cnz.alimama.com/emailAddress=r...@ts1.test.cnz.alimama.com
> verify error:num=18:self signed certificate
> verify return:1
> depth=0
> /C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ts1.test.cnz.alimama.com/emailAddress=r...@ts1.test.cnz.alimama.com
> verify return:1
> ---
> Certificate chain
> 0
> s:/C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ts1.test.cnz.alimama.com/emailAddress=r...@ts1.test.cnz.alimama.com
>
> i:/C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ts1.test.cnz.alimama.com/emailAddress=r...@ts1.test.cnz.alimama.com
> ---
> Server certificate
> -BEGIN CERTIFICATE-
> MIIDSzCCArSgAwIBAgICUWcwDQYJKoZIhvcNAQEFBQAwgcExCzAJBgNVBAYTAi0t
> MRIwEAYDVQQIDAlTb21lU3RhdGUxETAPBgNVBAcMCFNvbWVDaXR5MRkwFwYDVQQK
> DBBTb21lT3JnYW5pemF0aW9uMR8wHQYDVQQLDBZTb21lT3JnYW5pemF0aW9uYWxV
> bml0MSEwHwYDVQQDDBh0czEudGVzdC5jbnouYWxpbWFtYS5jb20xLDAqBgkqhkiG
> 9w0BCQEWHXJvb3RAdHMxLnRlc3QuY256LmFsaW1hbWEuY29tMB4XDTExMDMyNDEw
> Mjk1MVoXDTEyMDMyMzEwMjk1MVowgcExCzAJBgNVBAYTAi0tMRIwEAYDVQQIDAlT
> b21lU3RhdGUxETAPBgNVBAcMCFNvbWVDaXR5MRkwFwYDVQQKDBBTb21lT3JnYW5p
> emF0aW9uMR8wHQYDVQQLDBZTb21lT3JnYW5pemF0aW9uYWxVbml0MSEwHwYDVQQD
> DBh0czEudGVzdC5jbnouYWxpbWFtYS5jb20xLDAqBgkqhkiG9w0BCQEWHXJvb3RA
> dHMxLnRlc3QuY256LmFsaW1hbWEuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB
> iQKBgQDg0xr6MMfTUooenmxTyXiaSiHMfrkbGGhjgE0slP1iWfBf62Qal1daSSb8
> hSSFCZI78RWAp/bcadHGPo43xDWBmohLyTnlWksKKcbSJ9atdijC2L2CJNXiWgKC
> cu+2jOTLAw0YJVOufuJmm8QaqmHl4y3UGE626VDN8lPGBCrQcwIDAQABo1AwTjAd
> BgNVHQ4EFgQUIAfaVLkaRWgWp+zxPtp0bWfbbsgwHwYDVR0jBBgwFoAUIAfaVLka
> RWgWp+zxPtp0bWfbbsgwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQUFAAOBgQA1
> qYMZB0MuCQz2yCAx25C3+UtoZuxdmQxekmOPjtRAm2CRccW7r0ne57BcVU79Qk2s
> 6KTU4fO7lJ1tz49ZkX5zts5WuqsWDSb4cfyDb3ybubcZwUu+eSkqVkx/7GAuVgcl
> weoLXdgpQ779T45SovOR212BXQpYI0piMDNIB9p0mA==
> -END CERTIFICATE-
> subject=/C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ts1.test.cnz.alimama.com/emailAddress=r...@ts1.test.cnz.alimama.com
> issuer=/C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ts1.test.cnz.alimama.com/emailAddress=r...@ts1.test.cnz.alimama.com
> ---
> No client certificate CA names sent
> ---
> SSL handshake has read 1418 bytes and written 319 bytes
> ---
> New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
> Server public key is 1024 bit
> Secure Renegotiation IS supported
> Compression: NONE
> Expansion: NONE
> SSL-Session:
> Protocol : TLSv1
> Cipher: DHE-RSA-AES256-SHA
> Session-ID:
> 8A72957E09AF60AD3807C1D06CE3F9BD88914886B7F1F646B03E8BDA783FAB8B
> Session-ID-ctx:
> Master-Key:
> 42808C5CDF016480F1BC7FF6F764A4886886E430F8E23400D82A9E6A6DE377A30369541E52BA06E1DC878F18DAFC2ECA
> Key-Arg : None
> Krb5 Principal: None
> Start Time: 1300962675
> Timeout : 300 (sec)
> Verify return code: 18 (self signed certificate)
> ---
> drop connection and then reconnect
> CONNECTED(0003)
> ---
> Reused, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
> Secure Renegotiation IS supported
> Compression: zlib compression
> Expansion: zlib compression
> SSL-Session:
> Protocol : TLSv1
> Cipher: DHE-RSA-AES256-SHA
> Session-ID:
> 8A72957E09AF60AD3807C1D06CE3F9BD88914886B7F1F646B03E8BDA783FAB8B
> Session-ID-ctx:
> Master-Key:
> 42808C5CDF016480F1BC7FF6F764A4886886E430F8E23400D82A9E6A6DE377A30369541E52BA06E1DC878F18DAFC2ECA
> Key-Arg : None
> Krb5 Principal: None
>Compression: 1 (zlib compression)
> Start Time: 1300962675
> Timeout : 300 (sec)
> Verify return code: 18 (self signed certific
[jira] [Commented] (TS-718) can not reuse SSL connections on RHEL5/CentOS5
[
https://issues.apache.org/jira/browse/TS-718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021836#comment-13021836
]
Leif Hedstrom commented on TS-718:
--
One more suggestions: Lets rename proxy.config.ssl.max.sessions to be
proxy.config.ssl.session_cache.size .
So, we'll have
proxy.config.ssl.session_cache
proxy.config.ssl.session_cache.lifetime
proxy.config.ssl.session_cache.size
Where the first option is the new option to control which mode session cache is
in (so ignore my previous suggestion above). This makes all the session related
option grouped together nicely.
> can not reuse SSL connections on RHEL5/CentOS5
> --
>
> Key: TS-718
> URL: https://issues.apache.org/jira/browse/TS-718
> Project: Traffic Server
> Issue Type: Bug
> Components: SSL
>Affects Versions: 2.1.7
> Environment: RHEL5 system with TS 2.1.6 2.1.7
> compared with Apache httpd
>Reporter: Zhao Yongming
>Assignee: qianshi
> Fix For: 2.1.8
>
> Attachments: TS-718-v2.patch, TS-718.patch
>
>
> when with apache httpd default mod_ssl:
> {noformat}
> [root@ts1 httpd]# echo | openssl s_client -reconnect -connect localhost:443
> 2>&1
> CONNECTED(0003)
> depth=0
> /C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ts1.test.cnz.alimama.com/emailAddress=r...@ts1.test.cnz.alimama.com
> verify error:num=18:self signed certificate
> verify return:1
> depth=0
> /C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ts1.test.cnz.alimama.com/emailAddress=r...@ts1.test.cnz.alimama.com
> verify return:1
> ---
> Certificate chain
> 0
> s:/C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ts1.test.cnz.alimama.com/emailAddress=r...@ts1.test.cnz.alimama.com
>
> i:/C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ts1.test.cnz.alimama.com/emailAddress=r...@ts1.test.cnz.alimama.com
> ---
> Server certificate
> -BEGIN CERTIFICATE-
> MIIDSzCCArSgAwIBAgICUWcwDQYJKoZIhvcNAQEFBQAwgcExCzAJBgNVBAYTAi0t
> MRIwEAYDVQQIDAlTb21lU3RhdGUxETAPBgNVBAcMCFNvbWVDaXR5MRkwFwYDVQQK
> DBBTb21lT3JnYW5pemF0aW9uMR8wHQYDVQQLDBZTb21lT3JnYW5pemF0aW9uYWxV
> bml0MSEwHwYDVQQDDBh0czEudGVzdC5jbnouYWxpbWFtYS5jb20xLDAqBgkqhkiG
> 9w0BCQEWHXJvb3RAdHMxLnRlc3QuY256LmFsaW1hbWEuY29tMB4XDTExMDMyNDEw
> Mjk1MVoXDTEyMDMyMzEwMjk1MVowgcExCzAJBgNVBAYTAi0tMRIwEAYDVQQIDAlT
> b21lU3RhdGUxETAPBgNVBAcMCFNvbWVDaXR5MRkwFwYDVQQKDBBTb21lT3JnYW5p
> emF0aW9uMR8wHQYDVQQLDBZTb21lT3JnYW5pemF0aW9uYWxVbml0MSEwHwYDVQQD
> DBh0czEudGVzdC5jbnouYWxpbWFtYS5jb20xLDAqBgkqhkiG9w0BCQEWHXJvb3RA
> dHMxLnRlc3QuY256LmFsaW1hbWEuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB
> iQKBgQDg0xr6MMfTUooenmxTyXiaSiHMfrkbGGhjgE0slP1iWfBf62Qal1daSSb8
> hSSFCZI78RWAp/bcadHGPo43xDWBmohLyTnlWksKKcbSJ9atdijC2L2CJNXiWgKC
> cu+2jOTLAw0YJVOufuJmm8QaqmHl4y3UGE626VDN8lPGBCrQcwIDAQABo1AwTjAd
> BgNVHQ4EFgQUIAfaVLkaRWgWp+zxPtp0bWfbbsgwHwYDVR0jBBgwFoAUIAfaVLka
> RWgWp+zxPtp0bWfbbsgwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQUFAAOBgQA1
> qYMZB0MuCQz2yCAx25C3+UtoZuxdmQxekmOPjtRAm2CRccW7r0ne57BcVU79Qk2s
> 6KTU4fO7lJ1tz49ZkX5zts5WuqsWDSb4cfyDb3ybubcZwUu+eSkqVkx/7GAuVgcl
> weoLXdgpQ779T45SovOR212BXQpYI0piMDNIB9p0mA==
> -END CERTIFICATE-
> subject=/C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ts1.test.cnz.alimama.com/emailAddress=r...@ts1.test.cnz.alimama.com
> issuer=/C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ts1.test.cnz.alimama.com/emailAddress=r...@ts1.test.cnz.alimama.com
> ---
> No client certificate CA names sent
> ---
> SSL handshake has read 1418 bytes and written 319 bytes
> ---
> New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
> Server public key is 1024 bit
> Secure Renegotiation IS supported
> Compression: NONE
> Expansion: NONE
> SSL-Session:
> Protocol : TLSv1
> Cipher: DHE-RSA-AES256-SHA
> Session-ID:
> 8A72957E09AF60AD3807C1D06CE3F9BD88914886B7F1F646B03E8BDA783FAB8B
> Session-ID-ctx:
> Master-Key:
> 42808C5CDF016480F1BC7FF6F764A4886886E430F8E23400D82A9E6A6DE377A30369541E52BA06E1DC878F18DAFC2ECA
> Key-Arg : None
> Krb5 Principal: None
> Start Time: 1300962675
> Timeout : 300 (sec)
> Verify return code: 18 (self signed certificate)
> ---
> drop connection and then reconnect
> CONNECTED(0003)
> ---
> Reused, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
> Secure Renegotiation IS supported
> Compression: zlib compression
> Expansion: zlib compression
> SSL-Session:
> Protocol : TLSv1
> Cipher: DHE-RSA-AES256-SHA
> Session-ID:
> 8A72957E09AF60AD3807C1D06CE3F9BD88914886B7F1F646B03E8BDA783FAB8B
> Session-ID-ctx:
> Master-Key:
> 42808C5CDF016480F1BC7FF6F764A4886886E430F8E23400D82A9E6A6DE377A30369541E52BA06E1DC878F18DAFC2ECA
> Key-Arg : None
>
[jira] [Updated] (TS-475) HTTP SM should support efficient byte range requests
[ https://issues.apache.org/jira/browse/TS-475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-475: - Fix Version/s: (was: 2.1.8) 2.1.9 Moving out for v2.1.9, per ebalsa. > HTTP SM should support efficient byte range requests > > > Key: TS-475 > URL: https://issues.apache.org/jira/browse/TS-475 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: Leif Hedstrom >Assignee: Eric Balsa >Priority: Critical > Fix For: 2.1.9 > > > The cache has support for efficiently locate a particular range in the cached > object, but the HTTP SM does not support this. In order to make Range: > request efficient (particularly on large objects), the SM should support this > new cache feature. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-718) can not reuse SSL connections on RHEL5/CentOS5
[
https://issues.apache.org/jira/browse/TS-718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021939#comment-13021939
]
Leif Hedstrom commented on TS-718:
--
Confirmed that session cache with ATS does not work on CentOS5, I have no idea
why. It works fine on my Fedora Core 14 box.
> can not reuse SSL connections on RHEL5/CentOS5
> --
>
> Key: TS-718
> URL: https://issues.apache.org/jira/browse/TS-718
> Project: Traffic Server
> Issue Type: Bug
> Components: SSL
>Affects Versions: 2.1.7
> Environment: RHEL5 system with TS 2.1.6 2.1.7
> compared with Apache httpd
>Reporter: Zhao Yongming
>Assignee: qianshi
> Fix For: 2.1.8
>
> Attachments: TS-718-v2.patch, TS-718.patch
>
>
> when with apache httpd default mod_ssl:
> {noformat}
> [root@ts1 httpd]# echo | openssl s_client -reconnect -connect localhost:443
> 2>&1
> CONNECTED(0003)
> depth=0
> /C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ts1.test.cnz.alimama.com/emailAddress=r...@ts1.test.cnz.alimama.com
> verify error:num=18:self signed certificate
> verify return:1
> depth=0
> /C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ts1.test.cnz.alimama.com/emailAddress=r...@ts1.test.cnz.alimama.com
> verify return:1
> ---
> Certificate chain
> 0
> s:/C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ts1.test.cnz.alimama.com/emailAddress=r...@ts1.test.cnz.alimama.com
>
> i:/C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ts1.test.cnz.alimama.com/emailAddress=r...@ts1.test.cnz.alimama.com
> ---
> Server certificate
> -BEGIN CERTIFICATE-
> MIIDSzCCArSgAwIBAgICUWcwDQYJKoZIhvcNAQEFBQAwgcExCzAJBgNVBAYTAi0t
> MRIwEAYDVQQIDAlTb21lU3RhdGUxETAPBgNVBAcMCFNvbWVDaXR5MRkwFwYDVQQK
> DBBTb21lT3JnYW5pemF0aW9uMR8wHQYDVQQLDBZTb21lT3JnYW5pemF0aW9uYWxV
> bml0MSEwHwYDVQQDDBh0czEudGVzdC5jbnouYWxpbWFtYS5jb20xLDAqBgkqhkiG
> 9w0BCQEWHXJvb3RAdHMxLnRlc3QuY256LmFsaW1hbWEuY29tMB4XDTExMDMyNDEw
> Mjk1MVoXDTEyMDMyMzEwMjk1MVowgcExCzAJBgNVBAYTAi0tMRIwEAYDVQQIDAlT
> b21lU3RhdGUxETAPBgNVBAcMCFNvbWVDaXR5MRkwFwYDVQQKDBBTb21lT3JnYW5p
> emF0aW9uMR8wHQYDVQQLDBZTb21lT3JnYW5pemF0aW9uYWxVbml0MSEwHwYDVQQD
> DBh0czEudGVzdC5jbnouYWxpbWFtYS5jb20xLDAqBgkqhkiG9w0BCQEWHXJvb3RA
> dHMxLnRlc3QuY256LmFsaW1hbWEuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB
> iQKBgQDg0xr6MMfTUooenmxTyXiaSiHMfrkbGGhjgE0slP1iWfBf62Qal1daSSb8
> hSSFCZI78RWAp/bcadHGPo43xDWBmohLyTnlWksKKcbSJ9atdijC2L2CJNXiWgKC
> cu+2jOTLAw0YJVOufuJmm8QaqmHl4y3UGE626VDN8lPGBCrQcwIDAQABo1AwTjAd
> BgNVHQ4EFgQUIAfaVLkaRWgWp+zxPtp0bWfbbsgwHwYDVR0jBBgwFoAUIAfaVLka
> RWgWp+zxPtp0bWfbbsgwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQUFAAOBgQA1
> qYMZB0MuCQz2yCAx25C3+UtoZuxdmQxekmOPjtRAm2CRccW7r0ne57BcVU79Qk2s
> 6KTU4fO7lJ1tz49ZkX5zts5WuqsWDSb4cfyDb3ybubcZwUu+eSkqVkx/7GAuVgcl
> weoLXdgpQ779T45SovOR212BXQpYI0piMDNIB9p0mA==
> -END CERTIFICATE-
> subject=/C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ts1.test.cnz.alimama.com/emailAddress=r...@ts1.test.cnz.alimama.com
> issuer=/C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ts1.test.cnz.alimama.com/emailAddress=r...@ts1.test.cnz.alimama.com
> ---
> No client certificate CA names sent
> ---
> SSL handshake has read 1418 bytes and written 319 bytes
> ---
> New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
> Server public key is 1024 bit
> Secure Renegotiation IS supported
> Compression: NONE
> Expansion: NONE
> SSL-Session:
> Protocol : TLSv1
> Cipher: DHE-RSA-AES256-SHA
> Session-ID:
> 8A72957E09AF60AD3807C1D06CE3F9BD88914886B7F1F646B03E8BDA783FAB8B
> Session-ID-ctx:
> Master-Key:
> 42808C5CDF016480F1BC7FF6F764A4886886E430F8E23400D82A9E6A6DE377A30369541E52BA06E1DC878F18DAFC2ECA
> Key-Arg : None
> Krb5 Principal: None
> Start Time: 1300962675
> Timeout : 300 (sec)
> Verify return code: 18 (self signed certificate)
> ---
> drop connection and then reconnect
> CONNECTED(0003)
> ---
> Reused, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
> Secure Renegotiation IS supported
> Compression: zlib compression
> Expansion: zlib compression
> SSL-Session:
> Protocol : TLSv1
> Cipher: DHE-RSA-AES256-SHA
> Session-ID:
> 8A72957E09AF60AD3807C1D06CE3F9BD88914886B7F1F646B03E8BDA783FAB8B
> Session-ID-ctx:
> Master-Key:
> 42808C5CDF016480F1BC7FF6F764A4886886E430F8E23400D82A9E6A6DE377A30369541E52BA06E1DC878F18DAFC2ECA
> Key-Arg : None
> Krb5 Principal: None
>Compression: 1 (zlib compression)
> Start Time: 1300962675
> Timeout : 300 (sec)
> Verify return code: 18 (self signed certificate)
> ---
> drop connection and then reconnect
> CONNECTED(0003)
> ---
> Reused, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
> Secu
[jira] [Commented] (TS-702) FATAL: MIME.cc:1250: failed assert `j < block_count`
[
https://issues.apache.org/jira/browse/TS-702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021953#comment-13021953
]
Alan M. Carroll commented on TS-702:
Looks reasonable overall, a few issues --
1) Why not break after setting m_next_dup? That's what the original code does
and it seems that m_next_dup shouldn't be updated more than once.
2) The C-style casts should be static_cast<>(). Also, why the mixed const
types? E.g. in rebase.
3) I agree there's no good reason for rebase to be a template. It's too
specialized to be reused with other types.
4) Why the extra parens around some of the expressions? E.g. the test in the
for loop in mime_hdr_block_list_adjust.
> FATAL: MIME.cc:1250: failed assert `j < block_count`
> -
>
> Key: TS-702
> URL: https://issues.apache.org/jira/browse/TS-702
> Project: Traffic Server
> Issue Type: Bug
> Components: MIME
>Affects Versions: 2.0.1
> Environment: Sun Blade X6240 (64G Ram), Running Linux Debian Lenny,
> Kernel 2.6.26-2-amd64
>Reporter: Ricky Chan
>Priority: Critical
> Fix For: 2.1.8
>
> Attachments: trafficserver.2.1.7.too.many.mimefields.patch
>
>
> I have 20 servers in a CDN farm which I brought live recently, I have noticed
> with in a day 5 servers had this error reported in traffic.out. Essentially
> aborting due to assertion failure. The server restarts (from traffic_cop).
> This platform has not had any load go through it yet, it's running around
> 5MB/s a second with around 25 connection per second. So doing much.
> I was going to migrate more traffic onto it, but holding off due to this
> assertion issue.
> Looking at the code, we have:
> for (j=0; j < block_count; j++) {
> ... with a condition which breaks out ..
> }
> ink_release_assert(j < block_count)
> So for this assert to be hit the entire list must be gone through without
> triggering the break clause, i.e. j == block_count
> I don't know this code well, is this a real bug or should the assert be there
> (or j <= block_count)?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
