[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 ] Zhao Yongming updated TS-621: - Attachment: TS-621_cluster_zero_size_objects.patch I try to get the zero size object as a normal return. here is the patch make cluster happy and it passed my testing. It may need more tweak. Just FYI first > 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_cluster_zero_size_objects.patch, > 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=13036269#comment-13036269 ] John Plevyak commented on TS-621: - Looks good, but I agree, this set of changes is pretty invasive and I don't have great confidence that we haven't missed some corner cases. I am somewhat reluctant to dump it in just before 3.0, but in any case I think we need to review the code a bit more before committing john > 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_cluster_zero_size_objects.patch, > 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=13036279#comment-13036279 ] Leif Hedstrom commented on TS-621: -- The changes seem invasive to me too, but are definitely very useful. A few options I guess 1) Just go with this, and hope for the best (but we'll do more testing of course before v3.0). The sooner we land it, the better then. 2) We make a new configuration to allow zero-length bodies, off by default, and try to make the code as "backward compatible" as possible with this option turned off. This makes it possible to restore old behavior if there turns out to be a bug somewhere, but I can see how adding an option like this would be pretty gnarly. 3) We postpone landing this until v3.0 is release. I'll do some more testing today as well. > 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_cluster_zero_size_objects.patch, > 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] [Assigned] (TS-404) API to set IP address of origin server avoiding DNS lookup
[ https://issues.apache.org/jira/browse/TS-404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-404: Assignee: Leif Hedstrom > API to set IP address of origin server avoiding DNS lookup > -- > > Key: TS-404 > URL: https://issues.apache.org/jira/browse/TS-404 > Project: Traffic Server > Issue Type: Improvement > Components: TS API >Affects Versions: 2.1.1 > Environment: Red Hat Enterprise Linux AS release 4 (Nahant Update 6) > - x86_64 >Reporter: Anirban Roy >Assignee: Leif Hedstrom > Fix For: 2.1.9 > > > Current TS lacks InkAPI to set IP address of the origin server which could > avoid DNS lookup and hence makes it perform better in higher load. In our > usecase, we make DNS query from a plugin for maintaining politeness, > load-balancing, black-listing etc. So really speaking, we can avoid DNS query > from within traffic server. Exposing such API would be a great help for us. > We can see an InkAPI to get the IP though - > inkapi INKReturnCode INKHostLookupResultIPGet(INKHostLookupResult > lookup_result, unsigned int *ip); > We want similar InkAPI to set it before DNS lookup stage in trafficserver and > bypass the DNS lookup once set. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-783) Port ATS to IA64
[ https://issues.apache.org/jira/browse/TS-783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-783: - Fix Version/s: 2.1.9 Assignee: Leif Hedstrom > Port ATS to IA64 > > > Key: TS-783 > URL: https://issues.apache.org/jira/browse/TS-783 > Project: Traffic Server > Issue Type: Improvement > Components: Portability >Affects Versions: 2.1.8 >Reporter: Arno Toell >Assignee: Leif Hedstrom >Priority: Minor > Fix For: 2.1.9 > > Attachments: ats.patch > > > Currently ATS fails to build on not explicitly supported platforms. This is > mostly because of the macro in _lib/ts/ink_queue.h b/lib/ts/ink_queue.h_ > which is perhaps a bit overcautious. The patch I attached fixes this issue > and makes ATS build fine on IA64. > Moreover I removed _asm/ptrace.h_ from CoreUtils.h. This is not strictly > required to port ATS on IA64, but it prevents a successful build because of > an upstream issue (please see > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=538916#16 if you are > curious). This ought to be unproblematic because _struct pt_regs_ is not used > (anymore). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (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 ] Leif Hedstrom reassigned TS-778: Assignee: Leif Hedstrom (was: John Plevyak) > 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: Leif Hedstrom > 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] [Resolved] (TS-404) API to set IP address of origin server avoiding DNS lookup
[ https://issues.apache.org/jira/browse/TS-404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-404. -- Resolution: Fixed > API to set IP address of origin server avoiding DNS lookup > -- > > Key: TS-404 > URL: https://issues.apache.org/jira/browse/TS-404 > Project: Traffic Server > Issue Type: Improvement > Components: TS API >Affects Versions: 2.1.1 > Environment: Red Hat Enterprise Linux AS release 4 (Nahant Update 6) > - x86_64 >Reporter: Anirban Roy >Assignee: Leif Hedstrom > Fix For: 2.1.9 > > > Current TS lacks InkAPI to set IP address of the origin server which could > avoid DNS lookup and hence makes it perform better in higher load. In our > usecase, we make DNS query from a plugin for maintaining politeness, > load-balancing, black-listing etc. So really speaking, we can avoid DNS query > from within traffic server. Exposing such API would be a great help for us. > We can see an InkAPI to get the IP though - > inkapi INKReturnCode INKHostLookupResultIPGet(INKHostLookupResult > lookup_result, unsigned int *ip); > We want similar InkAPI to set it before DNS lookup stage in trafficserver and > bypass the DNS lookup once set. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-783) Port ATS to IA64
[ https://issues.apache.org/jira/browse/TS-783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-783. -- Resolution: Fixed > Port ATS to IA64 > > > Key: TS-783 > URL: https://issues.apache.org/jira/browse/TS-783 > Project: Traffic Server > Issue Type: Improvement > Components: Portability >Affects Versions: 2.1.8 >Reporter: Arno Toell >Assignee: Leif Hedstrom >Priority: Minor > Fix For: 2.1.9 > > Attachments: ats.patch > > > Currently ATS fails to build on not explicitly supported platforms. This is > mostly because of the macro in _lib/ts/ink_queue.h b/lib/ts/ink_queue.h_ > which is perhaps a bit overcautious. The patch I attached fixes this issue > and makes ATS build fine on IA64. > Moreover I removed _asm/ptrace.h_ from CoreUtils.h. This is not strictly > required to port ATS on IA64, but it prevents a successful build because of > an upstream issue (please see > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=538916#16 if you are > curious). This ought to be unproblematic because _struct pt_regs_ is not used > (anymore). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-785) Building outside of the tree does not work
[
https://issues.apache.org/jira/browse/TS-785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-785:
-
Fix Version/s: (was: 2.1.9)
3.1
> Building outside of the tree does not work
> --
>
> Key: TS-785
> URL: https://issues.apache.org/jira/browse/TS-785
> Project: Traffic Server
> Issue Type: Bug
> Components: Build
>Reporter: Igor Galić
> Labels: build
> Fix For: 3.1
>
>
> {noformat}
> igalic@bawnb976 ~/Projects/asf/ats-build % ../trafficserver/configure
> --prefix=/opt/dev
>
> ...
> igalic@bawnb976 ~/Projects/asf/ats-build % make
> Making all in proxy/api/ts
> make[1]: Entering directory `/home/igalic/Projects/asf/ats-build/proxy/api/ts'
> make[1]: Nothing to be done for `all'.
> make[1]: Leaving directory `/home/igalic/Projects/asf/ats-build/proxy/api/ts'
> Making all in iocore
> make[1]: Entering directory `/home/igalic/Projects/asf/ats-build/iocore'
> Making all in eventsystem
> make[2]: Entering directory
> `/home/igalic/Projects/asf/ats-build/iocore/eventsystem'
> g++ -DHAVE_CONFIG_H -I. -I../../../trafficserver/iocore/eventsystem
> -I../../lib/ts -I../../../trafficserver/lib/records -D_LARGEFILE64_SOURCE=1
> -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -D_REENTRANT -Dlinux
> -I/usr/include/tcl8.4 -mtune=native -march=native -Wall -O3 -march=i586 -g
> -pipe -Werror -feliminate-unused-debug-symbols -fno-strict-aliasing
> -Wno-invalid-offsetof -MT EventSystem.o -MD -MP -MF .deps/EventSystem.Tpo -c
> -o EventSystem.o ../../../trafficserver/iocore/eventsystem/EventSystem.cc
> In file included from
> ../../../trafficserver/iocore/eventsystem/EventSystem.cc:31:0:
> ../../../trafficserver/iocore/eventsystem/P_EventSystem.h:39:19: fatal error:
> libts.h: No such file or directory
> compilation terminated.
> make[2]: *** [EventSystem.o] Error 1
> make[2]: Leaving directory
> `/home/igalic/Projects/asf/ats-build/iocore/eventsystem'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/home/igalic/Projects/asf/ats-build/iocore'
> make: *** [all-recursive] Error 1
> 2 igalic@bawnb976 ~/Projects/asf/ats-build %
> {noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-404) API to set IP address of origin server avoiding DNS lookup
[ https://issues.apache.org/jira/browse/TS-404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-404: - Issue Type: New Feature (was: Improvement) > API to set IP address of origin server avoiding DNS lookup > -- > > Key: TS-404 > URL: https://issues.apache.org/jira/browse/TS-404 > Project: Traffic Server > Issue Type: New Feature > Components: TS API >Affects Versions: 2.1.1 > Environment: Red Hat Enterprise Linux AS release 4 (Nahant Update 6) > - x86_64 >Reporter: Anirban Roy >Assignee: Leif Hedstrom > Fix For: 2.1.9 > > > Current TS lacks InkAPI to set IP address of the origin server which could > avoid DNS lookup and hence makes it perform better in higher load. In our > usecase, we make DNS query from a plugin for maintaining politeness, > load-balancing, black-listing etc. So really speaking, we can avoid DNS query > from within traffic server. Exposing such API would be a great help for us. > We can see an InkAPI to get the IP though - > inkapi INKReturnCode INKHostLookupResultIPGet(INKHostLookupResult > lookup_result, unsigned int *ip); > We want similar InkAPI to set it before DNS lookup stage in trafficserver and > bypass the DNS lookup once set. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-775) Disable cluster autodiscovery via multicast when clustering is disabled (as is by default)
[
https://issues.apache.org/jira/browse/TS-775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-775:
-
Issue Type: Improvement (was: Bug)
> Disable cluster autodiscovery via multicast when clustering is disabled (as
> is by default)
> --
>
> Key: TS-775
> URL: https://issues.apache.org/jira/browse/TS-775
> Project: Traffic Server
> Issue Type: Improvement
> Components: Clustering
>Reporter: Igor Galić
>Assignee: Leif Hedstrom
> Fix For: 2.1.9
>
> Attachments: TS-775.diff
>
>
> By default clustering is disabled, however when a freshly installed instance
> starts up, it tries to discover potential clustering partners via multicast
> none the less. This is evident with Ubuntu when "ufw" is active, which blocks
> multicast by default:
> {noformat}
> May 12 23:11:46 pheme kernel: [549586.656109] [UFW BLOCK] IN=eth1 OUT=
> MAC=01:00:5e:00:00:01:fe:54:00:24:07:4d:08:00 SRC=0.0.0.0 DST=224.0.0.1
> LEN=32 TOS=0x00 PREC=0xC0 TTL=1 ID=0 DF PROTO=2
> May 12 23:11:46 pheme kernel: [549586.656131] [UFW BLOCK] IN=eth0 OUT=
> MAC=01:00:5e:00:00:01:00:24:21:ef:35:90:08:00 SRC=0.0.0.0 DST=224.0.0.1
> LEN=32 TOS=0x00 PREC=0xC0 TTL=1 ID=0 DF PROTO=2
> {noformat}
> When clustering is disabled, as it is by default, we should *not* try to do
> any kind of discovery either.
--
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.9)
> 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
>
> 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.00 680.80 0.0053.19
> 0.010.41 0.33
[jira] [Updated] (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 updated TS-789: - Issue Type: Bug (was: Improvement) > 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: Bug > 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] [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=13036424#comment-13036424
]
John Plevyak commented on TS-621:
-
Obviously the patch needs to be fixed up a bit. The Cluster used the
CacheDataType
as a message type, so I hacked in:
enum CacheDataType
{
CACHE_DATA_SIZE = VCONNECTION_CACHE_DATA_BASE,
- CACHE_DATA_HTTP_INFO,
+ CACHE_DATA_HTTP_INFO_LEAVE_BODY,
+ CACHE_DATA_HTTP_INFO_REPLACE_BODY,
CACHE_DATA_KEY,
CACHE_DATA_RAM_CACHE_HIT_FLAG
};
Which doesn't really make sense. The leave/replace bit should be encoded
somewhere else in the message.
The changes to CacheWrite are very tricky and I have little faith in them.
We could land it, but we would needs some serious testing...
> 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_cluster_zero_size_objects.patch,
> 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] [Created] (TS-792) Add a config option (disabled by default) to support mlock() and mlockall().
Add a config option (disabled by default) to support mlock() and mlockall(). Key: TS-792 URL: https://issues.apache.org/jira/browse/TS-792 Project: Traffic Server Issue Type: New Feature Components: Core Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 2.1.9 This allows us to lock the traffic_server pages into memory. This is very experimental! -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-792) Add a config option (disabled by default) to support mlock() and mlockall().
[ https://issues.apache.org/jira/browse/TS-792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-792. -- Resolution: Fixed > Add a config option (disabled by default) to support mlock() and mlockall(). > > > Key: TS-792 > URL: https://issues.apache.org/jira/browse/TS-792 > Project: Traffic Server > Issue Type: New Feature > Components: Core >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom > Fix For: 2.1.9 > > > This allows us to lock the traffic_server pages into memory. This is very > experimental! -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-788) clean up APIs for setting a request or response as being cacheable
[ https://issues.apache.org/jira/browse/TS-788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call resolved TS-788. --- Resolution: Fixed > 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] [Commented] (TS-769) traffic server loops forever if the origin sends back a 505 and the connection is keep-alive
[ https://issues.apache.org/jira/browse/TS-769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13036611#comment-13036611 ] Bryan Call commented on TS-769: --- The bug did exist in the Apache tree also. > traffic server loops forever if the origin sends back a 505 and the > connection is keep-alive > > > Key: TS-769 > URL: https://issues.apache.org/jira/browse/TS-769 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Affects Versions: 2.1.8 > Environment: This was observed in the Yahoo! version of traffic server >Reporter: Bryan Call >Assignee: Bryan Call > Fix For: 2.1.9 > > > Traffic server tries to downgrade the connection/protocol when it gets back a > 505 from the origin server. First it removes keep-alive and retries, then > traffic sever start to downgrade the http protocol version and retry. > However, another part of the code turns keep-alive back on and traffic server > will loop turning on and off keep-alive and making the same request to the > origin server. > I fixed the issue in the Yahoo! tree by alway downgrade keep-alive and > protocol version together. This will eventually stop after it has tried > HTTP/0.9. Also, I added an option to not downgrade and retry at all when > getting a 505. > I have to verify that this is also an issue with the Apache tree. I looked > over the code and it doesn't look like it changed at all from the Yahoo! > tree, so the bug should also be there. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-769) traffic server loops forever if the origin sends back a 505 and the connection is keep-alive
[ https://issues.apache.org/jira/browse/TS-769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call resolved TS-769. --- Resolution: Fixed Resolved according to the description of the bug. > traffic server loops forever if the origin sends back a 505 and the > connection is keep-alive > > > Key: TS-769 > URL: https://issues.apache.org/jira/browse/TS-769 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Affects Versions: 2.1.8 > Environment: This was observed in the Yahoo! version of traffic server >Reporter: Bryan Call >Assignee: Bryan Call > Fix For: 2.1.9 > > > Traffic server tries to downgrade the connection/protocol when it gets back a > 505 from the origin server. First it removes keep-alive and retries, then > traffic sever start to downgrade the http protocol version and retry. > However, another part of the code turns keep-alive back on and traffic server > will loop turning on and off keep-alive and making the same request to the > origin server. > I fixed the issue in the Yahoo! tree by alway downgrade keep-alive and > protocol version together. This will eventually stop after it has tried > HTTP/0.9. Also, I added an option to not downgrade and retry at all when > getting a 505. > I have to verify that this is also an issue with the Apache tree. I looked > over the code and it doesn't look like it changed at all from the Yahoo! > tree, so the bug should also be there. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
