[jira] [Updated] (TS-970) ts crash when use evacuate feature
[
https://issues.apache.org/jira/browse/TS-970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-970:
-
Fix Version/s: 3.1.1
> ts crash when use evacuate feature
> --
>
> Key: TS-970
> URL: https://issues.apache.org/jira/browse/TS-970
> Project: Traffic Server
> Issue Type: Bug
> Environment: {noformat}
> # uname -a
> Linux cache170.cn63 2.6.32-131.4.1.tb204.el5.x86_64 #1 SMP Fri Jul 1 22:17:55
> CST 2011 x86_64 x86_64 x86_64 GNU/Linux
> {noformat}
>Reporter: mohan_zl
> Fix For: 3.1.1
>
> Attachments: TS-970-1.patch
>
>
> My config arguments:
> start trafficserver in one machine 1
> {code}
> # traffic_line -s "proxy.config.cache.hit_evacuate_percent" -v 5 // by
> default, the value is 0, means no evacuation
> # cat storage.config //the size of storage file is 5G
> /dev/sda1
> {code}
> My test method:
> use http_load from another machine 2 to test machine 1
> {code}
> # http_load -parallel 500 -fetches 1000 -proxy xxx.xx.xx.xxx:8080
> mohan_urls
> # wc -l mohan_urls
> 40849490 mohan_urls
> # sort mohan_urls | uniq -c > mohan_urls_1; wc -l mohan_urls_1
> 14057051 mohan_urls_1
> # ls -al
> -rw-r--r-- 1 root root 3253681200 Sep 21 20:42 mohan_urls
> -rw-r--r-- 1 root root 1305299567 Sep 21 21:27 mohan_urls_1
> The total access urls' size is larger than the storage size
> {code}
> Crash result:
> {code}
> (gdb) bt
> #0 0x003639c30265 in raise () from /lib64/libc.so.6
> #1 0x003639c31d10 in abort () from /lib64/libc.so.6
> #2 0x2aaaee6d86fa in ink_die_die_die (retval=1) at ink_error.cc:43
> #3 0x2aaaee6d8979 in ink_fatal_va (return_code=1,
> message_format=0x424e6700 "CacheWrite.cc:519: failed assert
> `dir_pinned(&dir)`",
> ap=0x424e6600) at ink_error.cc:65
> #4 0x2aaaee6d8b46 in ink_fatal (return_code=1, message_format=0x424e6700
> "CacheWrite.cc:519: failed assert `dir_pinned(&dir)`")
> at ink_error.cc:73
> #5 0x2aaaee6d697a in _ink_assert (a=0x767108 "dir_pinned(&dir)",
> f=0x766a46 "CacheWrite.cc", l=519) at ink_assert.cc:44
> #6 0x006afaa2 in CacheVC::evacuateDocDone (this=0x2c371f80,
> event=3900, e=0x0) at CacheWrite.cc:519
> #7 0x004d3789 in Continuation::handleEvent (this=0x2c371f80,
> event=3900, data=0x0) at I_Continuation.h:146
> #8 0x006b0e7b in Vol::aggWrite (this=0x2e18a10, event=3900,
> e=0x2e18ae0) at CacheWrite.cc:998
> #9 0x006b1553 in Vol::evacuateWrite (this=0x2e18a10,
> evacuator=0x2c371f80, event=3900, e=0x2e18ae0) at CacheWrite.cc:603
> #10 0x006b2031 in Vol::evacuateDocReadDone (this=0x2e18a10,
> event=3900, e=0x2e18ae0) at CacheWrite.cc:687
> #11 0x004d3789 in Continuation::handleEvent (this=0x2e18a10,
> event=3900, data=0x2e18ae0) at I_Continuation.h:146
> #12 0x0068a532 in AIOCallbackInternal::io_complete (this=0x2e18ae0,
> event=1, data=0x30687d0) at P_AIO.h:80
> #13 0x004d3789 in Continuation::handleEvent (this=0x2e18ae0, event=1,
> data=0x30687d0) at I_Continuation.h:146
> #14 0x006f69b0 in EThread::process_event (this=0x2b22d010,
> e=0x30687d0, calling_code=1) at UnixEThread.cc:142
> #15 0x006f6cf2 in EThread::execute (this=0x2b22d010) at
> UnixEThread.cc:219
> #16 0x006f6337 in spawn_thread_internal (a=0x2d75190) at Thread.cc:88
> #17 0x00363a8064a7 in start_thread () from /lib64/libpthread.so.0
> #18 0x003639cd3c2d in clone () from /lib64/libc.so.6
> {code}
> {code}
> (gdb) f 6
> #6 0x006afaa2 in CacheVC::evacuateDocDone (this=0x2c371f80,
> event=3900, e=0x0) at CacheWrite.cc:519
> 519 ink_assert(dir_pinned(&dir));
> (gdb) p cod->num_writers
> $1 = 1
> (gdb) p cod->max_writers
> $2 = 5
> (gdb) p cod->dont_update_directory
> $3 = false
> (gdb) p cod->move_resident_alt
> $4 = false
> (gdb) p cod->reading_vec
> $5 = false
> (gdb) p cod->writing_vec
> $6 = true
> (gdb) p cod->first_dir
> $7 = {w = {61517, 5121, 14401, 59410, 0}}
> (gdb) p cod->single_doc_dir
> $8 = {w = {61517, 5121, 12585, 59410, 0}}
> (gdb) p this->dir
> $9 = {w = {10203, 5167, 14401, 59409, 0}}
> (gdb) p this->overwrite_dir
> $10 = {w = {20152, 5167, 10305, 59409, 0}}
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-966) cache.config dest_domain= dest_hostname= dest_ip= do not match anything
[ https://issues.apache.org/jira/browse/TS-966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-966: - Fix Version/s: 3.1.1 > cache.config dest_domain= dest_hostname= dest_ip= do not match anything > --- > > Key: TS-966 > URL: https://issues.apache.org/jira/browse/TS-966 > Project: Traffic Server > Issue Type: Bug > Components: Cache >Affects Versions: 3.1.0, 3.0.1 >Reporter: Igor Galić > Fix For: 3.1.1 > > > Caching policies are not applied when using these options to match targets. > It is also not very clear *what* dest_domain= vs dest_hostname= can match. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-965) cache.config can't deal with both revalidate= and ttl-in-cache= specified
[ https://issues.apache.org/jira/browse/TS-965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-965: - Fix Version/s: 3.1.1 > cache.config can't deal with both revalidate= and ttl-in-cache= specified > - > > Key: TS-965 > URL: https://issues.apache.org/jira/browse/TS-965 > Project: Traffic Server > Issue Type: Bug > Components: Cache >Affects Versions: 3.1.0, 3.0.1 >Reporter: Igor Galić > Fix For: 3.1.1 > > > If both of these options are specified (with the same time?), nothing is > cached at all. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-971) Thread error in the cache evacuation feature
[
https://issues.apache.org/jira/browse/TS-971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-971:
-
Fix Version/s: 3.1.1
> Thread error in the cache evacuation feature
>
>
> Key: TS-971
> URL: https://issues.apache.org/jira/browse/TS-971
> Project: Traffic Server
> Issue Type: Bug
>Reporter: mohan_zl
> Fix For: 3.1.1
>
> Attachments: TS-evacuate-fix.patch
>
>
> After fix the Bug TS-970, i go on testing the evacuate feature for the cache,
> with the same environment and test methods, and this time, trafficserver
> crash in another codes, somewhat strange.
> {code}
> (gdb) bt
> #0 0x003639c30265 in raise () from /lib64/libc.so.6
> #1 0x003639c31d10 in abort () from /lib64/libc.so.6
> #2 0x2b9258e7e6fa in ink_die_die_die (retval=Could not find the frame
> base for "ink_die_die_die".
> ) at ink_error.cc:43
> #3 0x2b9258e7e979 in ink_fatal_va (return_code=Could not find the frame
> base for "ink_fatal_va".
> ) at ink_error.cc:65
> #4 0x2b9258e7eb46 in ink_fatal (return_code=Could not find the frame
> base for "ink_fatal".
> ) at ink_error.cc:73
> #5 0x2b9258e7c97a in _ink_assert (a=Could not find the frame base for
> "_ink_assert".
> ) at ink_assert.cc:44
> #6 0x004f45df in EThread::schedule (this=0x2be9c010,
> e=0x2aaab4325e00, fast_signal=true)
> at ../../iocore/eventsystem/P_UnixEThread.h:96
> #7 0x006496db in EThread::schedule_imm_signal (this=0x2be9c010,
> cont=0x302b948, callback_event=1, cookie=0x0)
> at ../../iocore/eventsystem/P_UnixEThread.h:62
> #8 0x006c4427 in aio_thread_main (arg=0x2c0d1820) at AIO.cc:528
> #9 0x006c4afa in AIOThreadInfo::start (this=0x2c0d1820, event=1,
> e=0x2a05650) at AIO.cc:188
> #10 0x004d3789 in Continuation::handleEvent (this=0x2c0d1820,
> event=1, data=0x2a05650) at I_Continuation.h:146
> #11 0x006f705b in EThread::execute (this=0x2be9c010) at
> UnixEThread.cc:289
> #12 0x006f6307 in spawn_thread_internal (a=0x2c0d1870) at
> Thread.cc:88
> #13 0x00363a8064a7 in start_thread () from /lib64/libpthread.so.0
> #14 0x003639cd3c2d in clone () from /lib64/libc.so.6
> (gdb) f 8
> #8 0x006c4427 in aio_thread_main (arg=0x2c0d1820) at AIO.cc:528
> 528 op->thread->schedule_imm_signal(op);
> (gdb) p *op
> $1 = { = { = {_vptr.force_VFPT_to_top =
> 0x760710},
> handler = 0x68a4f6 ,
> handler_name = 0x75dfb0 "&AIOCallbackInternal::io_complete", mutex = {
> m_ptr = 0x2c261f70}, link = {> = {next = 0x0},
> prev = 0x0}}, aiocb = {aio_fildes = 38, aio_buf = 0x2aabd80db000,
> aio_nbytes = 3072, aio_offset = 3359854592, aio_reqprio = 0,
> aio_lio_opcode = 1, aio_state = 0, aio__pad = {0}}, action = {_vptr.Action =
> 0x0,
> continuation = 0x302b7c0, mutex = {m_ptr = 0x2c261f70}, cancelled =
> 0}, thread = 0x2be9c010, then = 0x0, aio_result = 3072}
> (gdb) p ((CacheVC *)op->action->continuation)->io->aiocb
> $1 = {aio_fildes = 38, aio_buf = 0x2aabd80db000, aio_nbytes = 3072,
> aio_offset = 3359854592, aio_reqprio = 0, aio_lio_opcode = 1, aio_state = 0,
> aio__pad = {0}}
> (gdb) p ((CacheVC *)op->action->continuation)->handler_name
> $2 = 0x75f372 "&CacheVC::handleReadDone"
> (gdb) p ((CacheVC *)op->action->continuation)->f.evacuator
> $3 = 1
> (gdb) p ((CacheVC *)op->action->continuation)->save_handler
> $4 = 0x6afe9e
> (gdb) f 6
> #6 0x004f45df in EThread::schedule (this=0x2be9c010,
> e=0x2aaab4325e00, fast_signal=true)
> at ../../iocore/eventsystem/P_UnixEThread.h:96
> 96ink_assert(tt == REGULAR);
> (gdb) p tt
> $2 = DEDICATED
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-968) During/after daily logfile roll, trafficserver seg faults (Sig 11)
[
https://issues.apache.org/jira/browse/TS-968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-968:
-
Fix Version/s: 3.1.1
> During/after daily logfile roll, trafficserver seg faults (Sig 11)
> --
>
> Key: TS-968
> URL: https://issues.apache.org/jira/browse/TS-968
> Project: Traffic Server
> Issue Type: Bug
> Components: Logging
>Affects Versions: 3.0.1
> Environment: Ubuntu 10.10, 2.6.35-24-virtual
>Reporter: Drew Rothstein
> Fix For: 3.1.1
>
>
> Every day at 00:00:00 after/during the log file roll, I see a segfault. Here
> are the past couple days:
> [Sep 22 00:00:00.000] Server {47590596851456} STATUS: The logfile
> /usr/local/var/log/trafficserver/error.log was rolled to
> /usr/local/var/log/trafficserver/error.log_trafficserver02.20110921.00h00m06s-20110922.00h00m00s.old.
> [Sep 22 00:00:00.000] Server {47590596851456} STATUS: The logfile
> /usr/local/var/log/trafficserver/squid.log was rolled to
> /usr/local/var/log/trafficserver/squid.log_trafficserver02.20110921.00h00m01s-20110922.00h00m00s.old.
> [Sep 22 00:00:00.000] Server {47590596851456} STATUS: The logfile
> /usr/local/var/log/trafficserver/extended2.log was rolled to
> /usr/local/var/log/trafficserver/extended2.log_trafficserver02.20110921.00h00m01s-20110922.00h00m00s.old.
> NOTE: Traffic Server received Sig 11: Segmentation fault
> /usr/local/bin/traffic_server - STACK TRACE:
> [Sep 22 00:00:17.729] Manager {140722071643936} FATAL:
> [LocalManager::pollMgmtProcessServer] Error in read (errno: 104)
> [Sep 22 00:00:17.729] Manager {140722071643936} FATAL: (last system error
> 104: Connection reset by peer)
> [Sep 22 00:00:17.730] Manager {140722071643936} NOTE:
> [LocalManager::mgmtShutdown] Executing shutdown request.
> [Sep 22 00:00:17.730] Manager {140722071643936} NOTE:
> [LocalManager::processShutdown] Executing process shutdown request.
> [Sep 22 00:00:17.730] Manager {140722071643936} ERROR:
> [LocalManager::sendMgmtMsgToProcesses] Error writing message
> [Sep 22 00:00:17.730] Manager {140722071643936} ERROR: (last system error
> 32: Broken pipe)
> [E. Mgmt] log ==> [TrafficManager] using root directory '/usr/local'
> [Sep 22 00:00:17.786] {140131209512736} STATUS: opened
> /usr/local/var/log/trafficserver/manager.log
> [Sep 22 00:00:17.786] {140131209512736} NOTE: updated diags config
> [Sep 22 00:00:17.805] Manager {140131209512736} NOTE:
> [ClusterCom::ClusterCom] Node running on OS: 'Linux' Release:
> '2.6.35-24-virtual'
> [Sep 22 00:00:17.805] Manager {140131209512736} NOTE:
> [LocalManager::listenForProxy] Listening on port: 80
> [Sep 22 00:00:17.805] Manager {140131209512736} NOTE: [TrafficManager] Setup
> complete
> [Sep 22 00:00:18.827] Manager {140131209512736} NOTE:
> [LocalManager::startProxy] Launching ts process
> [TrafficServer] using root directory '/usr/local'
> [Sep 22 00:00:18.849] Manager {140131209512736} NOTE:
> [LocalManager::pollMgmtProcessServer] New process connecting fd '13'
> [Sep 22 00:00:18.849] Manager {140131209512736} NOTE: [Alarms::signalAlarm]
> Server Process born
> [Sep 22 00:00:19.874] {47510015031936} STATUS: opened
> /usr/local/var/log/trafficserver/diags.log
> [Sep 22 00:00:19.874] {47510015031936} NOTE: updated diags config
> [Sep 22 00:00:19.879] Server {47510015031936} NOTE: cache clustering disabled
> [Sep 22 00:00:19.908] Server {47510015031936} NOTE: cache clustering disabled
> [Sep 22 00:00:20.019] Server {47510015031936} NOTE: logging initialized[7],
> logging_mode = 3
> [Sep 22 00:00:20.032] Server {47510015031936} NOTE: traffic server running
> [Sep 22 00:00:20.045] Server {47510028859136} NOTE: cache enabled
> [Sep 23 00:00:00.000] Server {47409990321920} STATUS: The logfile
> /usr/local/var/log/trafficserver/error.log was rolled to
> /usr/local/var/log/trafficserver/error.log_trafficserver02.20110922.00h00m11s-20110923.00h00m00s.old.
> [Sep 23 00:00:00.000] Server {47409990321920} STATUS: The logfile
> /usr/local/var/log/trafficserver/squid.log was rolled to
> /usr/local/var/log/trafficserver/squid.log_trafficserver02.20110922.00h00m06s-20110923.00h00m00s.old.
> [Sep 23 00:00:00.000] Server {47409990321920} STATUS: The logfile
> /usr/local/var/log/trafficserver/extended2.log was rolled to
> /usr/local/var/log/trafficserver/extended2.log_trafficserver02.20110922.00h00m06s-20110923.00h00m00s.old.
> NOTE: Traffic Server received Sig 11: Segmentation fault
> /usr/local/bin/traffic_server - STACK TRACE:
> [Sep 23 00:00:14.668] Manager {140131209512736} FATAL:
> [LocalManager::pollMgmtProcessServer] Error in read (errno: 104)
> [Sep 23 00:00:14.668] Manager {140131209512736} FATAL: (last system error
> 104: Connection reset by peer)
> [Sep 23 00:00:14.668] Manager {140131209512736} NOTE:
> [LocalManager
[jira] [Updated] (TS-964) No 64bit integer plugin APIs for HTTP headers
[ https://issues.apache.org/jira/browse/TS-964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-964: - Fix Version/s: 3.1.1 > No 64bit integer plugin APIs for HTTP headers > - > > Key: TS-964 > URL: https://issues.apache.org/jira/browse/TS-964 > Project: Traffic Server > Issue Type: Improvement > Components: TS API >Reporter: William Bardwell >Priority: Minor > Fix For: 3.1.1 > > > There are APIs for unsigned int, but stuff like content-length should be done > as 64-bit values, so we should add TSMimeHdrFieldValueUint64Get(), > TSMimeHdrFieldValueUint64Set(), TSMimeHdrFieldValueUint64Insert() or Int64 > versions of those APIs (since the mime_* stuff seems to have unsigned int, > int and int64, but no uint64). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-972) traffic_line should warn if a command didn't succeed
[
https://issues.apache.org/jira/browse/TS-972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-972:
-
Fix Version/s: 3.1.1
> traffic_line should warn if a command didn't succeed
>
>
> Key: TS-972
> URL: https://issues.apache.org/jira/browse/TS-972
> Project: Traffic Server
> Issue Type: Improvement
> Components: Management API
>Affects Versions: 3.1.0, 3.0.1
>Reporter: Arno Toell
> Fix For: 3.1.1
>
>
> {{traffic_line}} is a handy tool to manage a traffic server instance. For
> example it is possible to retrieve and set configuration settings through
> command line like this:
> {code}
> root@wv-tmp2:/home/at# traffic_line -r proxy.config.http.server_port ; echo $?
> 81
> 0
> {code}
> However, some commans can be set, but aren't effective until the server is
> restarted, despite of ATS offering the _-x_ option to flush configuration and
> reread new settings:
> {code}
> root@wv-tmp2:/home/at# traffic_line -s proxy.config.http.server_port -v 80 ;
> echo $?
> 0
> root@wv-tmp2:/home/at# traffic_line -x ; echo $?
> 0
> {code}
> Trafficserver should possibly warn when setting such settings which aren't
> effective until the server is restarted and leave with a non-zero exit status
> for _-x_ in such cases.
> Moreover {{traffic_line}} does not work at all if the manager is not running:
> {code}
> # traffic_line -r proxy.config.http.server_port ; echo $?
> traffic_line: Variable Not Found
> 1
> {code}
> That's all right, but the error message shall be improved telling that. :)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-952) when turn off config.proxy.hostdb, ts just reponse a 502 page.
[ https://issues.apache.org/jira/browse/TS-952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-952: - Fix Version/s: 3.1.1 > when turn off config.proxy.hostdb, ts just reponse a 502 page. > -- > > Key: TS-952 > URL: https://issues.apache.org/jira/browse/TS-952 > Project: Traffic Server > Issue Type: Bug > Components: DNS, HTTP >Affects Versions: 3.1.0 > Environment: all. >Reporter: weijin > Fix For: 3.1.1 > > > If turn config.proxy.hostdb off, ts does not do the dns query but just return > a 502 page. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-821) memcached_remap plugin
[ https://issues.apache.org/jira/browse/TS-821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-821: - Fix Version/s: (was: 3.1.1) sometime Moving this out for now, unless someone wish to review / land it. Since it's a plugin, it's not really dependant on a release anyways. > memcached_remap plugin > -- > > Key: TS-821 > URL: https://issues.apache.org/jira/browse/TS-821 > Project: Traffic Server > Issue Type: Improvement > Components: Plugins > Environment: Fedora 15 >Reporter: Opensource AT Navya Prabha >Assignee: Eric Balsa >Priority: Minor > Fix For: sometime > > Attachments: memcached_remap.tar.bz2 > > > to make ASF own memcached_remap plugin -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-467) Proxy shold not forward request headers that matches a Connection token
[ https://issues.apache.org/jira/browse/TS-467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-467: - Fix Version/s: (was: 3.1.1) 3.3.0 > Proxy shold not forward request headers that matches a Connection token > --- > > Key: TS-467 > URL: https://issues.apache.org/jira/browse/TS-467 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: Leif Hedstrom > Fix For: 3.3.0 > > > If a client sends a request like > X-foobar: fum > Connection: ,,X-foobar,, > the proxy (Traffic Server) MUST remove the header X-foobar before forwarding > the request. From the RFC: > HTTP/1.1 proxies MUST parse the Connection header field before a >message is forwarded and, for each connection-token in this field, >remove any header field(s) from the message with the same name as the >connection-token. > and > A system receiving an HTTP/1.0 (or lower-version) message that >includes a Connection header MUST, for each connection-token in this >field, remove and ignore any header field(s) from the message with >the same name as the connection-token. > (Originally discovered with Coadvisor). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-357) Compiling with -Wconversion generates a lot of errors
[ https://issues.apache.org/jira/browse/TS-357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-357: - Fix Version/s: (was: 3.1.1) 3.3.0 > Compiling with -Wconversion generates a lot of errors > - > > Key: TS-357 > URL: https://issues.apache.org/jira/browse/TS-357 > Project: Traffic Server > Issue Type: Improvement > Components: Cleanup >Affects Versions: 2.1.0 >Reporter: Bryan Call > Fix For: 3.3.0 > > > After adding -Wconversion to CFLAGS and CXXFLAGS I got 11k errors: > [bcall@snowball traffic.git]$ gmake -k 2> /dev/stdout | grep -c ' error: ' > 11432 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-608) Is HttpSessionManager::purge_keepalives() too aggressive?
[ https://issues.apache.org/jira/browse/TS-608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-608: - Fix Version/s: (was: 3.1.1) 3.3.0 > Is HttpSessionManager::purge_keepalives() too aggressive? > -- > > Key: TS-608 > URL: https://issues.apache.org/jira/browse/TS-608 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: Leif Hedstrom > Fix For: 3.3.0 > > Attachments: TS-608.patch > > > It seems that if we trigger the "max server connections", we call this purge > function in the session manager, which will close all currently open > keep-alive connections. This seems very aggressive, why not limit it to say > only removing 10% of each "bucket" or some such? Also, how does this work > together with per-origin limits? Ideally, if the per-origin limits are in > place, we would only purge sessions that are for the IP we wish to connect to > ? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-469) A PUT request should invalidate a previously cached object with the same URI
[ https://issues.apache.org/jira/browse/TS-469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-469: - Fix Version/s: (was: 3.1.1) 3.3.0 > A PUT request should invalidate a previously cached object with the same URI > > > Key: TS-469 > URL: https://issues.apache.org/jira/browse/TS-469 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Affects Versions: 2.1.6 >Reporter: Leif Hedstrom > Fix For: 3.3.0 > > > If the client first fetches an object with GET, and TS caches it, a > subsequent PUT request for the same URL should invalidate the cached object. > (Originally discovered with Coadvisor). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-464) Chunked response with bad Content-Length header to HTTP/1.0 clent is broken
[ https://issues.apache.org/jira/browse/TS-464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-464: - Fix Version/s: (was: 3.1.1) 3.3.0 > Chunked response with bad Content-Length header to HTTP/1.0 clent is broken > --- > > Key: TS-464 > URL: https://issues.apache.org/jira/browse/TS-464 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: Leif Hedstrom > Fix For: 3.3.0 > > > A client sends an HTTP/1.0 request through ATS, which gets proxied with > HTTP/1.1 to the origin. The origin (which is at fault here, but nonetheless) > returns with both > Content-Length: 10 > Transfer-Encoding: chunked > and a chunked body which is > 10 bytes long. In this case, ATS should still > respond with an HTTP/1.0 response, undoing the chunking, and return with an > appropriate CL: header. We do everything, except set the correct > Content-Length header, we simply return the erroneous CL header that the > Origin provided. This is not allowed in the RFC. > (Originally discovered using Coadvisor). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-468) We should respond with a 417 if we cannot meet an expectation
[ https://issues.apache.org/jira/browse/TS-468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-468: - Fix Version/s: (was: 3.1.1) 3.3.0 > We should respond with a 417 if we cannot meet an expectation > - > > Key: TS-468 > URL: https://issues.apache.org/jira/browse/TS-468 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: Leif Hedstrom > Fix For: 3.3.0 > > > If the client sends an Expect: header that we cannot meet, we should return a > 417 error. E.g. > Expect: expect=params > since we can't meet this expectation, we should return a 417, but instead we > forward this to the origin, and return with whatever it responds with. > (Originally found using Coadvisor). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-235) cleanup libinktomi++
[ https://issues.apache.org/jira/browse/TS-235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-235: - Fix Version/s: (was: 3.1.1) 3.3.0 > cleanup libinktomi++ > > > Key: TS-235 > URL: https://issues.apache.org/jira/browse/TS-235 > Project: Traffic Server > Issue Type: Improvement > Components: Cleanup >Affects Versions: 2.1.6 >Reporter: John Plevyak >Assignee: John Plevyak >Priority: Critical > Fix For: 3.3.0 > > Attachments: rename-inkmd5.sh > > > libinktomi++ is a bit of a mess... e.g. ink_port.h Portability.h > Compatability.h, yes you guessed > it, they all do very similar things. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-727) Do we need support for "streams" partitions?
[ https://issues.apache.org/jira/browse/TS-727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-727: - Fix Version/s: (was: 3.1.1) 3.3.0 > Do we need support for "streams" partitions? > > > Key: TS-727 > URL: https://issues.apache.org/jira/browse/TS-727 > Project: Traffic Server > Issue Type: Improvement >Reporter: Leif Hedstrom > Fix For: 3.3.0 > > > There's code in the cache related to MIXT streams volumes (caches). Since we > don't support streams, I'm thinking this code could be removed? Or > alternatively, we should expose APIs so that someone writing a plugin and > wish to store a different protocol (e.g. QT) can register this media type > with the API and core. The idea being that the core only contains protocols > that are in the core, but expose the cache core so that plugins can take > advantage of it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-846) Remap processor options could be integrated to a single option
[ https://issues.apache.org/jira/browse/TS-846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-846: - Fix Version/s: (was: 3.1.1) 3.3.0 > Remap processor options could be integrated to a single option > -- > > Key: TS-846 > URL: https://issues.apache.org/jira/browse/TS-846 > Project: Traffic Server > Issue Type: Improvement > Components: Configuration >Affects Versions: 3.0.0 >Reporter: Eric Balsa >Assignee: Eric Balsa >Priority: Minor > Fix For: 3.3.0 > > Original Estimate: 2h > Remaining Estimate: 2h > > TS_ReadConfigInteger(use_separate_thread, > "proxy.config.remap.use_remap_processor"); > and > TS_ReadConfigInteger(num_remap_threads, > "proxy.config.remap.num_remap_threads"); > should be changed to a single config > TS_ReadConfigInteger(num_remap_threads, > "proxy.config.remap.num_remap_threads"); > whereby a setting of "0" would indicate not to use a separate thread(s) for > remapping. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-518) Close UA connection early if the origin sent Connection close:, there's a bad Content-Length header, and the UA connection has Keep-Alive.
[ https://issues.apache.org/jira/browse/TS-518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-518: - Fix Version/s: (was: 3.1.1) 3.3.0 > Close UA connection early if the origin sent Connection close:, there's a bad > Content-Length header, and the UA connection has Keep-Alive. > -- > > Key: TS-518 > URL: https://issues.apache.org/jira/browse/TS-518 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: Leif Hedstrom > Fix For: 3.3.0 > > > In a very special case, we could improve the user experience by forcefully > closing the connection early. The case is > 1) The origin server sends a Content-Length: header that is wrong, where the > CL: value exceeds the actually body size. > 2) The origin server either sends a Connection: close, or it uses HTTP/1.0 > without keep-alive. > 3) The client (and TS) uses Keep-Alive to the UA. > In this case, we can end up stalling the UA until either the UA or the TS > connection times out. It might make sense to prematurely disconnect the > client when this case is detected. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-667) Ability to keep traffic server from initializing the wrong disks when using RAW disk mode.
[ https://issues.apache.org/jira/browse/TS-667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-667: - Fix Version/s: (was: 3.1.2) 3.2.0 > Ability to keep traffic server from initializing the wrong disks when using > RAW disk mode. > -- > > Key: TS-667 > URL: https://issues.apache.org/jira/browse/TS-667 > Project: Traffic Server > Issue Type: Improvement > Components: Cache, Configuration >Reporter: David Robinson >Priority: Minor > Labels: features > Fix For: 3.2.0 > > > When disk devices are configured in storage.config for RAW mode they are > automatically initialized when traffic server first starts up. If disk device > names change later due to adding/removing disks or kernel changes > trafficserver will overwrite disks that the user may not want to be cache > disks. This leads to data loss on the affected disks. > Maybe a feature could be added similar to squid's -z where cache disks must > be explicitly initialized before they can be used. Or a configuration > variable that changes trafficserver's initialization behavior. > (6:49:06 PM) zwoop: so, maybe have a few settings for the config > (6:49:06 PM) zwoop: 0 - Let it reinitialize cache as it likes > (6:49:06 PM) zwoop: 1 - Only initialize cache explicitly > (6:49:06 PM) zwoop: 2 - Only initialize cache explicitly, and refuse to start > up if we detect a cache disk with bad header -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-484) INKHttpTxnSetRespCacheableSet() vs INKHttpTxnServerRespNoStore()
[ https://issues.apache.org/jira/browse/TS-484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-484: - Fix Version/s: (was: 3.1.2) 3.2.0 > INKHttpTxnSetRespCacheableSet() vs INKHttpTxnServerRespNoStore() > > > Key: TS-484 > URL: https://issues.apache.org/jira/browse/TS-484 > Project: Traffic Server > Issue Type: Improvement >Reporter: Leif Hedstrom > Fix For: 3.2.0 > > > it seems that the logic around the new API INKHttpTxnSetRespCacheableSet() is > very similar to the old, existing INKHttpTxnServerRespNoStore(). Would it be > possible to "merge" the new API logic into the existing one (without changing > the old API) ? This would be a great thing to fix before we finalize v2.2, > to avoid breaking / adding more APIs. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-153) "Dynamic" keep-alive timeouts
[ https://issues.apache.org/jira/browse/TS-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-153: - Fix Version/s: (was: 3.1.2) 3.2.0 > "Dynamic" keep-alive timeouts > - > > Key: TS-153 > URL: https://issues.apache.org/jira/browse/TS-153 > Project: Traffic Server > Issue Type: New Feature > Components: Core >Reporter: Leif Hedstrom >Priority: Minor > Fix For: 3.2.0 > > > (This is from a Y! Bugzilla ticket 1821593, adding it here. . Originally > posted by Leif Hedstrom on 2008-03-19): > Currently you have to set static keep-alive idle timeouts in TS, e.g. >CONFIG proxy.config.http.keep_alive_no_activity_timeout_in INT 8 >CONFIG proxy.config.http.keep_alive_no_activity_timeout_out INT 30 > even with epoll() in 1.17.x, this is difficult to configure, and put an > appropriate timeout. The key here is that the > settings above need to assure that you stay below the max configured number > of connections, e.g.: > CONFIG proxy.config.net.connections_throttle INT 75000 > I'm suggesting that we add one (or two) new configuration options, and > appropriate TS code support, to instead of > specifying timeouts, we specify connection limits for idle KA connections. > For example: > CONFIG proxy.config.http.keep_alive_max_idle_connections_in INT 5 > CONFIG proxy.config.http_keep_alive_max_idle_connections_out INT 5000 > (one still has to be careful to leave head-room for active connections here, > in the example above, 2 connections > could be active, which is a lot of traffic). > These would override the idle timeouts, so one could use the max_idle > connections for incoming (client) connections, > and the idle timeouts for outgoing (origin) connections for instance. > The benefit here is that it makes configuration not only easier, but also a > lot safer for many applications. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-219) Daemon should not rely on init script exclusively for pid/lock removal.
[ https://issues.apache.org/jira/browse/TS-219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-219: - Fix Version/s: (was: 3.1.2) 3.2.0 > Daemon should not rely on init script exclusively for pid/lock removal. > --- > > Key: TS-219 > URL: https://issues.apache.org/jira/browse/TS-219 > Project: Traffic Server > Issue Type: Bug > Components: Core >Affects Versions: 2.0.0a >Reporter: Jason Giedymin >Priority: Minor > Labels: daemon, init, linux, lock, pid, script > Fix For: 3.2.0 > > > Having the ts daemon remove it's PID will be useful. > Init script can then do 'cleanup' if necessary. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-641) WebUI: Kill it with fire.
[ https://issues.apache.org/jira/browse/TS-641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-641: - Fix Version/s: (was: 3.1.2) 3.2.0 > WebUI: Kill it with fire. > - > > Key: TS-641 > URL: https://issues.apache.org/jira/browse/TS-641 > Project: Traffic Server > Issue Type: Improvement > Components: Web UI >Reporter: Igor Galić >Assignee: Igor Galić > Fix For: 3.2.0 > > Original Estimate: 14m > Remaining Estimate: 14m > > Get rid of proxy/mgmt/html2 > Get rid of all code in proxy/mgmt/web2 that is not used > Merge used code into proxy/mgmt/utils/WebMgmtUtils.* -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-658) HTTP SM holds the cache write lock for too long
[ https://issues.apache.org/jira/browse/TS-658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-658: - Fix Version/s: (was: 3.1.2) 3.2.0 > HTTP SM holds the cache write lock for too long > --- > > Key: TS-658 > URL: https://issues.apache.org/jira/browse/TS-658 > Project: Traffic Server > Issue Type: Bug >Reporter: Leif Hedstrom > Fix For: 3.2.0 > > > It seems we open the cache for write very early on in the HTTP SM, which can > have very bad effect on performance if the object is not cacheable. It's not > totally clear as to why this is done this way, but we should examine this for > v3.1, and try to minimize how long we hold the lock. It's possible this is > related to read_while_writer, but then it should be modified IMO. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-548) What is Initialize.cc /.h ??
[ https://issues.apache.org/jira/browse/TS-548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-548: - Fix Version/s: (was: 3.1.2) 3.2.0 > What is Initialize.cc /.h ?? > > > Key: TS-548 > URL: https://issues.apache.org/jira/browse/TS-548 > Project: Traffic Server > Issue Type: Bug > Components: Cleanup >Reporter: Leif Hedstrom > Fix For: 3.2.0 > > > This code isn't built, nor used, as far as I can tell, and seems "duplicated" > from what is available and used elsewhere. What is it? Should it be removed? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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: 3.1.2)
3.2.0
> 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.2.0
>
>
> {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.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-795) Clean up definitions and usage of buffer size indexes vs buffer sizes
[
https://issues.apache.org/jira/browse/TS-795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-795:
-
Fix Version/s: (was: 3.1.2)
3.2.0
> Clean up definitions and usage of buffer size indexes vs buffer sizes
> -
>
> Key: TS-795
> URL: https://issues.apache.org/jira/browse/TS-795
> Project: Traffic Server
> Issue Type: Improvement
> Components: Core
>Reporter: Leif Hedstrom
> Fix For: 3.2.0
>
>
> Right now, we have a set of defines, and APIs, which can take either a
> "index" to a size (used e.g. for an allocator index), or a real size. Both of
> these are currently int64_t in all APIs and member variables, and in the
> implementations, the usage are sometimes overloaded (i.e. we do "size"
> calculations on top of the indexes, making for real confusing code).
> There's also a lack of proper identification of what is an "size index" type
> (or parameter), and what is a "size". This makes for risky code.
> I think we should clean up all the implementations and APIs, as follow
> 1) Make proper names of all APIs and macros, clearly indicating if it's
> working on a size index or a size.
> 2) Keep only the size types, parameters and macros using int64_t. Do not
> overload "real" size over the size indexes.
> 3) We either make the size indexes an "int" (or even a short), or perhaps
> even better an enum (like below). All APIs, parameters, and member variables
> that refer to such size indexes would use this appropriate type.
> {code}
> enum BufferSizeIndex {
> BUFFER_SIZE_INDEX_128 = 0,
> BUFFER_SIZE_INDEX_256, /* 1 */
> BUFFER_SIZE_INDEX_512, /* 2 */
> BUFFER_SIZE_INDEX_1K,/* 3 */
> BUFFER_SIZE_INDEX_2K,/* 4 */
> BUFFER_SIZE_INDEX_4K,/* 5 */
> BUFFER_SIZE_INDEX_8K,/* 6 */
> BUFFER_SIZE_INDEX_16K, /* 7 */
> BUFFER_SIZE_INDEX_32K, /* 8 */
> BUFFER_SIZE_INDEX_64K, /* 9 */
> BUFFER_SIZE_INDEX_128K, /* 10 */
> BUFFER_SIZE_INDEX_256K, /* 11 */
> BUFFER_SIZE_INDEX_512K, /* 12 */
> BUFFER_SIZE_INDEX_1M,/* 13 */
> BUFFER_SIZE_INDEX_2M,/* 14 */
> /* These have special semantics */
> BUFFER_SIZE_NOT_ALLOCATED,
> };
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-274) UA side SSL support in forward proxy
[
https://issues.apache.org/jira/browse/TS-274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-274:
-
Fix Version/s: (was: 3.1.2)
3.2.0
> UA side SSL support in forward proxy
>
>
> Key: TS-274
> URL: https://issues.apache.org/jira/browse/TS-274
> Project: Traffic Server
> Issue Type: New Feature
> Components: SSL
>Affects Versions: 2.1.0, 2.0.0a
> Environment: Debian, Linux 2.6.18 32-bit
>Reporter: Marcus Clyne
> Labels: ssl
> Fix For: 3.2.0
>
>
> Using self-signed SSL certificates, which are in the correct paths under
> $prefix, and giving no startup errors, I get the following error when making
> a request through the proxy :
> Mar 24 14:35:09 www traffic_server[27926]: {1146895248} ERROR: SSL ERROR:
> SSL_ServerHandShake.
> Mar 24 14:35:09 www traffic_server[27926]: {1146895248} ERROR:
> SSL::5:error:1407609B:SSL routines:SSL23_GET_CLIENT_HELLO:https proxy
> request:s23_srvr.c:384:
> Mar 24 14:36:47 www traffic_server[27926]: {1146895248} ERROR: SSL ERROR:
> SSL_ServerHandShake.
> Mar 24 14:36:47 www traffic_server[27926]: {1146895248} ERROR:
> SSL::5:error:1407609C:SSL routines:SSL23_GET_CLIENT_HELLO:http
> request:s23_srvr.c:379:
> The first of these two was from using Proxifier (Windows software) to connect
> to the server, the second is from using `curl -k -x $ip:443
> http://google.com/`.
> The issue appears on the latest trunk version and the 2.0.x branch as of
> today when used in forward proxy mode.
> I have not personally tested in reverse proxy mode, but zwoop (Freenode IRC
> name) tested in reverse proxy mode, and reverse proxy mode worked only in the
> 2.0.x but not trunk.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-149) Split ram and disk cache hit response times into separate metrics
[ https://issues.apache.org/jira/browse/TS-149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-149: - Fix Version/s: (was: 3.1.2) 3.2.0 > Split ram and disk cache hit response times into separate metrics > - > > Key: TS-149 > URL: https://issues.apache.org/jira/browse/TS-149 > Project: Traffic Server > Issue Type: New Feature > Components: Cache >Reporter: Anirban >Priority: Minor > Fix For: 3.2.0 > > > Split ram and disk cache hit response times into separate metrics > Original description > by Stephen Bisordi from Yahoo > It appears that the response time for ram cache hits and disk cache hits is > captured as a single metric > (transaction_totaltime.hit_fresh). Would it be possible to split this into > two separate metrics, or to add a ram cache > hit result code to the log to differentiate between ram and disk hits > (similar to Squid's TCP_MEM_HIT)? > This change would allow for quicker troubleshooting of certain issues such as > poor disk performance. > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-698) LogFilter should support an actual IP type and matching rules
[
https://issues.apache.org/jira/browse/TS-698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-698:
-
Fix Version/s: (was: 3.1.2)
3.2.0
> LogFilter should support an actual IP type and matching rules
> -
>
> Key: TS-698
> URL: https://issues.apache.org/jira/browse/TS-698
> Project: Traffic Server
> Issue Type: Improvement
> Components: Logging
>Affects Versions: 2.1.6
> Environment: N/A
>Reporter: Eric Connell
>Priority: Minor
> Fix For: 3.2.0
>
>
> The LogFilter configuration in logs_xml.config should support a native IPv4
> and IPv6 filtering. For example, it would be handy to be able to filter out
> log lines from a specific server or netblock. For example, the following
> config would reject log lines for all hosts in the 10/8 network:
> {code}
>
>
>
>
>
>
>
>
> "/>
>
>
>
>
>
>
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-54) UnixNet cleanup, encapsulation of event subsystem
[ https://issues.apache.org/jira/browse/TS-54?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-54: Fix Version/s: (was: 3.1.2) 3.2.0 > UnixNet cleanup, encapsulation of event subsystem > - > > Key: TS-54 > URL: https://issues.apache.org/jira/browse/TS-54 > Project: Traffic Server > Issue Type: Improvement > Components: Cleanup > Environment: all unixesque >Reporter: John Plevyak >Assignee: John Plevyak > Fix For: 3.2.0 > > Attachments: proposed-jp-v1-List.h, ts-List-net-cleanup-jp-v2.patch, > ts-List_and_net-cleanup-jp-v1.patch > > Original Estimate: 72h > Remaining Estimate: 72h > > The UnixNet subsystem was modified for epoll, but lots of the old data > structures, data members and code > remain for the old "bucket" approach. > The epoll code should also be encapsulated to simplify support for other > platforms and a possible move > to an event library. > The current code is complicated by limitations in Queue which require > specifying the link field for every > use, but which can be fixed by in the template. > Finally, the current code does an unnecessary allocation for the epoll struct > which should be part of the NetVConnection etc. > and it takes a lock for the enable_queue which can be avoided by using the > non-locking AtomicSSL. > This work is also good preparation for evaluating libev or libevent as it > will reduce the amount of code which > will have to be changed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-305) sigTERM should cause a user-friendly shutdown
[ https://issues.apache.org/jira/browse/TS-305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-305: - Fix Version/s: (was: 3.1.2) 3.2.0 > sigTERM should cause a user-friendly shutdown > - > > Key: TS-305 > URL: https://issues.apache.org/jira/browse/TS-305 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Reporter: Miles Libbey >Priority: Minor > Fix For: 3.2.0 > > > (from yahoo bug 848837) > Original description > by Scott Manjourides 3 years ago at 2006-10-16 15:48 > On Monday 16 October 2006 03:01 pm, Ryan Troll wrote: > > Open a RFE asking to have sigTERM cause a user-friendly > > shutdown? Something like: > > > > - immediately set all KeepAlive timeout values to 5 seconds > > > > :: Optional, but could make shutdown faster than leaving at > > :: whatever the property specified. > > > > - no longer accept new connections > > - process exits when all existing connections close > > > > > > -R > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-766) Authenticate access to cluster command port
[ https://issues.apache.org/jira/browse/TS-766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-766: - Fix Version/s: (was: 3.1.2) 3.2.0 > Authenticate access to cluster command port > --- > > Key: TS-766 > URL: https://issues.apache.org/jira/browse/TS-766 > Project: Traffic Server > Issue Type: Improvement > Components: Clustering, Network >Affects Versions: 2.1.8 >Reporter: Arno Toell > Labels: security > Fix For: 3.2.0 > > > Similar to TS-765, the cluster RPC interface should not be reachable by > everyone. Instead some kind of peer authentication should apply. When > clustering is enabled, please authenticate and/or restrict access to the RPC > interface in a way only trusted peers are allowed to control the server. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-310) modifying global_user_agent_header requires restart
[ https://issues.apache.org/jira/browse/TS-310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-310: - Fix Version/s: (was: 3.1.2) 3.2.0 > modifying global_user_agent_header requires restart > --- > > Key: TS-310 > URL: https://issues.apache.org/jira/browse/TS-310 > Project: Traffic Server > Issue Type: Improvement > Components: Configuration >Reporter: Miles Libbey >Priority: Minor > Fix For: 3.2.0 > > > (was y bug 1389544) > Original description > by Leif Hedstrom2 years ago at 2007-07-26 16:38 > I don't know why, or if it's intentional, but modifying the config for > proxy.config.http.global_user_agent_header > requires a server restart. This is obviously not a huge problem, but > inconsistent and confusing. I can't think of any > reasons why we shouldn't support "dynamically" rereading this particular > configuration. > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-407) traffic_server not using proxy.config.syslog_facility
[
https://issues.apache.org/jira/browse/TS-407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-407:
-
Fix Version/s: (was: 3.1.2)
3.2.0
> traffic_server not using proxy.config.syslog_facility
> -
>
> Key: TS-407
> URL: https://issues.apache.org/jira/browse/TS-407
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Reporter: Leif Hedstrom
> Fix For: 3.2.0
>
>
> We have this code in Main.cc:
> static int syslog_facility = LOG_DAEMON;
> // static void syslog_log_configure()
> //
> // Reads the syslog configuration variable
> // and sets the global integer for the
> // facility and calls open log with the
> // new facility
> //
> static void
> syslog_log_configure()
> {
> char *facility_str = NULL;
> int facility;
> TS_ReadConfigStringAlloc(facility_str, "proxy.config.syslog_facility");
> if (facility_str == NULL || (facility =
> facility_string_to_int(facility_str)) < 0) {
> syslog(LOG_WARNING, "Bad or missing syslog facility. " "Defaulting to
> LOG_DAEMON");
> } else {
> syslog_facility = facility;
> closelog();
> openlog("traffic_server", LOG_PID | LOG_NDELAY | LOG_NOWAIT, facility);
> }
> }
> But as far as I can tell, we never use syslog_facility.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-182) Make it possible to have proxy.config.proxy_name default to `hostname`
[ https://issues.apache.org/jira/browse/TS-182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-182: - Fix Version/s: (was: 3.1.2) 3.2.0 > Make it possible to have proxy.config.proxy_name default to `hostname` > -- > > Key: TS-182 > URL: https://issues.apache.org/jira/browse/TS-182 > Project: Traffic Server > Issue Type: Improvement > Components: Configuration >Reporter: Leif Hedstrom >Priority: Minor > Fix For: 3.2.0 > > > It'd be nice if we could make the records.config setting for the "proxy name" > be something like > CONFIG proxy.config.proxy_name STRING "%h" > where %h evaluates to the equivalent of `hostname`. I don't know what other % > strings could be useful, but maybe > %p - port > %d - the domain (`domainname`) > %i - the IP -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-309) Report OS Errors in Header
[ https://issues.apache.org/jira/browse/TS-309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-309: - Fix Version/s: (was: 3.1.2) 3.2.0 > Report OS Errors in Header > -- > > Key: TS-309 > URL: https://issues.apache.org/jira/browse/TS-309 > Project: Traffic Server > Issue Type: Improvement > Components: HTTP >Reporter: Miles Libbey > Fix For: 3.2.0 > > > (from yahoo bug 1021194) > Original description > by Ryan Troll 3 years ago at 2007-01-17 13:20 > Cleaning out my mailbox; and I didn't want this to disappear. Back on 12/12 > Scott asked for a way to look at a YTS > response and differentiate between a TS error, and an Origin server error. > I *think* the general idea is that, whenever the origin server returns an > error; we return it to the client. > However, if there's a problem contacting the origin server, we should return > the appropriate HTTP response: > http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.5 > including > 500 Internal Server Error > 501 Not Implemented > 502 Bad Gateway > 503 Service Unavailable > 504 Gateway Timeout > 505 HTTP Version Not Supported > and specify what Origin Server triggered the error in the Warning header: > http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.46 > I think we could define our own warn code and use it specify the origin > server host (by name and IP): > 504 Gateway Timeout > Date: Wed, 17 Jan 2007 21:17:25 GMT > Warning: 599 l1.ycs.s1s.yahoo.com:80 "OS: us.yimg.com [66.218.71.81]" > But that's just a thought. Maybe mnot has a good suggestion -- he pointed us > towards the Warning: header, and may > know of good examples of it's use in the real world. > > > Comment 1 > by Chuck Neerdaels 3 years ago at 2007-01-18 16:33:15 > There's a pretty cool feature in TS, where it embeds codes into a Via > header (if those are turned on) where someone looking at the headers can see > whether it was a cache hit, an IMS hit, etc. As it moves through the state > machine, it appends characters to the string - and in the reply you get > something like [uN l oS f pS eN] which would translate to a user issuing a > no-cache pragma, that resulted in an origin server fetch, which was served > without error. It's pretty useful, so we might want to consider enabling > this. > There's a cheat sheet at > /dev/traffic/trunk/proxy/http2/README.via > chuck -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-58) Logging: Unified logging
[ https://issues.apache.org/jira/browse/TS-58?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-58: Fix Version/s: (was: 3.1.2) 3.2.0 > Logging: Unified logging > > > Key: TS-58 > URL: https://issues.apache.org/jira/browse/TS-58 > Project: Traffic Server > Issue Type: Improvement > Components: Logging >Affects Versions: 2.0.0a > Environment: All platforms >Reporter: George Paul >Priority: Minor > Fix For: 3.2.0 > > > There is a request to unify the logging in Traffic Server system. This would > entail modifying the Diagnostic logging system to use the internal > transaction logging system which uses non-locking buffers and a separate > thread. The changes would affect both the Traffic Server and Traffic Manager > which use the Diagnostic logging for event logging similar to syslog(). > -George -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-628) Add better config option for forward proxying
[ https://issues.apache.org/jira/browse/TS-628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-628: - Fix Version/s: (was: 3.1.2) 3.2.0 > Add better config option for forward proxying > - > > Key: TS-628 > URL: https://issues.apache.org/jira/browse/TS-628 > Project: Traffic Server > Issue Type: Improvement > Components: Configuration > Environment: All >Reporter: Marcus Clyne >Priority: Trivial > Fix For: 3.2.0 > > > Hi, > When setting up forward proxy on TS, currently it is required to set > proxy.config.url_remap.remap_required INT 0 > This is a bit obscure, and makes it more difficult for people who only work > with TS on an occasional basis to guess at the config option. > I think having an option like > proxy.config.forward_proxy.enable > or > proxy.config.http.forward.enable (so it's similar to > proxy.config.http.forward.proxy_auth_to_parent) > would be better. > It might be a good idea (at least for a period) to have both options, so as > not to break existing configurations. > If it is decided not to change the config option, as a minimum, it would be > nice to have a comment in the configuration file saying something like 'this > needs to be set to 0 to enable forward proxying'. This would allow for > people to search the config file for the word 'forward'. > Cheers, > Marcus. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-563) Incorrectly returned 0 status code from startup script even when TS fails to start
[ https://issues.apache.org/jira/browse/TS-563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-563: - Fix Version/s: (was: 3.1.2) 3.2.0 > Incorrectly returned 0 status code from startup script even when TS fails to > start > -- > > Key: TS-563 > URL: https://issues.apache.org/jira/browse/TS-563 > Project: Traffic Server > Issue Type: Bug >Affects Versions: 2.1.5 > Environment: Linux >Reporter: Marcus Clyne >Priority: Trivial > Fix For: 3.2.0 > > > When using proxy.config.log2 values in records.config rather than the new > proxy.config.log values, TS fails to start (server/manager/cop), but a return > code of 0 is returned rather than 1 or something more meaningful. > I have also noticed instances when config errors have prevented server from > starting, even though manager and cop do. It would probably make sense to > have a non-zero error code for these two. > Perhaps it might be useful to have different return codes for whether > cop/manager/server start or not (e.g. 1=server not started, 2=manager not > started, 3=cop not started? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-203) config files ownership
[ https://issues.apache.org/jira/browse/TS-203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-203: - Fix Version/s: (was: 3.1.2) 3.2.0 > config files ownership > -- > > Key: TS-203 > URL: https://issues.apache.org/jira/browse/TS-203 > Project: Traffic Server > Issue Type: Bug > Components: Build >Reporter: Leif Hedstrom >Priority: Minor > Fix For: 3.2.0 > > > It's semi-odd that the admin user (nobody) is also the user as to which > traffic_server process changes it's euid to. This means that the > traffic_server process has write permissions on the config files. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-391) Cleanup file header descriptions
[ https://issues.apache.org/jira/browse/TS-391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-391: - Fix Version/s: (was: 3.1.2) 3.2.0 > Cleanup file header descriptions > > > Key: TS-391 > URL: https://issues.apache.org/jira/browse/TS-391 > Project: Traffic Server > Issue Type: Improvement > Components: Cleanup >Reporter: Leif Hedstrom >Priority: Minor > Fix For: 3.2.0 > > > Most of our file headers has a Doxygen comment like > /** @file > A brief file description > We should fix this, and properly describe each file. :) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-481) Missing remap support for two cases
[ https://issues.apache.org/jira/browse/TS-481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-481: - Fix Version/s: (was: 3.1.2) 3.2.0 > Missing remap support for two cases > --- > > Key: TS-481 > URL: https://issues.apache.org/jira/browse/TS-481 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: Leif Hedstrom > Fix For: 3.2.0 > > > There are two cases where the remap processor is not used, but it should. As > of v2.1.4, the broken support was removed (broken code is worse than no > code), making two cases not use / support "remap" features. Both cases > currently call request_url_remap() which is now set to return false. The two > cases are > 1) If you configure remap mode to be URL_REMAP_FOR_OS (2). This is an > undocumented feature, I don't even know when or why you'd want to use it. The > setting in RecordsConfig.cc is proxy.config.url_remap.url_remap_mode, which > defaults to "1". > 2) If TS uses "raw" connections, I think for example when using the CONNECT > method, we will not do remap rules. This would be in a forward proxy mode, > primarily for things like HTTPS afaik. > I don't think either case are critical to get support for the remap processor > for v2.2, but please adjust the fix version if necessary. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-656) reimplement Connection Collapsing in a smoth way
[ https://issues.apache.org/jira/browse/TS-656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-656: - Fix Version/s: (was: 3.1.2) 3.2.0 > reimplement Connection Collapsing in a smoth way > > > Key: TS-656 > URL: https://issues.apache.org/jira/browse/TS-656 > Project: Traffic Server > Issue Type: Improvement >Affects Versions: 2.1.6 > Environment: per discussed in IRC, we'd like to clean the current CC > codes from trunk. >Reporter: Zhao Yongming > Fix For: 3.2.0 > > > we should figure out how to implement the Connection Collapsing that not so > ugly. target for V3.1 or so. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-672) cleanup Win32 references
[ https://issues.apache.org/jira/browse/TS-672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-672: - Fix Version/s: (was: 3.1.2) 3.2.0 > cleanup Win32 references > > > Key: TS-672 > URL: https://issues.apache.org/jira/browse/TS-672 > Project: Traffic Server > Issue Type: Improvement >Reporter: Igor Galić > Fix For: 3.2.0 > > > See: http://www.mail-archive.com/dev@trafficserver.apache.org/msg02413.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-382) socket option "cleanup" (and bug fixes)
[ https://issues.apache.org/jira/browse/TS-382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-382: - Fix Version/s: (was: 3.1.2) 3.2.0 > socket option "cleanup" (and bug fixes) > --- > > Key: TS-382 > URL: https://issues.apache.org/jira/browse/TS-382 > Project: Traffic Server > Issue Type: Bug > Components: Network >Reporter: Leif Hedstrom > Fix For: 3.2.0 > > > This is a bug moved from Y! Bugzilla, I'm posting the original bug > description and a few comments separately. Note that the bug description is > fairly limited, but while looking at this code, I noticed a lot of oddities > with the "socket option" support (lots of hardcoded stuff, and most of it is > not configurable). > Note that the original bug should have been fixed already in Apache TS, but > the other comments are still applicable. > From Bugzilla (posted by Leif): > We have two socket option config options in records.config: > proxy.config.net.sock_option_flag_in > proxy.config.net.sock_option_flag_out > With accept thread enabled, at least the _in option isn't honored. There are > possibly other cases in UnixNetAccept.cc > that we don't honor these flags either. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-315) Add switch to disable config file generation/runtime behavior changing
[ https://issues.apache.org/jira/browse/TS-315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-315: - Fix Version/s: (was: 3.1.2) 3.2.0 > Add switch to disable config file generation/runtime behavior changing > -- > > Key: TS-315 > URL: https://issues.apache.org/jira/browse/TS-315 > Project: Traffic Server > Issue Type: Improvement > Components: Configuration >Reporter: Miles Libbey >Priority: Minor > Fix For: 3.2.0 > > > (was yahoo bug 1863676) > Original description > by Michael S. Fischer 2 years ago at 2008-04-09 09:52 > In production, in order to improve site stability, it is imperative that TS > never accidentally overwrite its own > configuration files. > For this reason, we'd like to request a switch be added to TS, preferably via > the command line, that disables all > automatic configuration file generation or other runtime behavioral changes > initiated by any form of IPC other than > 'traffic_line -x' (including the web interface, etc.) > > > Comment 1 > by Bjornar Sandvik 2 years ago at 2008-04-09 09:57:17 > A very crucial request, in my opinion. If TS needs to be able to read > command-line config changes on the fly, these > changes should be stored in another config file (for example > remap.config.local instead of remap.config). We have a > patch config package that overwrites 4 of the config files under > /home/conf/ts/, and with all packages > we'd like to think that the content of these files can't change outside our > control. > > Comment 2 > by Bryan Call 2 years ago at 2008-04-09 11:02:46 > traffic_line -x doesn't modify the configuration, it reloads the > configuration files. If we want to have an option for > this it would be good to have it as an option configuration file (CONFIG > proxy.config.write_protect INT 1). > It would be an equivalent of write protecting floppies (ahh the memories)... > > > Comment 3 > by Michael S. Fischer 2 years ago at 2008-04-09 11:09:09 > I don't think it would be a good idea to have this in the configuration file, > as it would introduce a chicken/egg > problem. > > > Comment 4 > by Leif Hedstrom 19 months ago at 2008-08-27 12:43:17 > So I'm not 100% positive that this isn't just a bad interaction. Now, it's > only > triggered when trafficserver is running, but usually what ends up happening > is that we get a records.config which > looks like it's the default config that comes with the trafficserver package. > It's possible it's all one and the same issue, or we might have two issues. > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-659) Reduce cross dependencies in various modules
[
https://issues.apache.org/jira/browse/TS-659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-659:
-
Fix Version/s: (was: 3.1.2)
3.2.0
> Reduce cross dependencies in various modules
>
>
> Key: TS-659
> URL: https://issues.apache.org/jira/browse/TS-659
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Reporter: Leif Hedstrom
> Fix For: 3.2.0
>
>
> Right now, it's very difficult to build things (e.g. traffic_logcat) without
> including pretty much the entire code base. This is because of cross
> dependencies between various modules and libraries. So, where "logging" ought
> to be fairly self sustained, it really isn't. In an attempt to decouple this
> a little, I made a stub .cc file, which traffic_logcat and traffic_logstats
> uses. Yes this is ugly. Yes, it should be fixed (hence this bug). But it
> reduces the binary size for these binaries in the normal build from around
> 34MB to 4MB, each ...
> As a help to isolate *some* of the cross dependencies, here's the ugly stub
> code:
> {code}
> #include "libts.h"
> #include "LogObject.h"
> #if defined(solaris)
> #include
> #include
> #endif
> #include "P_Net.h"
> int fds_limit = 8000;
> UDPNetProcessor &udpNet;
> ClassAllocator udpPacketAllocator("udpPacketAllocator");
> void
> UDPConnection::Release()
> {
> ink_release_assert(false);
> }
> void
> UDPNetProcessor::FreeBandwidth(Continuation * udpConn)
> {
> ink_release_assert(false);
> }
> NetProcessor& netProcessor;
> Action *
> UnixNetProcessor::connect_re_internal(Continuation * cont, unsigned int ip,
> int port, NetVCOptions * opt)
> {
> ink_release_assert(false);
> return NULL;
> }
> #include "InkAPIInternal.h"
> ConfigUpdateCbTable *global_config_cbs = NULL;
> void
> ConfigUpdateCbTable::invoke(const char *name)
> {
> ink_release_assert(false);
> }
> const char *
> event_int_to_string(int event, int blen, char *buffer)
> {
> ink_release_assert(false);
> return NULL;
> }
> struct Machine;
> Machine *
> this_machine()
> {
> ink_release_assert(false);
> return NULL;
> }
> #include "LogConfig.h"
> void
> LogConfig::setup_collation(LogConfig * prev_config)
> {
> ink_release_assert(false);
> }
> void
> LogConfig::create_pre_defined_objects_with_filter(const
> PreDefinedFormatInfoList & pre_def_info_list, size_t num_filters,
> LogFilter ** filter, const
> char *filt_name, bool force_extension)
> {
> ink_release_assert(false);
> }
> int
> LogHost::write(LogBuffer * lb, size_t * to_disk, size_t * to_net, size_t *
> to_pipe)
> {
> ink_release_assert(false);
> return 0;
> }
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-53) remove old management code
[ https://issues.apache.org/jira/browse/TS-53?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-53: Fix Version/s: (was: 3.1.2) 3.2.0 > remove old management code > -- > > Key: TS-53 > URL: https://issues.apache.org/jira/browse/TS-53 > Project: Traffic Server > Issue Type: Improvement > Components: Cleanup >Reporter: Bryan Call >Priority: Minor > Fix For: 3.2.0 > > > Remove old management code that we won't use. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-57) Logging: IP's being logged in text mode when binary mode enabled for logging
[ https://issues.apache.org/jira/browse/TS-57?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-57: Fix Version/s: (was: 3.1.2) 3.2.0 > Logging: IP's being logged in text mode when binary mode enabled for logging > - > > Key: TS-57 > URL: https://issues.apache.org/jira/browse/TS-57 > Project: Traffic Server > Issue Type: Bug > Components: Logging >Affects Versions: 2.0.0a > Environment: All platforms >Reporter: George Paul >Assignee: George Paul >Priority: Trivial > Fix For: 3.2.0 > > > It was reported that IP's were being logged in text mode when binary logging > was enabled. This needs to be investigated and addressed if needed. > -George -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-646) Manager should be able to restart/crash w/o taking down the traffic server process.
[ https://issues.apache.org/jira/browse/TS-646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-646: - Fix Version/s: (was: 3.1.2) 3.2.0 > Manager should be able to restart/crash w/o taking down the traffic server > process. > --- > > Key: TS-646 > URL: https://issues.apache.org/jira/browse/TS-646 > Project: Traffic Server > Issue Type: Improvement > Components: Management >Reporter: John Plevyak > Fix For: 3.2.0 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-341) Update Contrib Scripts
[ https://issues.apache.org/jira/browse/TS-341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-341: - Fix Version/s: (was: 3.1.2) 3.2.0 > Update Contrib Scripts > -- > > Key: TS-341 > URL: https://issues.apache.org/jira/browse/TS-341 > Project: Traffic Server > Issue Type: Bug > Components: Build >Affects Versions: 2.0.0 > Environment: EC2 >Reporter: Jason Giedymin >Assignee: Jason Giedymin >Priority: Minor > Labels: Contrib, EC2, Scripts > Fix For: 3.2.0 > > > - The EC2 images i created last month had updates to the contrib scripts > which need to be synced with the source repo. > - Need to udpate the scripts to point to the source repo -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-312) add option to always share keep-alive connections to the origin server
[ https://issues.apache.org/jira/browse/TS-312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-312: - Fix Version/s: (was: 3.1.2) 3.2.0 > add option to always share keep-alive connections to the origin server > --- > > Key: TS-312 > URL: https://issues.apache.org/jira/browse/TS-312 > Project: Traffic Server > Issue Type: Improvement > Components: Network >Reporter: Miles Libbey >Assignee: Leif Hedstrom >Priority: Minor > Fix For: 3.2.0 > > > (was yahoo bug 1411758) > Original description > by Bryan Call (bcall) 2 years ago at 2007-08-08 13:35 > Leif and I were talking about extending the meaning of > proxy.config.http.share_server_session for reusing keep-alive connections > from the TS server and the origin server, for separate clients attached to > TS. You can read more about this in > [BUG 1162233]. The configuration options should be: > so lets add more "options" to share_server_session? E.g. > 0 - Never share/reuse connections > 1 - Share/reuse connections if max_connections is set (default) > 2 - Always try to share-reuse connections > option 1 will give the behavior we currently have and 2 will always try to > share the keep-alive connections to the > origin servers. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-777) Increasing logbuffer size makes us "drop" log entries
[ https://issues.apache.org/jira/browse/TS-777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-777: - Fix Version/s: (was: 3.1.2) 3.2.0 > Increasing logbuffer size makes us "drop" log entries > - > > Key: TS-777 > URL: https://issues.apache.org/jira/browse/TS-777 > Project: Traffic Server > Issue Type: Bug > Components: Logging >Affects Versions: 2.1.8 >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom > Fix For: 3.2.0 > > > Setting proxy.config.log.log_buffer_size higher than somewhere around 24KB > makes us start losing log entries. This is bad, since increasing this setting > could be a way to increase performance for busy systems. I've for now set the > defaults to 16KB, which seems to be stable. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-374) Potentially eliminate lock contention on HostDB
[ https://issues.apache.org/jira/browse/TS-374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-374: - Fix Version/s: (was: 3.1.2) 3.2.0 > Potentially eliminate lock contention on HostDB > --- > > Key: TS-374 > URL: https://issues.apache.org/jira/browse/TS-374 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Reporter: Leif Hedstrom > Fix For: 3.2.0 > > > When using as a reverse proxy, when a single (or very few) HostDB entries are > under "pressure", the try-lock there could cause us to reschedule. John > suggests we look at this as a first step towards reducing latencies under > high load, by avoiding holding the lock over multiple callbacks. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-119) RAM only caching
[ https://issues.apache.org/jira/browse/TS-119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-119: - Fix Version/s: (was: 3.1.2) 3.2.0 > RAM only caching > > > Key: TS-119 > URL: https://issues.apache.org/jira/browse/TS-119 > Project: Traffic Server > Issue Type: Improvement > Components: Cache >Reporter: John Plevyak >Priority: Minor > Fix For: 3.2.0 > > > It would be nice if we could run with a RAM only cache. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-905) Improve state machine around DNS lookups and handling of URL_REMAP_FOR_OS
[ https://issues.apache.org/jira/browse/TS-905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-905: - Fix Version/s: (was: 3.1.2) 3.2.0 > Improve state machine around DNS lookups and handling of URL_REMAP_FOR_OS > - > > Key: TS-905 > URL: https://issues.apache.org/jira/browse/TS-905 > Project: Traffic Server > Issue Type: Improvement > Components: DNS, HTTP >Reporter: Leif Hedstrom > Fix For: 3.2.0 > > > The code around DNS lookups in the HTTP state machine is somewhat odd. The > same state is revisited at least twice in the case of a parent proxy lookup > for example, and the internal state is not reset in between such lookups. > This caused breakage of parent proxy when we added an API to bypass origin > DNS lookup, as a very obscure side effect. > Also, there's code in there for a remapping mode URL_REMAP_FOR_OS (2), which > I believe we have crippled, and it's unclear exactly when it would be used. > We should examine this, and either fix this mode, or disable it completely. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-371) Add common process code
[ https://issues.apache.org/jira/browse/TS-371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-371: - Fix Version/s: (was: 3.1.2) 3.2.0 > Add common process code > --- > > Key: TS-371 > URL: https://issues.apache.org/jira/browse/TS-371 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Affects Versions: 2.1.2 >Reporter: Mladen Turk >Assignee: Mladen Turk >Priority: Minor > Fix For: 3.2.0 > > Attachments: ink_proc.diff > > > Use the new ink_proc common API for allowing better child and daemon process > control. > The common task if "daemonizing" the process is abstracted into API making it > available for multiple > programs instead duplicating code. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-199) Startup script should fail on "multiple" invocations of "start" (or "stop")
[ https://issues.apache.org/jira/browse/TS-199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-199: - Fix Version/s: (was: 3.1.2) 3.2.0 > Startup script should fail on "multiple" invocations of "start" (or "stop") > --- > > Key: TS-199 > URL: https://issues.apache.org/jira/browse/TS-199 > Project: Traffic Server > Issue Type: Improvement > Components: Packaging >Reporter: Leif Hedstrom >Priority: Minor > Fix For: 3.2.0 > > Attachments: TS-199__trafficserver.in__JasonGiedymin.patch > > > If I do > # /etc/init.d/trafficserver start > # /etc/init.d/trafficserver start > I'd expect the second invocation to give an error, [NO]. Same thing with > stop, if I run stop multiple times, if there are no process(es) to stop, each > invocation ought to generate errors as well, e.g. > root@loki 507/0 # ./local/bin/trafficserver stop > Stopping : [ OK ] > Stopping : [ OK ] > Stopping : [ OK ] > root@loki 508/0 # ./local/bin/trafficserver stop > Stopping : [ NOT ] > Stopping : [ NOT ] > Stopping : [ NOT ] -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-823) Build fails with --enable-standalone-iocore
[
https://issues.apache.org/jira/browse/TS-823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-823:
-
Fix Version/s: (was: 3.1.2)
3.2.0
> Build fails with --enable-standalone-iocore
> ---
>
> Key: TS-823
> URL: https://issues.apache.org/jira/browse/TS-823
> Project: Traffic Server
> Issue Type: Bug
> Components: Build
>Affects Versions: 3.1.0, 2.1.8
>Reporter: Igor Galić
> Fix For: 3.2.0
>
>
> When enabling ./configuring the build with --enable-standalone-iocore the
> build fails with:
> {noformat}
> igalic@bawnb976 ~/Projects/asf/trafficserver/iocore/dns (svn)-[trunk:1132769]
> % make
> g++ -DHAVE_CONFIG_H -I. -I../../lib/ts -I../../iocore/eventsystem
> -I../../iocore/net -I../../iocore/aio -I../../iocore/hostdb
> -I../../iocore/cache -I../../iocore/cluster -I../../iocore/utils
> -I../../iocore/dns -I../../lib/records -D_LARGEFILE64_SOURCE=1
> -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -D_REENTRANT -Dlinux
> -I/usr/include/tcl8.4 -march=native -mtune=native -march=i586 -g -pipe -Wall
> -Werror -O3 -feliminate-unused-debug-symbols -fno-strict-aliasing
> -Wno-invalid-offsetof -MT DNS.o -MD -MP -MF .deps/DNS.Tpo -c -o DNS.o DNS.cc
> DNS.cc: In member function 'virtual int DNSProcessor::start(int)':
> DNS.cc:132:7: error: 'SplitDNSConfig' has not been declared
> DNS.cc:134:5: error: 'SplitDNSConfig' has not been declared
> DNS.cc: In member function 'void DNSEntry::init(const char*, int, int,
> Continuation*, DNSHandler*, int)':
> DNS.cc:261:19: error: 'INK_NOWARN' was not declared in this scope
> make: *** [DNS.o] Error 1
> {noformat}
> This is due to missing dependencies in Makefile.am: Even though we include
> "P_DNS.h", which includes "libts.h", which in turn includes "ink_config.h"
> the compiler doesn't seem to be able to resolve "SPLIT_DNS".
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-81) Have one single place to store and lookup remap rules irrespective of type
[ https://issues.apache.org/jira/browse/TS-81?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-81: Fix Version/s: (was: 3.1.2) 3.2.0 > Have one single place to store and lookup remap rules irrespective of type > -- > > Key: TS-81 > URL: https://issues.apache.org/jira/browse/TS-81 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Affects Versions: 2.0.0a >Reporter: Manjesh Nilange >Priority: Minor > Fix For: 3.2.0 > > > Currently, remap rules are stored in different structures and looked up > separately based on type (forward, reverse, etc.). It'd be better design and > more maintainable to process (store, search) all rules in one structure and > then use type to determine action. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-754) Reduce memory usage on idle connections
[ https://issues.apache.org/jira/browse/TS-754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-754: - Fix Version/s: (was: 3.1.2) 3.2.0 > Reduce memory usage on idle connections > --- > > Key: TS-754 > URL: https://issues.apache.org/jira/browse/TS-754 > Project: Traffic Server > Issue Type: Improvement >Reporter: Leif Hedstrom > Fix For: 3.2.0 > > > We should examine what memory (if any) can be returned to class allocators / > freelist when a connection is idle (in keep-alive). Right now, I suspect we > hold on to more memory than is necessary, which limits the number of KA > connections a server can have. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-152) Cleanup Diags
[ https://issues.apache.org/jira/browse/TS-152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-152: - Fix Version/s: (was: 3.1.2) 3.2.0 > Cleanup Diags > - > > Key: TS-152 > URL: https://issues.apache.org/jira/browse/TS-152 > Project: Traffic Server > Issue Type: Improvement > Components: Cleanup >Reporter: John Plevyak >Priority: Minor > Fix For: 3.2.0 > > > The use of Diags functions and tags is inconsistent and they are often > wrapped with > incompatible macros in each module. > Following the discussion in https://issues.apache.org/jira/browse/TS-130 I > propose that we: > 1. use Diags() for diagnostic messages to appear from all builds > 2. use Debug() for diagnostic messages to appear from only DEBUG builds, > replacing this with myriad of competing macros for this behavior in > different moduels > 3. organize the existing tags hierarchically and document then (at least) in > the master P_.h file for > each module. > 4. rename the -T argument form --debug_tags to --diag_tags > 5. remove #define of IOCORE_MacheFatal to fprintf in P_EventSystem.h (what > the heck is that?) >and other wrappers for these functions and standardize them > 6. remove unused and competing ink_error.h/cc functions ink_fatal ink_dprintf > etc. > and convert to the Fatal/Diags versions. >These are all vestiges of when ink_xxx.h were C headers and InkFoo.h were > C++ > headers. Which accounts for the redundancy. > Because "." is special in regex we could use: > cache_write_open > cache_write_ready > etc. > so we could use -T"cache*" or -T"cache_write*" to capture different levels of > events. > Ideas welcome. > john -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-72) Records config review for update type behavior
[ https://issues.apache.org/jira/browse/TS-72?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-72: Fix Version/s: (was: 3.1.2) 3.2.0 > Records config review for update type behavior > -- > > Key: TS-72 > URL: https://issues.apache.org/jira/browse/TS-72 > Project: Traffic Server > Issue Type: Bug > Components: Cleanup >Affects Versions: 2.0.0a > Environment: All >Reporter: George Paul >Priority: Minor > Fix For: 3.2.0 > > > The Records configuration variables need to be reviewed for proper intended > update type behavior. > The update types can be the following: > RU_NULL, // default: don't know the behavior > RU_REREAD,// config can be updated dynamically w/ > traffic_line -x > RU_RESTART_TS,// config requires TS to be restarted to take effect > RU_RESTART_TM, // config requires TM/TS to be restarted to take effect > RU_RESTART_TC // config requires TC/TM/TS to be restarted to take > effect > This will require review of the overall system and component configs. > Possibly split this ticket into seperate tickets targeted to the various > components. > -George -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-287) transaction_active_timeout_in does not trigger on the first request of a Keep-Alive connection
[ https://issues.apache.org/jira/browse/TS-287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-287: - Fix Version/s: (was: 3.1.2) 3.2.0 > transaction_active_timeout_in does not trigger on the first request of a > Keep-Alive connection > -- > > Key: TS-287 > URL: https://issues.apache.org/jira/browse/TS-287 > Project: Traffic Server > Issue Type: Bug > Components: Core >Reporter: Steve Jiang > Fix For: 3.2.0 > > Attachments: slowclient.pl > > > proxy.config.http.transaction_active_timeout_in does not trigger on a slow > request on if the request is the first on a new client connection, because > the timeout event is cancelled before it can be triggered. > Subsequent requests with keep-alive on the same connection will correctly > trigger the active_timeout_in. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-380) Remaining 64-bit "conversion"
[ https://issues.apache.org/jira/browse/TS-380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-380: - Fix Version/s: (was: 3.1.2) 3.2.0 > Remaining 64-bit "conversion" > - > > Key: TS-380 > URL: https://issues.apache.org/jira/browse/TS-380 > Project: Traffic Server > Issue Type: Bug > Components: Core >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom >Priority: Critical > Fix For: 3.2.0 > > > There are a few areas which still needs to some 'lovin for true 64-bit > support. In particular, I know of an area in logging, related to log > filtering, that needs to be modified. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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: 3.1.1) 3.1.2 Moving out to 3.1.2 > 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 >Assignee: mohan_zl > Fix For: 3.1.2 > > Attachments: HCUtil.cc, hc.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. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-824) Range requests that result in cache refresh give 200 status response with full contents
[ https://issues.apache.org/jira/browse/TS-824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-824: - Attachment: TS-824.diff Here's something that solves at least some of the problem... Feedback and comments appreciated. > Range requests that result in cache refresh give 200 status response with > full contents > --- > > Key: TS-824 > URL: https://issues.apache.org/jira/browse/TS-824 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Affects Versions: 2.1.9, 2.1.8, 2.1.7, 2.1.6, 2.1.5, 2.1.4 >Reporter: William Bardwell >Priority: Minor > Fix For: 3.1.1 > > Attachments: TS-824.diff > > > If you send a request with a Range: header to TS when it has full cached > contents that need to be refreshed, and they get back a status 304 response > indicating that the cached contents are up to date, TS will respond to the > client with a status 200 response, and the full contents. So the content is > served from cache, but do not go through the transform to only return partial > bytes and a status 206 response like it should. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-824) Range requests that result in cache refresh give 200 status response with full contents
[ https://issues.apache.org/jira/browse/TS-824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-824: - Attachment: TS-824-2.diff Updated diff. > Range requests that result in cache refresh give 200 status response with > full contents > --- > > Key: TS-824 > URL: https://issues.apache.org/jira/browse/TS-824 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Affects Versions: 2.1.9, 2.1.8, 2.1.7, 2.1.6, 2.1.5, 2.1.4 >Reporter: William Bardwell >Priority: Minor > Fix For: 3.1.1 > > Attachments: TS-824-2.diff, TS-824.diff > > > If you send a request with a Range: header to TS when it has full cached > contents that need to be refreshed, and they get back a status 304 response > indicating that the cached contents are up to date, TS will respond to the > client with a status 200 response, and the full contents. So the content is > served from cache, but do not go through the transform to only return partial > bytes and a status 206 response like it should. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-824) Range requests that result in cache refresh give 200 status response with full contents
[ https://issues.apache.org/jira/browse/TS-824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-824: - Attachment: (was: TS-824.diff) > Range requests that result in cache refresh give 200 status response with > full contents > --- > > Key: TS-824 > URL: https://issues.apache.org/jira/browse/TS-824 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Affects Versions: 2.1.9, 2.1.8, 2.1.7, 2.1.6, 2.1.5, 2.1.4 >Reporter: William Bardwell >Priority: Minor > Fix For: 3.1.1 > > Attachments: TS-824-2.diff > > > If you send a request with a Range: header to TS when it has full cached > contents that need to be refreshed, and they get back a status 304 response > indicating that the cached contents are up to date, TS will respond to the > client with a status 200 response, and the full contents. So the content is > served from cache, but do not go through the transform to only return partial > bytes and a status 206 response like it should. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-829) socks stats cleanup - some stats are registered, but not used
[ https://issues.apache.org/jira/browse/TS-829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-829: - Fix Version/s: (was: 3.1.1) 3.1.2 > socks stats cleanup - some stats are registered, but not used > - > > Key: TS-829 > URL: https://issues.apache.org/jira/browse/TS-829 > Project: Traffic Server > Issue Type: Bug > Components: Network >Affects Versions: 3.0.0 >Reporter: Bryan Call >Priority: Minor > Fix For: 3.1.2 > > > From reviewing TS-818 I noticed that the stats that were being double > resisted are not used. Some cleanup work should be done for the socks stats. > Stats that are registered, but not used in the code: > [bcall@snowball traffic.git]$ grep -r proxy.process.socks iocore/net/Net.cc > "proxy.process.socks.connections_successful", > "proxy.process.socks.connections_unsuccessful", > "proxy.process.socks.connections_currently_open", > These stats are used some tests, so maybe they should be added back into the > code. > [bcall@snowball traffic.git]$ grep -rl --binary-files=without-match > proxy.process.socks.connections_ * > iocore/net/Net.cc > mgmt/api/remote/APITestCliRemote.cc > test/plugin/test-mgmt/test-mgmt.c > I did however see these stats being used: > [bcall@snowball traffic.git]$ grep -r SOCKSPROXY_ * > proxy/SocksProxy.cc:#define SOCKSPROXY_INC_STAT(x) \ > proxy/SocksProxy.cc: > SOCKSPROXY_INC_STAT(socksproxy_http_connections_stat); > proxy/SocksProxy.cc: > SOCKSPROXY_INC_STAT(socksproxy_tunneled_connections_stat); -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-975) server-transform.c broken
[ https://issues.apache.org/jira/browse/TS-975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-975: - Fix Version/s: (was: 3.1.2) 3.1.3 I'm moving all 3.1.2 bugs out to 3.1.3, and we can move some 3.1.1 bugs out to 3.1.2, to get some release action going. > server-transform.c broken > - > > Key: TS-975 > URL: https://issues.apache.org/jira/browse/TS-975 > Project: Traffic Server > Issue Type: Bug > Components: Plugins >Affects Versions: 3.1.0 >Reporter: Otto van der Schaaf >Assignee: Igor Galić >Priority: Minor > Fix For: 3.1.3 > > Attachments: server-transform.c.diff > > > While playing around with the server-transform plugin example, i noticed it > was broken. After some meddling around, i got it working again. > The changes are mainly that in some cases content-length was passed in > network-byte order where it shouldn't be. > Another fix was handling the TS_EVENT_IMMEDIATE event > in transform_write_event(). i currently perform > a TSVIOReenable(data->server_vio); on that event, and it seems to work. > However, I'm not sure at all if that is the correct thing to do, so if > anybody could help me out on that? :-). > I have tested the changed code with a custom echo server, and confirmed that > the plugin is actually sending and receiving to the echo server. > I added the working code. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-959) ae filtering code need to get clean & clever
[ https://issues.apache.org/jira/browse/TS-959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-959: - Fix Version/s: (was: 3.1.2) 3.1.3 I'm moving all 3.1.2 bugs out to 3.1.3, and we can move some 3.1.1 bugs out to 3.1.2, to get some release action going. > ae filtering code need to get clean & clever > > > Key: TS-959 > URL: https://issues.apache.org/jira/browse/TS-959 > Project: Traffic Server > Issue Type: Improvement > Components: Configuration, HTTP >Affects Versions: 3.1.1 >Reporter: Zhao Yongming >Assignee: Zhao Yongming >Priority: Minor > Fix For: 3.1.3 > > > I think the codes for aeua filter is ugly placed into httpconfig & main.cc, > and can not get live updated with traffic_line, that is not acceptable for > our config system. the codes need to be move out into one dedicate file or at > least get cleanup, and setup the callbacks for config file changes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-378) FIx the strict-aliasing rules warnings
[
https://issues.apache.org/jira/browse/TS-378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-378:
-
Fix Version/s: (was: 3.1.2)
3.1.3
I'm moving all 3.1.2 bugs out to 3.1.3, and we can move some 3.1.1 bugs out to
3.1.2, to get some release action going.
> FIx the strict-aliasing rules warnings
> --
>
> Key: TS-378
> URL: https://issues.apache.org/jira/browse/TS-378
> Project: Traffic Server
> Issue Type: Improvement
> Components: Cleanup
>Affects Versions: 2.1.6
>Reporter: Mladen Turk
>Assignee: Mladen Turk
>Priority: Minor
> Fix For: 3.1.3
>
>
> Currently the compile fails with -fstrict-aliasing.
> The reason is mostly using int pointers to read or write 64 bit numbers
> Eg. INK_MD5.cc has
> struct INK_MD5
> {
> uint64 b[2];
> uint32 word(int i)
> {
> uint32 *p = (uint32 *) & b[0];
> return p[i];
> }
> ...
> };
> Such things can be easily fixed and properly handled using unions
> (they are invented for that)
> struct INK_MD5
> {
> union {
> uint64 q[2];
> uint32 u[4];
> unsigned char b[16];
> } s;
> uint32 word(int i)
> {
> return s.w[i];
> }
> ...
> };
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-61) multiple do_io_pread on a CacheVConnection
[ https://issues.apache.org/jira/browse/TS-61?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-61: Fix Version/s: (was: 3.1.2) 3.1.3 I'm moving all 3.1.2 bugs out to 3.1.3, and we can move some 3.1.1 bugs out to 3.1.2, to get some release action going. > multiple do_io_pread on a CacheVConnection > -- > > Key: TS-61 > URL: https://issues.apache.org/jira/browse/TS-61 > Project: Traffic Server > Issue Type: Improvement > Components: Cache >Reporter: John Plevyak >Assignee: John Plevyak > Fix For: 3.1.3 > > Attachments: pread-2.patch > > Original Estimate: 48h > Remaining Estimate: 48h > > The current TS-46 patch includes do_io_pread support but allows only a single > do_io_pread. > In order to efficiently support range requests with multiple ranges it would > be helpful to be able > to do multiple do_io_pread's on a single open CacheVConnection. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-803) Fix SOCKS breakage and allow for setting next-hop SOCKS
[
https://issues.apache.org/jira/browse/TS-803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-803:
-
Fix Version/s: (was: 3.1.2)
3.1.3
I'm moving all 3.1.2 bugs out to 3.1.3, and we can move some 3.1.1 bugs out to
3.1.2, to get some release action going.
> Fix SOCKS breakage and allow for setting next-hop SOCKS
> ---
>
> Key: TS-803
> URL: https://issues.apache.org/jira/browse/TS-803
> Project: Traffic Server
> Issue Type: New Feature
> Components: Network
> Environment: Wherever ATS might run
>Reporter: M. Nunberg
> Fix For: 3.1.3
>
>
> Here is a patch I drew up a few months ago against a snapshot of ATS/2.1.7
> unstable/git. There are some quirks here, and I'm not that sure any more what
> this patch does exactly. However it:
> 1) Does fix SOCKS connections in general
> 2) Allows setting next-hop SOCKS proxy via the API
> Problems:
> See https://issues.apache.org/jira/browse/TS-802
> This has no effect on connections which are drawn from the connection pool,
> as it seems ATS currently doesn't maintain unique identities for peripheral
> connection params (source IP, SOCKS etc); i.e. this only affects new TCP
> connections to an OS.
> diff -x '*.o' -ru tsorig/iocore/net/I_NetVConnection.h
> tsgit217/iocore/net/I_NetVConnection.h
> --- tsorig/iocore/net/I_NetVConnection.h2011-03-09 21:43:58.0
> +
> +++ tsgit217/iocore/net/I_NetVConnection.h2011-03-17 14:37:18.0
> +
> @@ -120,6 +120,13 @@
>/// Version of SOCKS to use.
>unsigned char socks_version;
> + struct {
> + unsigned int ip;
> + int port;
> + char *username;
> + char *password;
> + } socks_override;
> +
>int socket_recv_bufsize;
>int socket_send_bufsize;
> Only in tsgit217/iocore/net: Makefile
> Only in tsgit217/iocore/net: Makefile.in
> diff -x '*.o' -ru tsorig/iocore/net/P_Socks.h tsgit217/iocore/net/P_Socks.h
> --- tsorig/iocore/net/P_Socks.h2011-03-09 21:43:58.0 +
> +++ tsgit217/iocore/net/P_Socks.h2011-03-17 13:17:20.0 +
> @@ -126,7 +126,7 @@
>unsigned char version;
>bool write_done;
> -
> + bool manual_parent_selection;
>SocksAuthHandler auth_handler;
>unsigned char socks_cmd;
> @@ -145,7 +145,8 @@
> SocksEntry():Continuation(NULL), netVConnection(0),
> ip(0), port(0), server_ip(0), server_port(0), nattempts(0),
> -lerrno(0), timeout(0), version(5), write_done(false),
> auth_handler(NULL), socks_cmd(NORMAL_SOCKS)
> +lerrno(0), timeout(0), version(5), write_done(false),
> manual_parent_selection(false),
> +auth_handler(NULL), socks_cmd(NORMAL_SOCKS)
>{
>}
> };
> diff -x '*.o' -ru tsorig/iocore/net/Socks.cc tsgit217/iocore/net/Socks.cc
> --- tsorig/iocore/net/Socks.cc2011-03-09 21:43:58.0 +
> +++ tsgit217/iocore/net/Socks.cc2011-03-17 13:46:07.0 +
> @@ -73,7 +73,8 @@
>nattempts = 0;
>findServer();
> - timeout = this_ethread()->schedule_in(this,
> HRTIME_SECONDS(netProcessor.socks_conf_stuff->server_connect_timeout));
> +// timeout = this_ethread()->schedule_in(this,
> HRTIME_SECONDS(netProcessor.socks_conf_stuff->server_connect_timeout));
> + timeout = this_ethread()->schedule_in(this, HRTIME_SECONDS(5));
>write_done = false;
> }
> @@ -81,6 +82,15 @@
> SocksEntry::findServer()
> {
>nattempts++;
> + if(manual_parent_selection) {
> + if(nattempts > 1) {
> + //Nullify IP and PORT
> + server_ip = -1;
> + server_port = 0;
> + }
> + Debug("mndebug(Socks)", "findServer() is a noop with manual socks
> selection");
> + return;
> + }
> #ifdef SOCKS_WITH_TS
>if (nattempts == 1) {
> @@ -187,7 +197,6 @@
> }
> Debug("Socks", "Failed to connect to %u.%u.%u.%u:%d",
> PRINT_IP(server_ip), server_port);
> -
> findServer();
> if (server_ip == (uint32_t) - 1) {
> diff -x '*.o' -ru tsorig/iocore/net/UnixNetProcessor.cc
> tsgit217/iocore/net/UnixNetProcessor.cc
> --- tsorig/iocore/net/UnixNetProcessor.cc2011-03-09 21:43:58.0
> +
> +++ tsgit217/iocore/net/UnixNetProcessor.cc2011-03-17 15:48:38.0
> +
> @@ -228,6 +228,11 @@
>!socks_conf_stuff->ip_range.match(ip))
> #endif
> );
> + if(opt->socks_override.ip >= 1) {
> + using_socks = true;
> + Debug("mndebug", "trying to set using_socks to true");
> + }
> +
>SocksEntry *socksEntry = NULL;
> #endif
>NET_SUM_GLOBAL_DYN_STAT(net_connections_currently_open_stat, 1);
> @@ -242,6 +247,16 @@
>if (using_socks) {
> Debug("Socks", "Using Socks ip: %u.%u.%u.%u:%d\n", PRINT_IP(ip), port);
> socksEntry = socksAllocator.alloc();
> +
> +if (opt->socks_override.ip) {
> +
[jira] [Updated] (TS-898) fix potential problems from coverity scan
[ https://issues.apache.org/jira/browse/TS-898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-898: - Fix Version/s: (was: 3.1.2) 3.1.3 I'm moving all 3.1.2 bugs out to 3.1.3, and we can move some 3.1.1 bugs out to 3.1.2, to get some release action going. > fix potential problems from coverity scan > - > > Key: TS-898 > URL: https://issues.apache.org/jira/browse/TS-898 > Project: Traffic Server > Issue Type: Improvement > Environment: RHEL5 >Reporter: Bryan Call >Assignee: Bryan Call > Fix For: 3.1.3 > > > Ran Coverity over the code and it reported 856 potential problems with the > code. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-254) Add TSEscapifyString() and TSUnescapifyString()
[
https://issues.apache.org/jira/browse/TS-254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-254:
-
Fix Version/s: (was: 3.1.2)
3.1.3
I'm moving all 3.1.2 bugs out to 3.1.3, and we can move some 3.1.1 bugs out to
3.1.2, to get some release action going.
> Add TSEscapifyString() and TSUnescapifyString()
>
>
> Key: TS-254
> URL: https://issues.apache.org/jira/browse/TS-254
> Project: Traffic Server
> Issue Type: New Feature
> Components: TS API
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
>Priority: Minor
> Fix For: 3.1.3
>
>
> It would be very convenient for plugin developers to have SDK APIs that
> allows for escaping and unescaping of strings. E.g.
> TSEscapifyString("http://www.ogre.com/ogre.png";)
> -> http%3A%2F%2Fwww.ogre.com%2Fogre.png
> TSUnescapifyString("http%3A%2F%2Fwww.ogre.com%2Fogre.png)
> -> http://www.ogre.com/ogre.png
> The "unescapify" string is fairly straight forward, but the "escapify"
> version might benefit from taking an (optional) table which describes what
> characters needs to be escaped (e.g. in in some cases you want a / to be
> escaped, but in others you do not).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-858) traffic_server segmentation_fault when cache storage value is below 65M
[
https://issues.apache.org/jira/browse/TS-858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-858:
-
Fix Version/s: (was: 3.1.2)
3.1.3
I'm moving all 3.1.2 bugs out to 3.1.3, and we can move some 3.1.1 bugs out to
3.1.2, to get some release action going.
> traffic_server segmentation_fault when cache storage value is below 65M
> ---
>
> Key: TS-858
> URL: https://issues.apache.org/jira/browse/TS-858
> Project: Traffic Server
> Issue Type: Bug
> Components: Cache
>Affects Versions: 3.0.0
> Environment: Fedora 14
>Reporter: Kevin Giles
>Priority: Minor
> Fix For: 3.1.3
>
>
> specify the storage as var/trafficserver 64M in the storage.conf,
> traffic_server will core dump upon launch, the following is the stack trace:
> {noformat}
> FATAL: Cache.cc:2293: failed assert `dpb && dpb->len == (uint64_t)b`
> traffic_server - STACK TRACE:
> traffic_server(ink_fatal_va+0x8e)[0x82ef221]
> traffic_server(ink_fatal+0x1e)[0x82ef252]
> traffic_server(_ink_assert+0x90)[0x82eeb6c]
> traffic_server(cplist_reconfigure()+0x2fd)[0x8283054]
> traffic_server(CacheProcessor::diskInitialized()+0x19b)[0x827b7d1]
> traffic_server(CacheDisk::openDone(int, void*)+0x40)[0x8291142]
> traffic_server(CacheDisk::clearDone(int, void*)+0xcc)[0x8290eb2]
> traffic_server(Continuation::handleEvent(int, void*)+0x47)[0x810d871]
> traffic_server(AIOCallbackInternal::io_complete(int, void*)+0x2c)[0x82862c8]
> traffic_server(Continuation::handleEvent(int, void*)+0x47)[0x810d871]
> traffic_server(EThread::process_event(Event*, int)+0x10e)[0x82e83f2]
> traffic_server(EThread::execute()+0xa6)[0x82e862a]
> traffic_server[0x82e74b1]
> /lib/libpthread.so.0[0x658e99]
> /lib/libc.so.6(clone+0x5e)[0x59ed2e]
> {noformat}
> It will core dump everytime, if the cache size is set to 65M, traffic_server
> will launch fine.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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: 3.1.2) 3.1.3 I'm moving all 3.1.2 bugs out to 3.1.3, and we can move some 3.1.1 bugs out to 3.1.2, to get some release action going. > 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 >Assignee: mohan_zl > Fix For: 3.1.3 > > Attachments: HCUtil.cc, hc.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. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-817) TSFetchUrl/TSFetchPages does not work with HTTP/1.1 requests
[ https://issues.apache.org/jira/browse/TS-817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-817: - Fix Version/s: (was: 3.1.2) 3.1.3 I'm moving all 3.1.2 bugs out to 3.1.3, and we can move some 3.1.1 bugs out to 3.1.2, to get some release action going. > TSFetchUrl/TSFetchPages does not work with HTTP/1.1 requests > > > Key: TS-817 > URL: https://issues.apache.org/jira/browse/TS-817 > Project: Traffic Server > Issue Type: Bug > Components: TS API >Affects Versions: 2.1.9, 2.1.8 >Reporter: Naveen > Labels: api-change, function > Fix For: 3.1.3 > > > The API calls TSFetchUrl/TSFetchPages do not work with HTTP/1.1 requests. The > implementation seems to use the "end of the connection" to signal the user > callback function, which is not the case on persistent connections. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-17) Expose atomic abstractions via InkAPI
[ https://issues.apache.org/jira/browse/TS-17?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-17: Fix Version/s: (was: 3.1.2) 3.1.3 I'm moving all 3.1.2 bugs out to 3.1.3, and we can move some 3.1.1 bugs out to 3.1.2, to get some release action going. > Expose atomic abstractions via InkAPI > - > > Key: TS-17 > URL: https://issues.apache.org/jira/browse/TS-17 > Project: Traffic Server > Issue Type: Improvement > Components: TS API >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom >Priority: Minor > Fix For: 3.1.3 > > > With the changes being made to the atomic abstractions, we should take this > opportunity to expose atomic APIs via InkAPI (InkAPI.h). Breaking API or > binarby ABIs is not a problem. Doing this, will make it easier to use atomic > instructions in plugins, and keep the plugins "cross platform". -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-214) On Solaris, use port_send to signal async events to a waiting thread (e.g. like eventfd/pipe)
[ https://issues.apache.org/jira/browse/TS-214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-214: - Fix Version/s: (was: 3.1.2) 3.1.3 I'm moving all 3.1.2 bugs out to 3.1.3, and we can move some 3.1.1 bugs out to 3.1.2, to get some release action going. > On Solaris, use port_send to signal async events to a waiting thread (e.g. > like eventfd/pipe) > - > > Key: TS-214 > URL: https://issues.apache.org/jira/browse/TS-214 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Affects Versions: 2.1.0 > Environment: OpenSolaris >Reporter: John Plevyak >Assignee: Theo Schlossnagle > Fix For: 3.1.3 > > > We should use port_send to signal async events to a waiting thread (e.g. like > eventfd/pipe). > http://developers.sun.com/solaris/articles/event_completion.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-879) Seek on cached file
[ https://issues.apache.org/jira/browse/TS-879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-879: - Fix Version/s: (was: 3.1.2) 3.1.3 I'm moving all 3.1.2 bugs out to 3.1.3, and we can move some 3.1.1 bugs out to 3.1.2, to get some release action going. > Seek on cached file > --- > > Key: TS-879 > URL: https://issues.apache.org/jira/browse/TS-879 > Project: Traffic Server > Issue Type: Bug > Components: Cache, TS API >Affects Versions: 3.0.0 >Reporter: Nelson Pérez > Labels: api-addition, cache, trafficserver > Fix For: 3.1.3 > > > I want a custom written plugin to be able to seek to any point in a cached > file. According to John Plevyak > (http://www.mail-archive.com/dev@trafficserver.apache.org/msg02785.html) this > feature is new in the cache, but not yet available to the API. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-866) Need way to clear contents of a cache entry
[ https://issues.apache.org/jira/browse/TS-866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-866: - Fix Version/s: (was: 3.1.2) 3.1.3 I'm moving all 3.1.2 bugs out to 3.1.3, and we can move some 3.1.1 bugs out to 3.1.2, to get some release action going. > Need way to clear contents of a cache entry > --- > > Key: TS-866 > URL: https://issues.apache.org/jira/browse/TS-866 > Project: Traffic Server > Issue Type: New Feature > Components: Cache >Affects Versions: 3.0.0 >Reporter: William Bardwell >Priority: Minor > Fix For: 3.1.3 > > Attachments: cache_erase.diff > > > I needed a way to clear a cache entry off of disk, not just forget about it. > The worry was about if you got content on a server that was illegal or a > privacy violation of some sort, we wanted a way to be able to tell customers > that after this step there was no way that TS could serve the content again. > The normal cache remove just clears the directory entry, but theoretically a > bug could allow that data out in some way. This was not intended to prevent > forensic analysis of the hardware being able to recover the data. And bugs > in low level drivers or the kernel could theoretically allow data to survive > due to block remapping or mis-management of disk caches. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-612) ATS does not allow password protected certificates
[
https://issues.apache.org/jira/browse/TS-612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-612:
-
Fix Version/s: (was: 3.1.2)
3.1.3
I'm moving all 3.1.2 bugs out to 3.1.3, and we can move some 3.1.1 bugs out to
3.1.2, to get some release action going.
> ATS does not allow password protected certificates
> --
>
> Key: TS-612
> URL: https://issues.apache.org/jira/browse/TS-612
> Project: Traffic Server
> Issue Type: Improvement
> Components: SSL
>Affects Versions: 2.1.4
> Environment: Any
>Reporter: Igor Galić
> Fix For: 3.1.3
>
>
> Create a (self-signed) certificate with a password that is non-empty. {cat
> server.key server.crt > server.pem} and configure it as
> {CONFIG proxy.config.ssl.server.cert.filename STRING server.pem}
> The result will be:
> {noformat}
> Jan 3 10:50:16 proveedores traffic_server[2579]: NOTE: --- Server Starting
> ---
> Jan 3 10:50:16 proveedores traffic_server[2579]: NOTE: Server Version:
> Apache Traffic Server - traffic_server - 2.0.1 - (build # 113112 on Dec 31
> 2010 at 12:58:34)
> Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} STATUS: opened
> var/log/trafficserver/diags.log
> Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} NOTE: updated
> diags config
> Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} NOTE: cache
> clustering disabled
> Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} WARNING: no
> cache disks specified in etc/trafficserver/storage.config: cache disabled
> Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} NOTE: cache
> clustering disabled
> Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} WARNING:
> unable to open cache disk(s): Cache Disabled
> Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} ERROR: SSL
> ERROR: Cannot use server private key file.
> Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} ERROR:
> SSL::0:error:0906406D:PEM routines:PEM_def_callback:problems getting
> password:pem_lib.c:105:
> Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} ERROR:
> SSL::0:error:0906A068:PEM routines:PEM_do_header:bad password
> read:pem_lib.c:406:
> Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} ERROR:
> SSL::0:error:140B0009:SSL routines:SSL_CTX_use_PrivateKey_file:PEM
> lib:ssl_rsa.c:669:
> Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} ERROR: SSL
> ERROR: Can't initialize the SSL library, disabling SSL termination!.
> Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} NOTE: logging
> initialized[7], logging_mode = 3
> Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} NOTE: traffic
> server running
> {noformat}
> A first -- ugly -- shot would be to at least have a password field in the
> configuration.
> In the end something taking the input of an external program or from a file
> would be more desirable.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-340) EC2 Updates/Testing/Building
[ https://issues.apache.org/jira/browse/TS-340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-340: - Fix Version/s: (was: 3.1.2) 3.1.3 I'm moving all 3.1.2 bugs out to 3.1.3, and we can move some 3.1.1 bugs out to 3.1.2, to get some release action going. > EC2 Updates/Testing/Building > > > Key: TS-340 > URL: https://issues.apache.org/jira/browse/TS-340 > Project: Traffic Server > Issue Type: Bug > Components: Build, Portability >Affects Versions: 2.0.0a > Environment: EC2 >Reporter: Jason Giedymin >Assignee: Jason Giedymin >Priority: Minor > Labels: AMI, EC2, Fedora, Ubuntu > Fix For: 3.1.3 > > > 1.) More Lucid Testing > 2.) Rebuild with latest ATS Release > 3.) Seed to West, EU, Asia datacenters (20 Images in total, > Fedora/Ubuntu9/Ubuntu10/32/64) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-837) ATS fails to compile with gcc 4.6.1 with --enable-debug
[
https://issues.apache.org/jira/browse/TS-837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-837:
-
Fix Version/s: (was: 3.1.2)
3.1.3
I'm moving all 3.1.2 bugs out to 3.1.3, and we can move some 3.1.1 bugs out to
3.1.2, to get some release action going.
> ATS fails to compile with gcc 4.6.1 with --enable-debug
> ---
>
> Key: TS-837
> URL: https://issues.apache.org/jira/browse/TS-837
> Project: Traffic Server
> Issue Type: Bug
>Affects Versions: 3.1.0, 3.0.0
> Environment: Linux, Debian, Amd64 + GCC 4.6.1
>Reporter: Igor Galić
>Assignee: Igor Galić
> Fix For: 3.1.3
>
> Attachments: proxything.diff
>
>
> {noformat}
> In file included from ../../proxy/ControlMatcher.h:104:0,
> from ../../proxy/ParentSelection.h:37,
> from P_Socks.h:30,
> from P_Net.h:106,
> from Connection.cc:34:
> ../../proxy/hdrs/HTTP.h: In member function 'INK_MD5
> HTTPInfo::object_key_get()':
> ../../proxy/hdrs/HTTP.h:1375:24: error: dereferencing type-punned pointer
> will break strict-aliasing rules [-Werror=strict-aliasing]
> ../../proxy/hdrs/HTTP.h: In member function 'int64_t
> HTTPInfo::object_size_get()':
> ../../proxy/hdrs/HTTP.h:1405:24: error: dereferencing type-punned pointer
> will break strict-aliasing rules [-Werror=strict-aliasing]
> ../../proxy/hdrs/HTTP.h: In member function 'void
> HTTPInfo::object_size_set(int64_t)':
> ../../proxy/hdrs/HTTP.h:1422:51: error: dereferencing type-punned pointer
> will break strict-aliasing rules [-Werror=strict-aliasing]
> cc1plus: all warnings being treated as errors
> *** [Connection.o] Error 1
> make[2]: Leaving directory `/netsrc/trafficserver-3.0.0/iocore/net'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/netsrc/trafficserver-3.0.0/iocore'
> make: *** [all-recursive] Error 1
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-60) support writing large buffers via zero-copy
[ https://issues.apache.org/jira/browse/TS-60?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-60: Fix Version/s: (was: 3.1.2) 3.1.3 I'm moving all 3.1.2 bugs out to 3.1.3, and we can move some 3.1.1 bugs out to 3.1.2, to get some release action going. > support writing large buffers via zero-copy > --- > > Key: TS-60 > URL: https://issues.apache.org/jira/browse/TS-60 > Project: Traffic Server > Issue Type: Improvement > Components: Cache > Environment: all >Reporter: John Plevyak >Assignee: John Plevyak > Fix For: 3.1.3 > > Original Estimate: 48h > Remaining Estimate: 48h > > Currently all write data is written from the aggregation buffer. In order to > support large buffer writes efficiently > it would be nice to be able to write directly from page aligned memory. This > would be bother more efficient and > would help support large objects. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-893) the prefetch function in codes need more love to show up
[ https://issues.apache.org/jira/browse/TS-893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-893: - Fix Version/s: (was: 3.1.2) 3.1.3 I'm moving all 3.1.2 bugs out to 3.1.3, and we can move some 3.1.1 bugs out to 3.1.2, to get some release action going. > the prefetch function in codes need more love to show up > > > Key: TS-893 > URL: https://issues.apache.org/jira/browse/TS-893 > Project: Traffic Server > Issue Type: Improvement >Reporter: Zhao Yongming >Assignee: Zhao Yongming > Fix For: 3.1.3 > > > the prefetch function in proxy is a good solution when you really need to > faster up your user download time, it can parse any allowed plean html file, > get all resource tags out and do batch loading from OS. I am going to preload > my site before we put it online, as it will get about 1 month to get the disk > full and hit rate stable. it is a cool feature but it have the following > issues: > 1, the prefetch config file is not managed well. ie, it is not managed by > cluster > 2, the it does not any document in the admin guide or old pdf file. > 3, prefetching just care plean html file, without compressing, should we do > some decompressing? is that possible? > hopes this is the starting of make prefetch really useful for some cutting > edge situation. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-939) enhance DNS round robin functionality in ATS
[ https://issues.apache.org/jira/browse/TS-939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-939: - Fix Version/s: (was: 3.1.2) 3.1.3 I'm moving all 3.1.2 bugs out to 3.1.3, and we can move some 3.1.1 bugs out to 3.1.2, to get some release action going. > enhance DNS round robin functionality in ATS > > > Key: TS-939 > URL: https://issues.apache.org/jira/browse/TS-939 > Project: Traffic Server > Issue Type: New Feature > Components: DNS >Reporter: vijaya bhaskar mamidi >Priority: Minor > Fix For: 3.1.3 > > > right now proxy.config.dns.round_robin_nameservers can only have two values > # Enables (1) or disables (0) DNS server round-robin. > CONFIG proxy.config.dns.round_robin_nameservers INT 1 > > enhance the above feature to have a third value (2). If the value is set to > 2, it should do round robin and if ATS fails to connect to one of the IP > tries to connect to other one if all the IPs are tried return a error to > Client. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-976) gzip.c plugin - working again + browser compatibility improvement
[ https://issues.apache.org/jira/browse/TS-976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-976: - Fix Version/s: (was: 3.1.2) 3.1.3 I'm moving all 3.1.2 bugs out to 3.1.3, and we can move some 3.1.1 bugs out to 3.1.2, to get some release action going. > gzip.c plugin - working again + browser compatibility improvement > --- > > Key: TS-976 > URL: https://issues.apache.org/jira/browse/TS-976 > Project: Traffic Server > Issue Type: Bug > Components: Plugins >Affects Versions: 3.1.0 >Reporter: Otto van der Schaaf >Assignee: Igor Galić > Fix For: 3.1.3 > > Attachments: gzip.diff > > > I did some work on the gzip.c example plugin: > -made it working again (current code failes on asserts from > TSMimeHdrFieldValueStringGet), > -made it compress using the same deflateinit2 call as mod_gzip, for better > browser compatibility (ie issues). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-32) Fix ICP
[ https://issues.apache.org/jira/browse/TS-32?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-32: Fix Version/s: (was: 3.1.2) 3.1.3 I'm moving all 3.1.2 bugs out to 3.1.3, and we can move some 3.1.1 bugs out to 3.1.2, to get some release action going. > Fix ICP > --- > > Key: TS-32 > URL: https://issues.apache.org/jira/browse/TS-32 > Project: Traffic Server > Issue Type: Bug > Components: Core >Reporter: Miles Libbey > Fix For: 3.1.3 > > > http://icp.ircache.net/ > The ICP implementation in Traffic Server broke when epoll() was introduced. > Its still an interesting and used feature in caches: > - when a caching layer of several boxes are used ICP helps to reduce > disparities when a client is not routed to the same cache on subsequent > requests > - after a restart, it can help reduce the time spent in a cold cache situation -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-829) socks stats cleanup - some stats are registered, but not used
[ https://issues.apache.org/jira/browse/TS-829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-829: - Fix Version/s: (was: 3.1.2) 3.1.3 I'm moving all 3.1.2 bugs out to 3.1.3, and we can move some 3.1.1 bugs out to 3.1.2, to get some release action going. > socks stats cleanup - some stats are registered, but not used > - > > Key: TS-829 > URL: https://issues.apache.org/jira/browse/TS-829 > Project: Traffic Server > Issue Type: Bug > Components: Network >Affects Versions: 3.0.0 >Reporter: Bryan Call >Priority: Minor > Fix For: 3.1.3 > > > From reviewing TS-818 I noticed that the stats that were being double > resisted are not used. Some cleanup work should be done for the socks stats. > Stats that are registered, but not used in the code: > [bcall@snowball traffic.git]$ grep -r proxy.process.socks iocore/net/Net.cc > "proxy.process.socks.connections_successful", > "proxy.process.socks.connections_unsuccessful", > "proxy.process.socks.connections_currently_open", > These stats are used some tests, so maybe they should be added back into the > code. > [bcall@snowball traffic.git]$ grep -rl --binary-files=without-match > proxy.process.socks.connections_ * > iocore/net/Net.cc > mgmt/api/remote/APITestCliRemote.cc > test/plugin/test-mgmt/test-mgmt.c > I did however see these stats being used: > [bcall@snowball traffic.git]$ grep -r SOCKSPROXY_ * > proxy/SocksProxy.cc:#define SOCKSPROXY_INC_STAT(x) \ > proxy/SocksProxy.cc: > SOCKSPROXY_INC_STAT(socksproxy_http_connections_stat); > proxy/SocksProxy.cc: > SOCKSPROXY_INC_STAT(socksproxy_tunneled_connections_stat); -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-343) The cache lookup and add operation use different key in plugin
[
https://issues.apache.org/jira/browse/TS-343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-343:
-
Fix Version/s: (was: 3.1.2)
3.1.3
I'm moving all 3.1.2 bugs out to 3.1.3, and we can move some 3.1.1 bugs out to
3.1.2, to get some release action going.
> The cache lookup and add operation use different key in plugin
> --
>
> Key: TS-343
> URL: https://issues.apache.org/jira/browse/TS-343
> Project: Traffic Server
> Issue Type: Bug
> Components: Cache
>Affects Versions: 2.0.0
>Reporter: Flier Lu
>Priority: Critical
> Fix For: 3.1.3
>
>
> I'm developing a cache plugin base on the redis,
> http://code.google.com/p/rediscache/
> The plugin could be loaded and hook the cache read/write operations
> [May 9 16:25:05.012] Server {3079476928} NOTE: loading plugin
> 'libexec/trafficserver/redis_cache.so'
> [May 9 16:25:05.014] Server {3079476928} DIAG: (cache_plugin)
> [INKPluginInit] Starting redis cache plugin
> But the cache lookup and add operation use different key, it seems use the
> url as lookup key
> [May 9 16:25:13.149] Server {3066555280} DEBUG: (cache_plugin)
> [CacheProcessor::open_read] Cache hooks are set
> [May 9 16:25:13.153] Server {3066555280} DEBUG: (cache_plugin)
> [NewCacheVC::alloc] new B33B1EE0
> [May 9 16:25:13.153] Server {3066555280} DEBUG: (cache_plugin)
> [NewCacheVC::set_cache_http_hdr]
> [May 9 16:25:13.153] Server {3066555280} DIAG: (cache_plugin) [cache_read]
> [May 9 16:25:13.153] Server {3066555280} DEBUG: (cache_plugin)
> [INKCacheKeyGet] vc get cache key
> [May 9 16:25:13.158] Server {3066555280} DIAG: (cache_plugin) cache hitted
> for key: http://www.baidu.com/ w/ 0 bytes value
> [May 9 16:25:13.158] Server {3066555280} DEBUG: (cache_plugin)
> [INKHttpCacheReenable] event id: 1133 data: 0 size: 0
> [May 9 16:25:13.158] Server {3066555280} DEBUG: (cache_plugin)
> [INKHttpCacheReenable] cache_lookup_complete
> [May 9 16:25:13.158] Server {3066555280} DEBUG: (cache_plugin)
> [INKHttpCacheReenable] open read failed
> but store the cache item with a random MD5 as key
> [May 9 16:25:13.334] Server {3079476928} DEBUG: (cache_plugin)
> [NewCacheVC::handleWrite] event=1
> [May 9 16:25:13.334] Server {3079476928} DIAG: (cache_plugin) [cache_write]
> [May 9 16:25:13.334] Server {3079476928} DEBUG: (cache_plugin)
> [INKCacheKeyGet] vc get cache key
> [May 9 16:25:13.346] Server {3079476928} DIAG: (cache_plugin) put 3571 bytes
> value to redis w/ 16 bytes key: 0xb33b1fb0
> [May 9 16:25:13.346] Server {3079476928} DEBUG: (cache_plugin)
> [INKHttpCacheReenable] event id: 1129 data: 0 size: 3571
> [May 9 16:25:13.346] Server {3079476928} DEBUG: (cache_plugin)
> [INKHttpCacheReenable] cache_write
> I'm not sure whether it is a design issue or bug ? and the cache lookup
> always has 0 size buffer ?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-904) when doing custom logging, it would be nice if we can set dedicate sampling rate for each rule
[ https://issues.apache.org/jira/browse/TS-904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-904: - Fix Version/s: (was: 3.1.2) 3.1.3 I'm moving all 3.1.2 bugs out to 3.1.3, and we can move some 3.1.1 bugs out to 3.1.2, to get some release action going. > when doing custom logging, it would be nice if we can set dedicate sampling > rate for each rule > -- > > Key: TS-904 > URL: https://issues.apache.org/jira/browse/TS-904 > Project: Traffic Server > Issue Type: New Feature > Components: Logging >Affects Versions: 3.1.0 >Reporter: Zhao Yongming >Priority: Minor > Fix For: 3.1.3 > > > the sampling is a global config in logging, we want to get it custom-able. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-669) [GSoC2011] ATS does not support SSL in IPv6
[ https://issues.apache.org/jira/browse/TS-669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-669: - Fix Version/s: (was: 3.1.2) 3.1.3 I'm moving all 3.1.2 bugs out to 3.1.3, and we can move some 3.1.1 bugs out to 3.1.2, to get some release action going. > [GSoC2011] ATS does not support SSL in IPv6 > --- > > Key: TS-669 > URL: https://issues.apache.org/jira/browse/TS-669 > Project: Traffic Server > Issue Type: Bug > Components: SSL >Reporter: vijaya bhaskar mamidi > Labels: gsoc2011, ipv6, ssl > Fix For: 3.1.3 > > > proxy.config.http.server_other_ports is used to support IPv6 but this only > work for http ports and not secure ports. We should support IPv6 for secure > ports as well. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-110) Improve regex remap to allow substitutions in path field
[ https://issues.apache.org/jira/browse/TS-110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-110: - Fix Version/s: (was: 3.1.2) 3.1.3 I'm moving all 3.1.2 bugs out to 3.1.3, and we can move some 3.1.1 bugs out to 3.1.2, to get some release action going. > Improve regex remap to allow substitutions in path field > > > Key: TS-110 > URL: https://issues.apache.org/jira/browse/TS-110 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Reporter: Manjesh Nilange >Priority: Minor > Fix For: 3.1.3 > > > Currently, regex support covers only the host field of the remap rules. It'd > be nice to extend this to allow substitutions into the path field as well. > This will allow rules like: > regex_map http://www.example-(.*).com/ http://real-example.com/$1 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-946) Scheduling a continuation on all threads of a specific type
[ https://issues.apache.org/jira/browse/TS-946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-946: - Fix Version/s: (was: 3.1.2) 3.1.3 I'm moving all 3.1.2 bugs out to 3.1.3, and we can move some 3.1.1 bugs out to 3.1.2, to get some release action going. > Scheduling a continuation on all threads of a specific type > --- > > Key: TS-946 > URL: https://issues.apache.org/jira/browse/TS-946 > Project: Traffic Server > Issue Type: New Feature > Components: Core >Reporter: Leif Hedstrom > Fix For: 3.1.3 > > > It would be incredibly useful, both in the core and in plugin APIs, to be > able to schedule a continuation to run on all threads of a specific type. > E.g. in a plugin, something like > TSAction TSContScheduleOnThreads(TSCont cont, TSThreadPool tp); > This would be useful for e.g. setting up per-thread specifics from a plugin, > but quite possibly also from the core. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
