[jira] [Created] (TS-787) disable SSLv2 by default
disable SSLv2 by default Key: TS-787 URL: https://issues.apache.org/jira/browse/TS-787 Project: Traffic Server Issue Type: Improvement Components: Configuration, SSL Affects Versions: 2.1.8 Reporter: Zhao Yongming Priority: Minor Fix For: 2.1.9 we should disable SSLv2 by default, as it is not recommended for security concern. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-787) disable SSLv2 by default
[ https://issues.apache.org/jira/browse/TS-787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zhao Yongming updated TS-787: - Attachment: SSLv2.patch disable SSLv2 > disable SSLv2 by default > > > Key: TS-787 > URL: https://issues.apache.org/jira/browse/TS-787 > Project: Traffic Server > Issue Type: Improvement > Components: Configuration, SSL >Affects Versions: 2.1.8 >Reporter: Zhao Yongming >Priority: Minor > Labels: ssl > Fix For: 2.1.9 > > Attachments: SSLv2.patch > > > we should disable SSLv2 by default, as it is not recommended for security > concern. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (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
]
Zhao Yongming closed TS-724.
Resolution: Invalid
Assignee: Zhao Yongming
This is confirmed not a problem from TS, but it is when some big & hot file on
the same disk.
> 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
>Assignee: 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.00
[jira] [Assigned] (TS-787) disable SSLv2 by default
[ https://issues.apache.org/jira/browse/TS-787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-787: Assignee: Leif Hedstrom > disable SSLv2 by default > > > Key: TS-787 > URL: https://issues.apache.org/jira/browse/TS-787 > Project: Traffic Server > Issue Type: Improvement > Components: Configuration, SSL >Affects Versions: 2.1.8 >Reporter: Zhao Yongming >Assignee: Leif Hedstrom >Priority: Minor > Labels: ssl > Fix For: 2.1.9 > > Attachments: SSLv2.patch > > > we should disable SSLv2 by default, as it is not recommended for security > concern. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-621) writing 0 bytes to the HTTP cache means only update the header... need a new API: update_header_only() to allow 0 byte files to be cached
[ https://issues.apache.org/jira/browse/TS-621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Plevyak updated TS-621: Attachment: ts-621-jp-2.patch Updated patch. > writing 0 bytes to the HTTP cache means only update the header... need a new > API: update_header_only() to allow 0 byte files to be cached > - > > Key: TS-621 > URL: https://issues.apache.org/jira/browse/TS-621 > Project: Traffic Server > Issue Type: Improvement > Components: Cache >Affects Versions: 2.1.5 >Reporter: John Plevyak >Assignee: John Plevyak > Fix For: 2.1.9 > > Attachments: ts-621-jp-1.patch, ts-621-jp-2.patch > > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-788) clean up APIs for setting a request or response as being cacheable
clean up APIs for setting a request or response as being cacheable -- Key: TS-788 URL: https://issues.apache.org/jira/browse/TS-788 Project: Traffic Server Issue Type: Bug Components: TS API Affects Versions: 2.1.8 Reporter: Bryan Call Assignee: Bryan Call Fix For: 2.1.9 redundant Set in the name function name for the Set*CacheableSet and not having the ability to turn off caching from the API: TSHttpTxnSetReqCacheableSet(TSHttpTxn txnp) TSHttpTxnSetRespCacheableSet(TSHttpTxn txnp) should be: TSHttpTxnReqCacheableSet(TSHttpTxn txnp, int flag) TSHttpTxnRespCacheableSet(TSHttpTxn txnp, int flag) to be like other API function prototypes: TSSkipRemappingSet(TSHttpTxn txnp, int flag); -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-621) writing 0 bytes to the HTTP cache means only update the header... need a new API: update_header_only() to allow 0 byte files to be cached
[ https://issues.apache.org/jira/browse/TS-621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Plevyak updated TS-621: Attachment: ts-621-jp-3.patch This one works... but I would consider it very risky. > writing 0 bytes to the HTTP cache means only update the header... need a new > API: update_header_only() to allow 0 byte files to be cached > - > > Key: TS-621 > URL: https://issues.apache.org/jira/browse/TS-621 > Project: Traffic Server > Issue Type: Improvement > Components: Cache >Affects Versions: 2.1.5 >Reporter: John Plevyak >Assignee: John Plevyak > Fix For: 2.1.9 > > Attachments: ts-621-jp-1.patch, ts-621-jp-2.patch, ts-621-jp-3.patch > > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-621) writing 0 bytes to the HTTP cache means only update the header... need a new API: update_header_only() to allow 0 byte files to be cached
[ https://issues.apache.org/jira/browse/TS-621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13034928#comment-13034928 ] Leif Hedstrom commented on TS-621: -- Yep, -3 works. This seems ok so far to me, and in line with where I was looking as well. I'll give it some more tests, but id' be great if ibrezac could test it too. > writing 0 bytes to the HTTP cache means only update the header... need a new > API: update_header_only() to allow 0 byte files to be cached > - > > Key: TS-621 > URL: https://issues.apache.org/jira/browse/TS-621 > Project: Traffic Server > Issue Type: Improvement > Components: Cache >Affects Versions: 2.1.5 >Reporter: John Plevyak >Assignee: John Plevyak > Fix For: 2.1.9 > > Attachments: ts-621-jp-1.patch, ts-621-jp-2.patch, ts-621-jp-3.patch > > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-621) writing 0 bytes to the HTTP cache means only update the header... need a new API: update_header_only() to allow 0 byte files to be cached
[
https://issues.apache.org/jira/browse/TS-621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-621:
-
Comment: was deleted
(was: Took a quick look at this, nothing obvious comes to mind, yet. I did
notice the event (VC_EVENT_WRITE_COMPLETE) originates from
UnixNetVConnection.cc:476:
{code}
if (s->vio.ntodo() <= 0) {
write_signal_done(VC_EVENT_WRITE_COMPLETE, nh, vc);
return;
} else if (!signalled) {
{code})
> writing 0 bytes to the HTTP cache means only update the header... need a new
> API: update_header_only() to allow 0 byte files to be cached
> -
>
> Key: TS-621
> URL: https://issues.apache.org/jira/browse/TS-621
> Project: Traffic Server
> Issue Type: Improvement
> Components: Cache
>Affects Versions: 2.1.5
>Reporter: John Plevyak
>Assignee: John Plevyak
> Fix For: 2.1.9
>
> Attachments: ts-621-jp-1.patch, ts-621-jp-2.patch, ts-621-jp-3.patch
>
>
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-621) writing 0 bytes to the HTTP cache means only update the header... need a new API: update_header_only() to allow 0 byte files to be cached
[ https://issues.apache.org/jira/browse/TS-621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13035005#comment-13035005 ] Leif Hedstrom commented on TS-621: -- I think I've found a problem on clustering here. I'm fetching e.g. curl -D - -o /dev/null -s -x cluster1.ogre.com:8080 http://www.howstuffworks.com/bearing/ So, this 301 gets cached on cluster1, I'm assuming the hashing on the URL does that. But if I fetch the same object from cluster2.ogre.com:8080, it's always a cache miss. And to make things worse, it actually forces cache1 to refresh the object as well (so it gets refetched, and updated in cache). Also, it seems that 40x's are always cached in cluster mode now, even with the proxy.config.http.negative_caching_enabled setting disabled. Neither of these problems seems to occur in the standalone cache scenario. I'll try to do some more debugging on this as well, and yes, I know we already suspect issues with clustering. John, you have any immediate ideas we should look into? :) > writing 0 bytes to the HTTP cache means only update the header... need a new > API: update_header_only() to allow 0 byte files to be cached > - > > Key: TS-621 > URL: https://issues.apache.org/jira/browse/TS-621 > Project: Traffic Server > Issue Type: Improvement > Components: Cache >Affects Versions: 2.1.5 >Reporter: John Plevyak >Assignee: John Plevyak > Fix For: 2.1.9 > > Attachments: ts-621-jp-1.patch, ts-621-jp-2.patch, ts-621-jp-3.patch > > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-778) Compile Fails on Solaris 10 (gcc)
[ https://issues.apache.org/jira/browse/TS-778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Brezac updated TS-778: --- Attachment: assert.patch > Compile Fails on Solaris 10 (gcc) > - > > Key: TS-778 > URL: https://issues.apache.org/jira/browse/TS-778 > Project: Traffic Server > Issue Type: Bug >Affects Versions: 2.1.8 > Environment: Solaris 10 x86 / gcc 4.4.2 >Reporter: Igor Brezac >Assignee: John Plevyak > Fix For: 2.1.9 > > Attachments: assert.patch > > > g++ -DHAVE_CONFIG_H -DMGMT_USE_SYSLOG -I. -I../../lib/ts -I../../proxy/hdrs > -D_LARGEFILE64_SOURCE=1 -D_COMPILE64BIT_SOURCE=1 -D_GNU_SOURCE -D_REENTRANT > -Dsolaris -I/usr/local/include -O3 -m64 -g -pipe -Wall -Werror > -feliminate-unused-debug-symbols -fno-strict-aliasing -Wno-invalid-offsetof > -MT IPRange.o -MD -MP -MF .deps/IPRange.Tpo -c -o IPRange.o IPRange.cc > In file included from ../../lib/ts/Map.h:31, > from ../../lib/ts/libts.h:96, > from IPRange.h:27, > from IPRange.cc:44: > ../../lib/ts/Vec.h: In member function 'void Vec::addx()': > ../../lib/ts/Vec.h:627: error: there are no arguments to '__assert' that > depend on a template parameter, so a declaration of '__assert' must be > available > ../../lib/ts/Vec.h:627: note: (if you use '-fpermissive', G++ will accept > your code, but allowing the use of an undeclared name is deprecated) > In file included from ../../lib/ts/libts.h:96, > from IPRange.h:27, > from IPRange.cc:44: > ../../lib/ts/Map.h: In constructor 'MapElem::MapElem(uintptr_t)': > ../../lib/ts/Map.h:57: error: there are no arguments to '__assert' that > depend on a template parameter, so a declaration of '__assert' must be > available > make[2]: *** [IPRange.o] Error 1 > make[2]: Leaving directory `/src/trafficserver-2.1.8-unstable/mgmt/preparse' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/src/trafficserver-2.1.8-unstable/mgmt' > make: *** [all-recursive] Error 1 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-745) Support ssd
[ https://issues.apache.org/jira/browse/TS-745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13035178#comment-13035178 ] mohan_zl commented on TS-745: - +1 on a branch. I am busy on preparing ts for online use these days, sorry for looking at this so late. > Support ssd > --- > > Key: TS-745 > URL: https://issues.apache.org/jira/browse/TS-745 > Project: Traffic Server > Issue Type: New Feature > Components: Cache >Reporter: mohan_zl >Assignee: mohan_zl > Fix For: 3.1 > > Attachments: ssd_cache.patch > > > A patch for supporting, not work well for a long time with --enable-debug -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-789) PURGE should purge all alternates, no matter what the request headers indicate
PURGE should purge all alternates, no matter what the request headers indicate -- Key: TS-789 URL: https://issues.apache.org/jira/browse/TS-789 Project: Traffic Server Issue Type: Improvement Components: HTTP Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 2.1.9 If you cache e.g. a a gzip'ed version of an object only, and try to PURGE that without sending an "Accept-Encoding: gzip", we will not purge the object at all (and return a 404 Not Found). This is undesirable. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-789) PURGE should purge all alternates, no matter what the request headers indicate
[ https://issues.apache.org/jira/browse/TS-789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-789. -- Resolution: Fixed > PURGE should purge all alternates, no matter what the request headers indicate > -- > > Key: TS-789 > URL: https://issues.apache.org/jira/browse/TS-789 > Project: Traffic Server > Issue Type: Improvement > Components: HTTP >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom > Fix For: 2.1.9 > > > If you cache e.g. a a gzip'ed version of an object only, and try to PURGE > that without sending an "Accept-Encoding: gzip", we will not purge the object > at all (and return a 404 Not Found). This is undesirable. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
