[jira] [Updated] (TS-1203) Crash report: HdrHeap::duplicate_str, in host_set
[
https://issues.apache.org/jira/browse/TS-1203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1203:
--
Priority: Critical (was: Major)
Fix Version/s: 3.1.4
> Crash report: HdrHeap::duplicate_str, in host_set
> -
>
> Key: TS-1203
> URL: https://issues.apache.org/jira/browse/TS-1203
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
>Affects Versions: 3.1.3
> Environment: 3.0.x, new crashes
>Reporter: Zhao Yongming
>Assignee: weijin
>Priority: Critical
> Fix For: 3.1.4
>
>
> we get some new crashes in the production:
> {code}
> warning: no loadable sections found in added symbol-file system-supplied DSO
> at 0x727fd000
> Core was generated by `/usr/bin/traffic_server -M -A,12:X,13:X'.
> Program terminated with signal 11, Segmentation fault.
> #0 0x003e5b07c24e in memcpy () from /lib64/libc.so.6
> (gdb) bt
> #0 0x003e5b07c24e in memcpy () from /lib64/libc.so.6
> #1 0x005aab68 in HdrHeap::duplicate_str (this=,
> str=0x2aae474a6ec0 ,
> nbytes=21) at HdrHeap.cc:344
> #2 0x005b3ac3 in mime_str_u16_set (heap=0x2aaabd62be12,
> s_str=0x2aae474a6ec0 , s_len=21,
> d_str=0x2aae3656f348, d_len=0x2aae3656f322, must_copy=true) at
> MIME.cc:3034
> #3 0x005aef28 in host_set (this=0x2aae268f8c18, url= out>) at URL.h:541
> #4 HTTPHdr::set_url_target_from_host_field (this=0x2aae268f8c18, url= optimized out>) at HTTP.cc:1484
> #5 0x0055dc69 in RemapProcessor::setup_for_remap (this= optimized out>, s=0x2aae268f83c8) at RemapProcessor.cc:130
> #6 0x005165d9 in HttpSM::do_remap_request (this=0x2aae268f8360,
> run_inline=true) at HttpSM.cc:3666
> #7 0x00526cbb in HttpSM::set_next_state (this=0x2aaabd62be12) at
> HttpSM.cc:6392
> #8 0x005136f0 in HttpSM::call_transact_and_set_next_state
> (this=0x2aae268f8360, f=) at HttpSM.cc:6345
> #9 0x00526713 in HttpSM::set_next_state (this=0x2aae268f8360) at
> HttpSM.cc:6553
> #10 0x005136f0 in HttpSM::call_transact_and_set_next_state
> (this=0x2aae268f8360, f=) at HttpSM.cc:6345
> #11 0x00526713 in HttpSM::set_next_state (this=0x2aae268f8360) at
> HttpSM.cc:6553
> #12 0x005136f0 in HttpSM::call_transact_and_set_next_state
> (this=0x2aae268f8360, f=) at HttpSM.cc:6345
> #13 0x00520f21 in HttpSM::state_read_client_request_header
> (this=0x2aae268f8360, event=100, data=)
> at HttpSM.cc:783
> #14 0x005259b9 in HttpSM::main_handler (this=0x2aae268f8360,
> event=100, data=0x2aae68aee6e0) at HttpSM.cc:2456
> #15 0x0066d1fb in handleEvent (nh=0x2b105668, vc=0x2aae68aee520,
> thread=0x2b104010)
> at ../../iocore/eventsystem/I_Continuation.h:146
> #16 read_signal_and_update (nh=0x2b105668, vc=0x2aae68aee520,
> thread=0x2b104010) at UnixNetVConnection.cc:138
> #17 read_from_net (nh=0x2b105668, vc=0x2aae68aee520,
> thread=0x2b104010) at UnixNetVConnection.cc:320
> #18 0x00666579 in NetHandler::mainNetEvent (this=0x2b105668,
> event=, e=0x2b8ed028) at UnixNet.cc:389
> #19 0x00691c8f in EThread::process_event (this=0x2b104010,
> e=0x35681c0, calling_code=5) at I_Continuation.h:146
> #20 0x0069259c in EThread::execute (this=0x2b104010) at
> UnixEThread.cc:263
> #21 0x0069115e in spawn_thread_internal (a=0x35621b0) at Thread.cc:88
> #22 0x003e5b80673d in start_thread () from /lib64/libpthread.so.0
> #23 0x003e5b0d44bd in clone () from /lib64/libc.so.6
> (gdb) f 1
> #1 0x005aab68 in HdrHeap::duplicate_str (this=,
> str=0x2aae474a6ec0 ,
> nbytes=21) at HdrHeap.cc:344
> 344 memcpy(new_str, str, nbytes);
> (gdb) p str
> $1 = 0x2aae474a6ec0
> (gdb) p nbytes
> $2 = 21
> (gdb) f 2
> #2 0x005b3ac3 in mime_str_u16_set (heap=0x2aaabd62be12,
> s_str=0x2aae474a6ec0 , s_len=21,
> d_str=0x2aae3656f348, d_len=0x2aae3656f322, must_copy=true) at
> MIME.cc:3034
> 3034 s_str = heap->duplicate_str(s_str, s_len);
> (gdb) p s_str
> $3 = 0x2aae474a6ec0
> (gdb) f 3
> #3 0x005aef28 in host_set (this=0x2aae268f8c18, url= out>) at URL.h:541
> 541 url_host_set(m_heap, m_url_impl, value, length, true);
> (gdb) p value
> $4 =
> (gdb) p length
> $5 =
> (gdb) f 2
> #2 0x005b3ac3 in mime_str_u16_set (heap=0x2aaabd62be12,
> s_str=0x2aae474a6ec0 , s_len=21,
> d_str=0x2aae3656f348, d_len=0x2aae3656f322, must_copy=true) at
> MIME.cc:3034
> 3034 s_str = heap->duplicate_str(s_str, s_len);
> (gdb) l
> 3029//either NULL or be valid ptr for a string already
> 3030//the string heaps
> 3031heap->free_string(*d_str, *d_len);
> 3032
> 3033if (must_copy && s_str) {
> 3034 s_str = heap->duplicate_str(s_str, s_len);
> 303
[jira] [Updated] (TS-1201) Crash report: hostdb multicache, double free
[
https://issues.apache.org/jira/browse/TS-1201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1201:
--
Fix Version/s: 3.1.4
> Crash report: hostdb multicache, double free
>
>
> Key: TS-1201
> URL: https://issues.apache.org/jira/browse/TS-1201
> Project: Traffic Server
> Issue Type: Bug
>Reporter: Zhao Yongming
>Assignee: weijin
> Fix For: 3.1.4
>
>
> {code}
> *** glibc detected *** /usr/bin/traffic_server: corrupted double-linked list:
> 0x1fe10ef0 ***
> === Backtrace: =
> /lib64/libc.so.6[0x3db2072555]
> /lib64/libc.so.6(cfree+0x4b)[0x3db20728bb]
> /usr/bin/traffic_server(MultiCacheSync::mcEvent(int, Event*)+0xa4)[0x5dae04]
> /usr/bin/traffic_server(EThread::process_event(Event*, int)+0x22f)[0x691c8f]
> /usr/bin/traffic_server(EThread::execute()+0x6a1)[0x692681]
> /usr/bin/traffic_server[0x69115e]
> /lib64/libpthread.so.0[0x3db280673d]
> /lib64/libc.so.6(clone+0x6d)[0x3db20d44bd]
> === Memory map:
> {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-1211) listen queue doesn't get modified for traffic_manager when setting configuration option in records.config
[ https://issues.apache.org/jira/browse/TS-1211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1211: -- Fix Version/s: 3.1.4 > listen queue doesn't get modified for traffic_manager when setting > configuration option in records.config > - > > Key: TS-1211 > URL: https://issues.apache.org/jira/browse/TS-1211 > Project: Traffic Server > Issue Type: Bug >Affects Versions: 3.1.3 >Reporter: Bryan Call > Fix For: 3.1.4 > > > listen queue only gets modified if you are running the traffic_server binary > and not if you use traffic_cop or the startup scripts > traffic_manager is hardcoded to have a listen backlog of 1024. -- 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-1204) Crash report: HttpSM::main_handler HttpSM.cc:2412: failed assert `magic == HTTP_SM_MAGIC_ALIVE`
[
https://issues.apache.org/jira/browse/TS-1204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1204:
--
Fix Version/s: 3.1.4
> Crash report: HttpSM::main_handler HttpSM.cc:2412: failed assert `magic ==
> HTTP_SM_MAGIC_ALIVE`
> ---
>
> Key: TS-1204
> URL: https://issues.apache.org/jira/browse/TS-1204
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
>Affects Versions: 3.1.3
> Environment: git master Sat Apr 7 03:29:50 2012. forwarding proxy on
> centos 6.2 x86_64, with cacheurl plugin
>Reporter: Zhao Yongming
> Fix For: 3.1.4
>
>
> {code}
> FATAL: HttpSM.cc:2412: failed assert `magic == HTTP_SM_MAGIC_ALIVE`
> /usr/bin/traffic_server - STACK TRACE:
> /usr/lib64/trafficserver/libtsutil.so.3(ink_fatal+0x88)[0x3ddba14368]
> /usr/lib64/trafficserver/libtsutil.so.3(_ink_assert+0x1f)[0x3ddba12c6f]
> /usr/bin/traffic_server(HttpSM::main_handler(int, void*)+0x2e)[0x5163fe]
> /usr/bin/traffic_server[0x628b4b]
> /usr/bin/traffic_server(write_to_net_io(NetHandler*, UnixNetVConnection*,
> EThread*)+0x353)[0x62c7a3]
> /usr/bin/traffic_server(NetHandler::mainNetEvent(int, Event*)+0x2fe)[0x624cce]
> /usr/bin/traffic_server(EThread::process_event(Event*, int)+0xb4)[0x6494f4]
> /usr/bin/traffic_server(EThread::execute()+0x4c3)[0x649e83]
> /usr/bin/traffic_server[0x648832]
> /lib64/libpthread.so.0[0x380dc077f1]
> /lib64/libc.so.6(clone+0x6d)[0x380d0e592d]
> {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-990) IPv6 support for clustering
[ https://issues.apache.org/jira/browse/TS-990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-990: - Fix Version/s: (was: 3.2.0) 3.3.0 I'm thinking you mean 3.3.0 ? > IPv6 support for clustering > --- > > Key: TS-990 > URL: https://issues.apache.org/jira/browse/TS-990 > Project: Traffic Server > Issue Type: Improvement > Components: Clustering >Affects Versions: 3.1.0 >Reporter: Alan M. Carroll >Assignee: Alan M. Carroll >Priority: Minor > Labels: clustering, ipv6 > Fix For: 3.3.0 > > > Update clustering to be IPv6 compatible. -- 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-935) Should EVENT_INTERNAL really be the same as TS_EVENT_TIMEOUT
[ https://issues.apache.org/jira/browse/TS-935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-935: - Fix Version/s: (was: 3.1.4) 3.3.0 Moving out to 3.3.0, please move back if there will be a fix soon for v3.1.4. > Should EVENT_INTERNAL really be the same as TS_EVENT_TIMEOUT > > > Key: TS-935 > URL: https://issues.apache.org/jira/browse/TS-935 > Project: Traffic Server > Issue Type: Bug > Components: TS API >Affects Versions: 3.0.1 >Reporter: Brian Geffon >Assignee: Brian Geffon > Fix For: 3.3.0 > > > When trying to use TSContCall with event = TS_EVENT_TIMEOUT I stumbled upon > the fact that the API will decrement the event count for EVENT_INTERNAL or > EVENT_IMMEDIATE (see INKContInternal::handle_event_count), but shouldn't we > be able to do a TSContCall with TS_EVENT_IMMEDIAITE or TS_EVENT_TIMEOUT > because as of now doing so would cause m_event_count to become -1 or > shouldn't these defined values be something different? -- 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.4) 3.3.0 Moving out to 3.3.0, please move back if you will have a new patch soon. There's no urgency here, we can land this any time you have the patch ready. > 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.0.0 >Reporter: Otto van der Schaaf >Assignee: Otto van der Schaaf >Priority: Minor > Fix For: 3.3.0 > > 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-1118) Modify how we manage the cache key / MD5 / lookup_url in the CacheSM / HttpSM.
[ https://issues.apache.org/jira/browse/TS-1118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1118: -- Fix Version/s: (was: 3.1.4) 3.3.0 > Modify how we manage the cache key / MD5 / lookup_url in the CacheSM / HttpSM. > -- > > Key: TS-1118 > URL: https://issues.apache.org/jira/browse/TS-1118 > Project: Traffic Server > Issue Type: New Feature > Components: Core >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom > Fix For: 3.3.0 > > > I'd like to make the core simpler, and more efficient, dealing with the cache > keys. We have APIs today to modify the cache URL (lookup_url), but it's > incredibly inefficient. I'll post more details on my ideas here when I have > it all written down. -- 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-1200) DOAP file reference incorrect
[ https://issues.apache.org/jira/browse/TS-1200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1200: -- Assignee: Igor Galić (was: Leif Hedstrom) > DOAP file reference incorrect > - > > Key: TS-1200 > URL: https://issues.apache.org/jira/browse/TS-1200 > Project: Traffic Server > Issue Type: Bug >Reporter: Sebb >Assignee: Igor Galić >Priority: Critical > > The DOAP file for the project needs to be available for the projects.a.o > website to function correctly. > Currently the build is looking for > http://svn.apache.org/repos/asf/trafficserver/traffic/trunk/doc/doap.rdf > However this does not exist, so the build is reporting an error. > Please update the file > https://svn.apache.org/repos/asf/infrastructure/site-tools/trunk/projects/files.xml > with the new location ASAP. -- 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-1184) Additional whitespace in proxy.config.admin.user_id value results in error
[
https://issues.apache.org/jira/browse/TS-1184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1184:
--
Fix Version/s: 3.3.0
Assignee: Leif Hedstrom
Kurt, I'm targeting this for 3.3.0. We're trying to close in on 3.2.0 :).
Thanks for the bug report. Fwiw, I think we should modify the config parser to
ignore trailing white spaces. It seems like an easy fix, but we have to make
sure there are no configs that actually needs a trailing space in the value.
> Additional whitespace in proxy.config.admin.user_id value results in error
> --
>
> Key: TS-1184
> URL: https://issues.apache.org/jira/browse/TS-1184
> Project: Traffic Server
> Issue Type: Bug
> Components: Configuration
>Affects Versions: 3.0.4
>Reporter: Kurt Payne
>Assignee: Leif Hedstrom
>Priority: Minor
> Fix For: 3.3.0
>
>
> Config looked like this:
> {noformat}
> CONFIG proxy.config.alarm_email STRING nobody
> {noformat}
> The username had a trailing space. ATS fails to start, and the following
> messages appear in {{/var/log/messages:}}
> {noformat}
> Apr 3 10:46:33 blitz traffic_cop[5498]: --- Cop Starting [Version: Apache
> Traffic Server - traffic_cop - 3.0.4 - (build # 3310 on Apr 3 2012 at
> 10:16:46)] ---
> Apr 3 10:46:33 blitz traffic_cop[5498]: can't get passwd entry for the admin
> user
> Apr 3 10:46:33 blitz traffic_cop[5498]: can't get passwd entry for the admin
> user
> Apr 3 10:46:33 blitz traffic_cop[5498]: traffic_manager not running, making
> sure traffic_server is dead
> Apr 3 10:46:33 blitz traffic_cop[5498]: spawning traffic_manager
> Apr 3 10:46:33 blitz traffic_manager[5500]: NOTE: --- Manager Starting ---
> Apr 3 10:46:33 blitz traffic_manager[5500]: NOTE: Manager Version: Apache
> Traffic Server - traffic_manager - 3.0.4 - (build # 3310 on Apr 3 2012 at
> 10:16:03)
> Apr 3 10:46:33 blitz traffic_manager[5500]: NOTE:
> RLIMIT_NOFILE(7):cur(3),max(3)
> Apr 3 10:46:33 blitz traffic_manager[5500]: {140630387636192} STATUS: opened
> /usr/local/var/log/trafficserver/manager.log
> Apr 3 10:46:35 blitz traffic_server[5509]: NOTE: --- Server Starting ---
> Apr 3 10:46:35 blitz traffic_server[5509]: NOTE: Server Version: Apache
> Traffic Server - traffic_server - 3.0.4 - (build # 3310 on Apr 3 2012 at
> 10:16:30)
> Apr 3 10:46:35 blitz traffic_server[5509]: {47289782682464} STATUS: opened
> /usr/local/var/log/trafficserver/diags.log
> {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-1185) fails to build from source with gcc 4.7
[
https://issues.apache.org/jira/browse/TS-1185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1185:
--
Fix Version/s: 3.1.4
Assignee: Leif Hedstrom
> fails to build from source with gcc 4.7
> ---
>
> Key: TS-1185
> URL: https://issues.apache.org/jira/browse/TS-1185
> Project: Traffic Server
> Issue Type: Bug
>Affects Versions: 3.1.3, 3.0.4
> Environment: Debian Unstable with gcc 4.7
>Reporter: Arno Toell
>Assignee: Leif Hedstrom
> Fix For: 3.1.4
>
>
> Using gcc 4.7, ATS fails to build from source. See Debian bug 667396
> (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=667396) for further
> information. gcc 4.7 fails with
> {code}
> 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../../proxy -I../../lib/records -I../../mgmt
> -I../../mgmt/preparse -I../../mgmt/utils -I../../proxy/hdrs
> -I../../proxy/http/remap -I../../proxy/logging -D_FORTIFY_SOURCE=2
> -D_LARGEFILE64_SOURCE=1 -D_COMPILE64BIT_SOURCE=1 -D_GNU_SOURCE -D_REENTRANT
> -Dlinux -I/usr/include/tcl8.5 -g -O2 -fstack-protector
> --param=ssp-buffer-size=4 -Wformat -Wformat-security -Werror=format-security
> -pipe -Wall -Werror -feliminate-unused-debug-symbols -fno-strict-aliasing
> -Wno-invalid-offsetof -MT HttpClientSession.o -MD -MP -MF
> .deps/HttpClientSession.Tpo -c -o HttpClientSession.o HttpClientSession.cc
> In file included from ../../lib/ts/libts.h:96:0,
> from HttpClientSession.h:35,
> from HttpClientSession.cc:35:
> ../../lib/ts/Map.h: In instantiation of 'C Map::get(K) [with K =
> unsigned int; C = int; A = DefaultAlloc]':
> HttpConnectionCount.h:51:34: required from here
> ../../lib/ts/Map.h:240:29: error: 'set_in' was not declared in this scope,
> and no declarations were found by argument-dependent lookup at the point of
> instantiation [-fpermissive]
> ../../lib/ts/Map.h:240:29: note: declarations in dependent base
> 'Vec, DefaultAlloc, 2>' are not found by
> unqualified lookup
> ../../lib/ts/Map.h:240:29: note: use 'this->set_in' instead
> ../../lib/ts/Map.h: In instantiation of 'MapElem* Map::put(K,
> C) [with K = unsigned int; C = int; A = DefaultAlloc]':
> HttpConnectionCount.h:64:37: required from here
> ../../lib/ts/Map.h:258:29: error: 'set_in' was not declared in this scope,
> and no declarations were found by argument-dependent lookup at the point of
> instantiation [-fpermissive]
> ../../lib/ts/Map.h:258:29: note: declarations in dependent base
> 'Vec, DefaultAlloc, 2>' are not found by
> unqualified lookup
> ../../lib/ts/Map.h:258:29: note: use 'this->set_in' instead
> ../../lib/ts/Map.h:263:21: error: 'set_add' was not declared in this scope,
> and no declarations were found by argument-dependent lookup at the point of
> instantiation [-fpermissive]
> ../../lib/ts/Map.h:263:21: note: declarations in dependent base
> 'Vec, DefaultAlloc, 2>' are not found by
> unqualified lookup
> ../../lib/ts/Map.h:263:21: note: use 'this->set_add' instead
> make[4]: *** [HttpClientSession.o] Error 1
> {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-1196) the via metrix in PURGE response should be documented
[
https://issues.apache.org/jira/browse/TS-1196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1196:
--
Fix Version/s: 3.3.0
> the via metrix in PURGE response should be documented
> -
>
> Key: TS-1196
> URL: https://issues.apache.org/jira/browse/TS-1196
> Project: Traffic Server
> Issue Type: Task
> Components: Documentation
>Affects Versions: 3.1.3
>Reporter: Zhao Yongming
>Assignee: Zhao Yongming
>Priority: Minor
> Fix For: 3.3.0
>
>
> {code}
> [yonghao@cache161.cn50 trafficserver]$ echo -ne "PURGE
> http://img01.taobaocdn.com/bao/uploaded/i1/000/160/T1RoNcXn5Qj0JX.jpg_60x60.jpg
> HTTP/1.0\r\n\r\n" | nc -i 1 cache162.cn50 81
> HTTP/1.0 200 Ok
> Date: Tue, 10 Apr 2012 07:10:30 GMT
> Via: http/1.1 cn50 (ApacheTrafficServer/3.0.2 [cRs f ])
> Content-Length: 0
> {code}
> what does the cR mean? we should document it down!
--
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-1187) TSMimeHdrFieldNameSet does not work for headers read from the client or origin server (but does work for headers added by traffic server)
[ https://issues.apache.org/jira/browse/TS-1187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1187: -- Fix Version/s: (was: 3.1.4) 3.3.0 > TSMimeHdrFieldNameSet does not work for headers read from the client or > origin server (but does work for headers added by traffic server) > - > > Key: TS-1187 > URL: https://issues.apache.org/jira/browse/TS-1187 > Project: Traffic Server > Issue Type: Bug > Components: MIME >Affects Versions: 3.0.2 > Environment: Redhat linux with plugin that wants to rename a header > read from the client. >Reporter: Alistair Stevenson > Labels: api-change > Fix For: 3.3.0 > > > TSMimeHdrFieldNameSet does not work for headers read from the client or > origin server (but does work for headers added by traffic server) > The name appears set (and the function returns SUCCESS) but when the data is > sent to the origin Server it is corrupted at the point where the header is > set. i.e the header name is sent but the header is corrupted after this. > I am having to create a new header and copy the values and then destroy the > original header which is not as efficient. -- 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-1033) Add some "missing" WKS's to HdrToken.
[ https://issues.apache.org/jira/browse/TS-1033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1033: -- Fix Version/s: (was: 3.1.4) 3.3.0 > Add some "missing" WKS's to HdrToken. > - > > Key: TS-1033 > URL: https://issues.apache.org/jira/browse/TS-1033 > Project: Traffic Server > Issue Type: Improvement > Components: HTTP >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom > Fix For: 3.3.0 > > > And of course various other places (including InkAPI). -- 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-1121) --disable-diags configuration option does not do anything
[ https://issues.apache.org/jira/browse/TS-1121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1121: -- Fix Version/s: (was: 3.3.0) 3.1.4 Moving back to 3.1.4, I have a small patch that at least makes most of the diagnostics compile time configurable. > --disable-diags configuration option does not do anything > - > > Key: TS-1121 > URL: https://issues.apache.org/jira/browse/TS-1121 > Project: Traffic Server > Issue Type: Bug > Components: Build, Core >Affects Versions: 3.0.3 > Environment: any >Reporter: Uri Shachar >Assignee: Leif Hedstrom >Priority: Minor > Fix For: 3.1.4 > > Original Estimate: 2h > Remaining Estimate: 2h > > The --disable-diags flag sets TS_USE_DIAGS to 0 but Diags.h tests if it is > defined or 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-1187) TSMimeHdrFieldNameSet does not work for headers read from the client or origin server (but does work for headers added by traffic server)
[ https://issues.apache.org/jira/browse/TS-1187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1187: -- Backport to Version: (was: 3.0.4) > TSMimeHdrFieldNameSet does not work for headers read from the client or > origin server (but does work for headers added by traffic server) > - > > Key: TS-1187 > URL: https://issues.apache.org/jira/browse/TS-1187 > Project: Traffic Server > Issue Type: Bug > Components: MIME >Affects Versions: 3.0.2 > Environment: Redhat linux with plugin that wants to rename a header > read from the client. >Reporter: Alistair Stevenson > Labels: api-change > Fix For: 3.1.4 > > > TSMimeHdrFieldNameSet does not work for headers read from the client or > origin server (but does work for headers added by traffic server) > The name appears set (and the function returns SUCCESS) but when the data is > sent to the origin Server it is corrupted at the point where the header is > set. i.e the header name is sent but the header is corrupted after this. > I am having to create a new header and copy the values and then destroy the > original header which is not as efficient. -- 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-1114) Crash report: HttpTransactCache::SelectFromAlternates
[
https://issues.apache.org/jira/browse/TS-1114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1114:
--
Backport to Version: 3.0.5 (was: 3.0.4)
> Crash report: HttpTransactCache::SelectFromAlternates
> -
>
> Key: TS-1114
> URL: https://issues.apache.org/jira/browse/TS-1114
> Project: Traffic Server
> Issue Type: Bug
>Reporter: Zhao Yongming
>Assignee: weijin
> Fix For: 3.1.4
>
> Attachments: cache_crash.diff
>
>
> it may or may not be the upstream issue, let us open it for tracking.
> {code}
> #0 0x0053075e in HttpTransactCache::SelectFromAlternates
> (cache_vector=0x2aaab80ff500, client_request=0x2aaab80ff4c0,
> http_config_params=0x2aaab547b800) at ../../proxy/hdrs/HTTP.h:1375
> 1375((int32_t *) & val)[0] = m_alt->m_object_key[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-1158) Race on mutex switching for NetVConnections in UnixNetVConnection::mainEvent
[ https://issues.apache.org/jira/browse/TS-1158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1158: -- Backport to Version: 3.0.5 (was: 3.0.4) > Race on mutex switching for NetVConnections in UnixNetVConnection::mainEvent > > > Key: TS-1158 > URL: https://issues.apache.org/jira/browse/TS-1158 > Project: Traffic Server > Issue Type: Bug > Components: Core >Affects Versions: 3.0.3 > Environment: ALL >Reporter: John Plevyak >Assignee: John Plevyak > Fix For: 3.1.4 > > Attachments: ts-1158-jp1.patch > > > Because of the way session management works, the vio.mutex must be > re-verified to be identical to the one the lock was taken on after the lock > is acquired. Otherwise there is a race when the mutex is switched allowing > such that the old lock is held while the new lock is in not held. -- 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-1053) get combo_handler compiled
[
https://issues.apache.org/jira/browse/TS-1053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1053:
--
Fix Version/s: (was: 3.1.4)
3.3.0
Moving all unassigned bugs out to 3.3.0. Move back and assign as necessary.
> get combo_handler compiled
> --
>
> Key: TS-1053
> URL: https://issues.apache.org/jira/browse/TS-1053
> Project: Traffic Server
> Issue Type: Task
> Components: Plugins
>Reporter: Conan Wang
> Fix For: 3.3.0
>
> Attachments: Makefile, combo_handler.diff, fetcher.diff
>
>
> combo_handler require ESI's code. Before make ESI work as a lib, you can try
> it this way:
> make "esi/lib" and "esi/fetcher" the subdir of combo_handler and use the
> makefile.
> {noformat}
> combo_handler
> |combo_handler.cc
> |fetcher
> |lib
> |LICENSE
> |Makefile
> |README
> {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-832) Crash Report: RecMessageMarshal_Realloc in cluster mode 2
[
https://issues.apache.org/jira/browse/TS-832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-832:
-
Fix Version/s: (was: 3.1.4)
3.3.0
Moving all unassigned bugs out to 3.3.0. Move back and assign as necessary.
> Crash Report: RecMessageMarshal_Realloc in cluster mode 2
> -
>
> Key: TS-832
> URL: https://issues.apache.org/jira/browse/TS-832
> Project: Traffic Server
> Issue Type: Bug
> Components: Clustering, Core
>Affects Versions: 3.1.0
> Environment: version trunk, aka v3.0 after, cluster mode set to 2(
> management cluster ), --enable-debug
>Reporter: Zhao Yongming
> Labels: cluster, realloc
> Fix For: 3.3.0
>
>
> here is two core dumps:
> {code}
> #0 0x003c33030265 in raise () from /lib64/libc.so.6
> (gdb) bt
> #0 0x003c33030265 in raise () from /lib64/libc.so.6
> #1 0x003c33031d10 in abort () from /lib64/libc.so.6
> #2 0x003c3306a84b in __libc_message () from /lib64/libc.so.6
> #3 0x003c33075421 in realloc () from /lib64/libc.so.6
> #4 0x2acf28ff4e01 in ink_realloc (ptr=Could not find the frame base
> for "ink_realloc".
> ) at ink_memory.cc:88
> #5 0x006f2835 in RecMessageMarshal_Realloc (msg=0x2b6d6010,
> record=0x2acf29248f50) at RecMessage.cc:350
> #6 0x006eced8 in send_push_message () at P_RecCore.i:154
> #7 0x006efef9 in sync_cont::sync (this=0x20034150, event=1,
> e=0x20033d30) at RecProcess.cc:263
> #8 0x004d2c5f in Continuation::handleEvent (this=0x20034150,
> event=1, data=0x20033d30) at I_Continuation.h:146
> #9 0x006f5f0b in EThread::execute (this=0x2b5d5010) at
> UnixEThread.cc:287
> #10 0x006f5181 in spawn_thread_internal (a=0x200441b0) at
> Thread.cc:88
> #11 0x003c33c064a7 in start_thread () from /lib64/libpthread.so.0
> #12 0x003c330d3c2d in clone () from /lib64/libc.so.6
> (gdb) info f
> Stack level 0, frame at 0x41f4c3e0:
> rip = 0x3c33030265 in raise; saved rip 0x3c33031d10
> called by frame at 0x41f4c520
> Arglist at 0x41f4c3d0, args:
> Locals at 0x41f4c3d0, Previous frame's sp is 0x41f4c3e0
> Saved registers:
> rip at 0x41f4c3d8
> {code}
> {code}
> #0 0x0038aa230265 in raise () from /lib64/libc.so.6
> (gdb) bt
> #0 0x0038aa230265 in raise () from /lib64/libc.so.6
> #1 0x0038aa231d10 in abort () from /lib64/libc.so.6
> #2 0x0038aa26a84b in __libc_message () from /lib64/libc.so.6
> #3 0x0038aa275421 in realloc () from /lib64/libc.so.6
> #4 0x2ab28042ce01 in ink_realloc (ptr=Could not find the frame base
> for "ink_realloc".
> ) at ink_memory.cc:88
> #5 0x006f2835 in RecMessageMarshal_Realloc (msg=0x2b6d6010,
> record=0x2ab280680f50) at RecMessage.cc:350
> #6 0x006eced8 in send_push_message () at P_RecCore.i:154
> #7 0x006efef9 in sync_cont::sync (this=0x16a6f150, event=1,
> e=0x16a6ed30) at RecProcess.cc:263
> #8 0x004d2c5f in Continuation::handleEvent (this=0x16a6f150,
> event=1, data=0x16a6ed30) at I_Continuation.h:146
> #9 0x006f5f0b in EThread::execute (this=0x2b5d5010) at
> UnixEThread.cc:287
> #10 0x006f5181 in spawn_thread_internal (a=0x16a7f1b0) at
> Thread.cc:88
> #11 0x0038aae064a7 in start_thread () from /lib64/libpthread.so.0
> #12 0x0038aa2d3c2d in clone () from /lib64/libc.so.6
> (gdb) info f
> Stack level 0, frame at 0x406b03e0:
> rip = 0x38aa230265 in raise; saved rip 0x38aa231d10
> called by frame at 0x406b0520
> Arglist at 0x406b03d0, args:
> Locals at 0x406b03d0, Previous frame's sp is 0x406b03e0
> Saved registers:
> rip at 0x406b03d8
> {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-1169) in enable-debug and pristine_host_hdr=0 mode, TS will crash when purge a cached object which is after TSCacheUrlSet
[
https://issues.apache.org/jira/browse/TS-1169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1169:
--
Fix Version/s: (was: 3.1.4)
3.3.0
Moving all unassigned bugs out to 3.3.0. Move back and assign as necessary.
> in enable-debug and pristine_host_hdr=0 mode, TS will crash when purge a
> cached object which is after TSCacheUrlSet
> ---
>
> Key: TS-1169
> URL: https://issues.apache.org/jira/browse/TS-1169
> Project: Traffic Server
> Issue Type: Bug
>Affects Versions: 3.1.3, 3.0.4
> Environment: configure --enable-debug
>Reporter: Conan Wang
> Fix For: 3.3.0
>
>
> {code}
> #6 0x000100d269af in _ink_assert (a=0x1003c6be0 "md5a == md5b ||
> t_state.txn_conf->maintain_pristine_host_hdr", f=0x1003c514e "HttpSM.cc",
> l=3921) at ink_assert.cc:44
> #7 0x000100123e59 in HttpSM::do_cache_delete_all_alts (this=0x109d41190,
> cont=0x0) at HttpSM.cc:3921
> {code}
> in HttpSM::do_cache_delete_all_alts debug code, if a object key is rewritten
> by TSCacheUrlSet, md5a will not equal md5b, and it will crash because
> maintain_pristine_host_hdr = 0 ( when disable pristine_host_hdr ).
> Anyway, the cached object is purged successfully. Maybe it's just a wrong
> assert which didn't consider TSCacheUrlSet case.
> {code}
> #ifdef DEBUG
> INK_MD5 md5a;
> INK_MD5 md5b;
> t_state.hdr_info.client_request.url_get()->MD5_get(&md5a);
> t_state.cache_info.lookup_url->MD5_get(&md5b);
> ink_assert(md5a == md5b || t_state.txn_conf->maintain_pristine_host_hdr);
> #endif
> {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-1155) POST requests that are chunked encoding hang when going forward to origin over SSL
[ https://issues.apache.org/jira/browse/TS-1155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1155: -- Fix Version/s: (was: 3.1.4) 3.3.0 Moving all unassigned bugs out to 3.3.0. Move back and assign as necessary. > POST requests that are chunked encoding hang when going forward to origin > over SSL > -- > > Key: TS-1155 > URL: https://issues.apache.org/jira/browse/TS-1155 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Affects Versions: 3.0.2 >Reporter: William Bardwell > Fix For: 3.3.0 > > > If you make a chunked encoded POST request, e.g.: > curl -H "Transfer-Encoding: chunked" -d@/etc/ca-certificates.conf > http://example.com/cgi-bin/cgi.pl > Where ATS is going forward to the origin over SSL, it junk hangs for a little > while and ends up returning a 502 response. > The problem seems to be code at proxy/http/HttpTransact.cc:5273 which only > checks for chunked encoding when the scheme is http. Just removing the extra > scheme check makes it work for me. > I don't know why it has that check, especially since it is checking for http > or https right before 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-1146) RFC 5077 TLS Session tickets
[ https://issues.apache.org/jira/browse/TS-1146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1146: -- Fix Version/s: (was: 3.1.4) 3.3.0 Moving all unassigned bugs out to 3.3.0. Move back and assign as necessary. > RFC 5077 TLS Session tickets > > > Key: TS-1146 > URL: https://issues.apache.org/jira/browse/TS-1146 > Project: Traffic Server > Issue Type: Improvement > Components: SSL >Reporter: James Peach > Fix For: 3.3.0 > > > For supporting RFC 5077 TLS Session tickets across a ATS cluster, all the > machines need to have the same server ticket. > See https://github.com/apache/httpd rev > 967d943b93498233f0ec81a5b48706fdb6892dfd -- 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-1128) gcc don't like break strict-aliasing in I_ProxyAllocator.h
[
https://issues.apache.org/jira/browse/TS-1128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1128:
--
Fix Version/s: (was: 3.1.4)
3.3.0
Moving all unassigned bugs out to 3.3.0. Move back and assign as necessary.
> gcc don't like break strict-aliasing in I_ProxyAllocator.h
> --
>
> Key: TS-1128
> URL: https://issues.apache.org/jira/browse/TS-1128
> Project: Traffic Server
> Issue Type: Improvement
> Components: Cleanup
>Affects Versions: 3.1.4
>Reporter: Zhao Yongming
>Priority: Minor
> Fix For: 3.3.0
>
>
> {code}
> cc1plus: warnings being treated as errors
> ../../iocore/eventsystem/I_ProxyAllocator.h: In member function 'virtual
> UnixNetVConnection* SSLNetAccept::allocateThread(EThread*)':
> ../../iocore/eventsystem/I_ProxyAllocator.h:54: error: dereferencing pointer
> '' does break strict-aliasing rules
> ../../iocore/eventsystem/I_ProxyAllocator.h:54: note: initialized from here
> cc1plus: warnings being treated as errors
> ../../iocore/eventsystem/I_ProxyAllocator.h: In member function 'virtual
> UnixNetVConnection* UnixNetProcessor::allocateThread(EThread*)':
> ../../iocore/eventsystem/I_ProxyAllocator.h:54: error: dereferencing pointer
> '' does break strict-aliasing rules
> ../../iocore/eventsystem/I_ProxyAllocator.h:54: note: initialized from here
> ../../iocore/eventsystem/I_ProxyAllocator.h: In member function 'virtual
> UnixNetVConnection* SSLNetProcessor::allocateThread(EThread*)':
> ../../iocore/eventsystem/I_ProxyAllocator.h:54: error: dereferencing pointer
> '' does break strict-aliasing rules
> ../../iocore/eventsystem/I_ProxyAllocator.h:54: note: initialized from here
> cc1plus: warnings being treated as errors
> ../../iocore/eventsystem/I_ProxyAllocator.h: In member function 'virtual
> UnixNetVConnection* NetAccept::allocateThread(EThread*)':
> ../../iocore/eventsystem/I_ProxyAllocator.h:54: error: dereferencing pointer
> '' does break strict-aliasing rules
> ../../iocore/eventsystem/I_ProxyAllocator.h:54: note: initialized from here
> make[2]: *** [SSLUnixNet.o] Error 1
> make[2]: *** Waiting for unfinished jobs
> make[2]: *** [UnixNetProcessor.o] Error 1
> mv -f .deps/NetVConnection.Tpo .deps/NetVConnection.Po
> mv -f .deps/Net.Tpo .deps/Net.Po
> mv -f .deps/UDPIOEvent.Tpo .deps/UDPIOEvent.Po
> make[2]: *** [UnixNetAccept.o] Error 1
> mv -f .deps/Connection.Tpo .deps/Connection.Po
> mv -f .deps/SSLCertLookup.Tpo .deps/SSLCertLookup.Po
> mv -f .deps/UnixConnection.Tpo .deps/UnixConnection.Po
> mv -f .deps/SSLConfig.Tpo .deps/SSLConfig.Po
> mv -f .deps/SSLNet.Tpo .deps/SSLNet.Po
> mv -f .deps/UnixNet.Tpo .deps/UnixNet.Po
> mv -f .deps/UnixNetPages.Tpo .deps/UnixNetPages.Po
> mv -f .deps/Socks.Tpo .deps/Socks.Po
> mv -f .deps/SSLNetVConnection.Tpo .deps/SSLNetVConnection.Po
> mv -f .deps/UnixNetVConnection.Tpo .deps/UnixNetVConnection.Po
> make[2]: Leaving directory
> `/root/rpmbuild/BUILD/trafficserver-3.0.2/iocore/net'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/root/rpmbuild/BUILD/trafficserver-3.0.2/iocore'
> make: *** [all-recursive] Error 1
> error: Bad exit status from /var/tmp/rpm-tmp.VFqSxi (%build)
> {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-1152) http_ui error,when i get http://localhost/cache/
[
https://issues.apache.org/jira/browse/TS-1152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1152:
--
Fix Version/s: (was: 3.1.4)
3.3.0
Moving all unassigned bugs out to 3.3.0. Move back and assign as necessary.
> http_ui error,when i get http://localhost/cache/
>
>
> Key: TS-1152
> URL: https://issues.apache.org/jira/browse/TS-1152
> Project: Traffic Server
> Issue Type: Bug
> Components: Web UI
>Affects Versions: 3.0.4
> Environment: centos 6 x86_64
>Reporter: bettydramit
> Fix For: 3.3.0
>
>
> When i enable http_ui ，I got follow error (get http://xxx.xxx.xxx.xxx/cache/)
> [Mar 19 16:46:17.778] Manager {13989191624} ERROR:
> [WebHttpHandleConnection] /favicon.ico not valid autoconf file
> [Mar 19 16:46:17.778] Manager {13989191624} ERROR: (last system error
> 11: Resource temporarily unavailable)
> [Mar 19 16:46:19.089] Manager {13989191624} ERROR:
> [WebHttpHandleConnection] /favicon.ico not valid autoconf file
> [Mar 19 16:46:19.090] Manager {13989191624} ERROR: (last system error
> 11: Resource temporarily unavailable)
> [Mar 19 16:46:20.763] Manager {13989191624} ERROR:
> [WebHttpHandleConnection] /favicon.ico not valid autoconf file
> [Mar 19 16:46:20.763] Manager {13989191624} ERROR: (last system error
> 11: Resource temporarily unavailable)
> [Mar 19 16:58:21.906] Manager {13989191624} ERROR:
> [WebHttpHandleConnection] /robots.txt not valid autoconf file
> [Mar 19 16:58:21.906] Manager {13989191624} ERROR: (last system error
> 11: Resource temporarily unavailable)
> [Mar 19 17:01:43.703] Manager {13989191624} ERROR:
> [WebHttpHandleConnection] /favicon.ico not valid autoconf file
> [Mar 19 17:01:43.703] Manager {13989191624} ERROR: (last system error
> 11: Resource temporarily unavailable)
--
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-1106) redirect map generates multiple Via: header entries.
[
https://issues.apache.org/jira/browse/TS-1106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1106:
--
Fix Version/s: (was: 3.1.4)
3.3.0
Moving all unassigned bugs out to 3.3.0. Move back and assign as necessary.
> redirect map generates multiple Via: header entries.
>
>
> Key: TS-1106
> URL: https://issues.apache.org/jira/browse/TS-1106
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
>Affects Versions: 3.1.2
>Reporter: Leif Hedstrom
> Fix For: 3.3.0
>
>
> It seems using the redirect rule in remap.config, ends up duplicating the
> entry in the Via: header, e.g.
> {code}
> Via: http/1.1 kramer.ogre.com (ApacheTrafficServer/3.1.3-unstable [u c s f p
> eS:tNc i p s ]), http/1.1 kramer.ogre.com
> (ApacheTrafficServer/3.1.3-unstable [u c s f p eS:tNc i p s ])
> {code}
> I'm not sure why this happens, if it's duplicating it, or if it's going
> through the SM twice. I know i'm not proxying twice through the box.
--
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-902) Crash report: invalid ip range in remap.config crash server
[
https://issues.apache.org/jira/browse/TS-902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-902:
-
Fix Version/s: (was: 3.1.4)
3.3.0
Moving all unassigned bugs out to 3.3.0. Move back and assign as necessary.
> Crash report: invalid ip range in remap.config crash server
> ---
>
> Key: TS-902
> URL: https://issues.apache.org/jira/browse/TS-902
> Project: Traffic Server
> Issue Type: Bug
> Components: Configuration, HTTP
>Affects Versions: 3.1.0, 3.0.1
> Environment: TS 3.0.1
>Reporter: Zhao Yongming
> Labels: crash
> Fix For: 3.3.0
>
>
> when I put a strage ip range, ie: src_ip=128.0.0.0-121.14.89.0 in remap ip
> filtering, it will cause the server crash:
> {code}
> [TrafficServer] using root directory '/usr'
> [Aug 4 11:04:53.209] Manager {140564987967264} NOTE:
> [LocalManager::pollMgmtProcessServer] New process connecting fd '13'
> [Aug 4 11:04:53.209] Manager {140564987967264} NOTE: [Alarms::signalAlarm]
> Server Process born
> [Aug 4 11:04:54.222] {46990117603664} STATUS: opened
> /var/log/trafficserver/diags.log
> [Aug 4 11:04:54.224] {46990117603664} NOTE: updated diags config
> [Aug 4 11:04:54.225] Server {46990117603664} NOTE: cache clustering disabled
> [Aug 4 11:04:54.239] Server {46990117603664} NOTE: cache clustering disabled
> [Aug 4 11:04:54.343] Server {46990117603664} NOTE: logging initialized[7],
> logging_mode = 1
> [Aug 4 11:04:54.345] Server {46990117603664} NOTE: PrefetchProcessor:
> Started the prefetch processor
> [Aug 4 11:04:54.346] Server {46990117603664} WARNING: Could not add rule at
> line #1; Aborting!
> [Aug 4 11:04:54.346] Server {46990117603664} WARNING: [ReverseProxy] Unable
> to parse IP value in src_ip=128.0.0.0-121.14.89.0 at line 1
> FATAL: [ReverseProxy] Unable to parse IP value in
> src_ip=128.0.0.0-121.14.89.0 at line 1
> /usr/bin/traffic_server - STACK TRACE:
> /usr/lib64/trafficserver/libtsutil.so.3(ink_fatal_va+0x9d)[0x3ab46127dd]
> /usr/lib64/trafficserver/libtsutil.so.3(ink_fatal+0x88)[0x3ab4612938]
> /usr/bin/traffic_server(_ZN10UrlRewrite10BuildTableEv+0x585)[0x580335]
> /usr/bin/traffic_server(_ZN10UrlRewriteC1EPKc+0x2fa)[0x58219a]
> /usr/bin/traffic_server(_Z18init_reverse_proxyv+0xec)[0x4de75c]
> /usr/bin/traffic_server(_Z20init_HttpProxyServerv+0xb)[0x51ee7b]
> /usr/bin/traffic_server(main+0xc07)[0x4bf177]
> /lib64/libc.so.6(__libc_start_main+0xf4)[0x389961d994]
> /usr/bin/traffic_server(__gxx_personality_v0+0x491)[0x4793a9]
> [Aug 4 11:04:54.506] Manager {140564987967264} ERROR:
> [LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig 6:
> Aborted
> {code}
> and here is the rules defined in my remap.config:
> {code}
> .defflt tools @action=deny @src_ip=0.0.0.0-127.0.0.0
> @src_ip=128.0.0.0-121.14.89.0 @src_ip=121.14.90.254-255.255.255.255
> @method=PURGE
> .useflt tools
> {code}
> well, it is invalid, but we should not crash, right?
--
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-923) traffic_logstats: critical: cannot parse log files
[ https://issues.apache.org/jira/browse/TS-923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-923: - Fix Version/s: (was: 3.1.4) 3.3.0 Moving all unassigned bugs out to 3.3.0. Move back and assign as necessary. > traffic_logstats: critical: cannot parse log files > -- > > Key: TS-923 > URL: https://issues.apache.org/jira/browse/TS-923 > Project: Traffic Server > Issue Type: Bug > Components: Logging >Affects Versions: 3.0.1 > Environment: Centos 5.6 2.6.18-164.6.1.el5 #1 SMP Tue Nov 3 16:12:36 > EST 2009 x86_64 x86_64 x86_64 GNU/Linux >Reporter: Hung Nguyen > Fix For: 3.3.0 > > > After running for about 3 days, traffic_logstats stop working with following > error: > traffic_logstats > critical: can't parse log file > I tried to set Logging to various parameter in record.config, but still > cannot get traffic_logstats works. > When this problem happens, TS uses less resource. > In my setup, I use ram cache only. > -- 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-891) Crash report: mime_hdr_sanity_check in mime_parser_parse during
[
https://issues.apache.org/jira/browse/TS-891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-891:
-
Fix Version/s: (was: 3.1.4)
3.3.0
Moving all unassigned bugs out to 3.3.0. Move back and assign as necessary.
> Crash report: mime_hdr_sanity_check in mime_parser_parse during
>
>
> Key: TS-891
> URL: https://issues.apache.org/jira/browse/TS-891
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
>Affects Versions: 3.0.1
> Environment: v3.0.1, submit from user
>Reporter: Zhao Yongming
> Labels: crash
> Fix For: 3.3.0
>
>
> no other information, place holding first.
> {code}
> zym@zym6400 ~ $ c++filt < /tmp/a
> FATAL: MIME.cc:576: failed assert `strncasecmp(field->m_ptr_name, wks,
> field->m_len_name) == 0`
> /usr/local/ts/bin/traffic_server - STACK TRACE:
> /usr/local/ts/lib/libtsutil.so.3(ink_fatal_va+0xc7)[0x4003109b]
> /usr/local/ts/lib/libtsutil.so.3(ink_fatal+0x2b)[0x400310ed]
> /usr/local/ts/lib/libtsutil.so.3(_ink_assert+0xc4)[0x4002fd54]
> /usr/local/ts/bin/traffic_server(mime_hdr_sanity_check(MIMEHdrImpl*)+0x323)[0x823f5c8]
> /usr/local/ts/bin/traffic_server(mime_hdr_field_attach(MIMEHdrImpl*,
> MIMEField*, int, MIMEField*)+0x36[0x8241e17]
> /usr/local/ts/bin/traffic_server(mime_parser_parse(MIMEParser*, HdrHeap*,
> MIMEHdrImpl*, char const**, char const*, bool, bool)+0x2b5)[0x82442b6]
> /usr/local/ts/bin/traffic_server(http_parser_parse_req(HTTPParser*, HdrHeap*,
> HTTPHdrImpl*, char const**, char const*, bool, bool)+0x801)[0x823ae17]
> /usr/local/ts/bin/traffic_server(HTTPHdr::parse_req(HTTPParser*,
> IOBufferReader*, int*, bool)+0x126)[0x82380f4]
> /usr/local/ts/bin/traffic_server(HttpSM::state_read_client_request_header(int,
> void*)+0x2f0)[0x819b87c]
> /usr/local/ts/bin/traffic_server(HttpSM::main_handler(int,
> void*)+0x1f[0x81a0cc0]
> /usr/local/ts/bin/traffic_server(Continuation::handleEvent(int,
> void*)+0x47)[0x81154f9]
> /usr/local/ts/bin/traffic_server[0x82f644c]
> /usr/local/ts/bin/traffic_server[0x82f6e43]
> /usr/local/ts/bin/traffic_server(UnixNetVConnection::net_read_io(NetHandler*,
> EThread*)+0x17)[0x82f8c6d]
> /usr/local/ts/bin/traffic_server(NetHandler::mainNetEvent(int,
> Event*)+0x62a)[0x82f2ea4]
> /usr/local/ts/bin/traffic_server(Continuation::handleEvent(int,
> void*)+0x47)[0x81154f9]
> /usr/local/ts/bin/traffic_server(EThread::process_event(Event*,
> int)+0x114)[0x831af5a]
> /usr/local/ts/bin/traffic_server(EThread::execute()+0x425)[0x831b529]
> /usr/local/ts/bin/traffic_server(main+0x1245)[0x813f233]
> /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe0)[0x40476450]
> /usr/local/ts/bin/traffic_server[0x80f60e1]
> {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-921) TSIOBufferBlockReadStart() could'nt return the corresponding chunk data length when original server using the "Transfer Encoding: chunked" http header !
[
https://issues.apache.org/jira/browse/TS-921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-921:
-
Fix Version/s: (was: 3.1.4)
3.3.0
Moving all unassigned bugs out to 3.3.0. Move back and assign as necessary.
> TSIOBufferBlockReadStart() could'nt return the corresponding chunk data
> length when original server using the "Transfer Encoding: chunked" http
> header !
>
>
> Key: TS-921
> URL: https://issues.apache.org/jira/browse/TS-921
> Project: Traffic Server
> Issue Type: Bug
> Components: TS API
>Affects Versions: 3.0.1
> Environment: OS: Ubuntu 10.10 32bit, Traffic Server version:.3.0.1,
> Web Browser：firefox 6.0，CPU: Intel core i3-2100 3.10GHz, Memory: 2G,
> HardDisk: 500G
>Reporter: taoyunxing
> Labels: transfer_encoding_chunded
> Fix For: 3.3.0
>
> Original Estimate: 672h
> Remaining Estimate: 672h
>
> Recently I meet with a strange proble when I manage to get the server
> response body in the "Transfer Encoding: chunked" mode:
> I couldn't get the corresponding chunk length in hexdecimal ! The details as
> follows:
> I use the "null-transform" plugin modified to just output the server response
> body, when the web server uses the "Transfer Encoding: chunked" header
> to transfer chunked data to user agent, eg, I request the web page:
> "http://www.qq.com/";, I just get the chunk body data, but get no chunk length
> in
> the hexdecimal format "383cb\r\n" before the chunk body data. the chunk body
> data is uncompressed and like as " 1.0 Transitional//EN"
> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";>\r\n..."
> In addition, I capture the data packet using the Wireshark software, I sure
> that I see the chunk length "383cb\r\n" before the chunk body data
> " "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";>\r\n...", it is
> a complete chunk response !
> I continue to check the code of null-transform.c, set a breakpoint at the
> function TSIOBufferBlockReadStart(), run ATS and debug it, when ATS stop at
> the breakpoint TSIOBufferBlockReadStart(), I print the return string of
> TSIOBufferBlockReadStart(), there is no chunk data length at the head of
> output string, which implies the api TSIOBufferBlockReadStart() has bug！
> Breakpoint 1, TSIOBufferBlockReadStart (blockp=0x89d6570, readerp=0x89d5330,
> avail=0xb6c8e288) at InkIOCoreAPI.cc:659
> 659 {
> (gdb) s
> 660 sdk_assert(sdk_sanity_check_iocore_structure(blockp) == TS_SUCCESS);
> (gdb) n
> 667 p = blk->start();
> (gdb)
> 668 if (avail)
> (gdb) p p
> $3 = 0xb1312000 " Transitional//EN\"
> \"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd\";>\r\n xmlns=\"http://www.w3.org/1999/xhtml\";>\r\n\r\n http-equiv=\"Conten"...
> (gdb)
--
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-801) Crash Report: enable update will triger Segmentation fault
[
https://issues.apache.org/jira/browse/TS-801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-801:
-
Fix Version/s: (was: 3.1.4)
3.3.0
Moving all unassigned bugs out to 3.3.0. Move back and assign as necessary.
> Crash Report: enable update will triger Segmentation fault
> --
>
> Key: TS-801
> URL: https://issues.apache.org/jira/browse/TS-801
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
>Affects Versions: 2.1.8
> Environment: v2.1.8 and update function enabled.
>Reporter: Zhao Yongming
> Labels: update
> Fix For: 3.3.0
>
>
> {code}
> b13621367...@hotmail.com: NOTE: Traffic Server received Sig 11: Segmentation
> fault
> /usr/local/ts/bin/traffic_server - STACK TRACE:
> b13621367...@hotmail.com:
> /usr/local/ts/bin/traffic_server[0x5260c9]
> /lib64/libpthread.so.0[0x3088e0f4c0]
> [0x6e]
> /usr/local/ts/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void
> (*)(HttpTransact::State*))+0x6e)[0x57e0e2]
> /usr/local/ts/bin/traffic_server(HttpSM::set_next_state()+0x18b)[0x57e369]
> /usr/local/ts/bin/traffic_server(HttpUpdateSM::set_next_state()+0xad)[0x5b604b]
> /usr/local/ts/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void
> (*)(HttpTransact::State*))+0x15e)[0x57e1d2]
> /usr/local/ts/bin/traffic_server(HttpSM::handle_api_return()+0x138)[0x56d9aa]
> /usr/local/ts/bin/traffic_server(HttpUpdateSM::handle_api_return()+0x47)[0x5b5cc1]
> /usr/local/ts/bin/traffic_server(HttpSM::do_api_callout()+0x3f)[0x582cc3]
> /usr/local/ts/bin/traffic_server(HttpSM::set_next_state()+0x64)[0x57e242]
> /usr/local/ts/bin/traffic_server(HttpUpdateSM::set_next_state()+0xad)[0x5b604b]
> /usr/local/ts/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void
> (*)(HttpTransact::State*))+0x15e)[0x57e1d2]
> /usr/local/ts/bin/traffic_server(HttpSM::handle_api_return()+0x13b13621367...@hotmail.com:
> 8)[0x56d9aa]
> /usr/local/ts/bin/traffic_server(HttpUpdateSM::handle_api_return()+0x47)[0x5b5cc1]
> /usr/local/ts/bin/traffic_server(HttpSM::do_api_callout()+0x3f)[0x582cc3]
> /usr/local/ts/bin/traffic_server(HttpSM::set_next_state()+0x64)[0x57e242]
> /usr/local/ts/bin/traffic_server(HttpUpdateSM::set_next_state()+0xad)[0x5b604b]
> /usr/local/ts/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void
> (*)(HttpTransact::State*))+0x15e)[0x57e1d2]
> /usr/local/ts/bin/traffic_server(HttpUpdateSM::handle_api_return()+0x36)[0x5b5cb0]
> /usr/local/ts/bin/traffic_server(HttpSM::do_api_callout()+0x3f)[0x582cc3]
> /usr/local/ts/bin/traffic_server(HttpSM::state_add_to_list(int,
> void*)+0x2aa)[0x56a51c]
> /usr/local/ts/bin/traffic_server(HttpSM::main_handler(int,
> void*)+0x2cb)[0x570c13]
> /usr/local/ts/bin/traffic_server(Continuation::handleEvent(int,
> void*)+0x6c)[0x4e0486]
> /usr/local/ts/bin/traffic_server(HttpUpdateSM::start_scheduled_update(Continuation*,
> HTTPHdr*)+0x168)[0x5b5c1c]
> /usr/local/ts/bin/traffic_server(UpdateSM::http_scheme(UpdateSM*)+0x335)[0x53599f]
> /usr/local/ts/bin/traffic_server(UpdateSM::HandleSMEvent(int,
> Event*)+0x1ab)[0x535437]
> /usr/local/ts/bin/traffic_server(Continuation::handleEvent(int,
> void*)+0x6c)[0x4e0486]
> /usr/local/ts/bin/traffic_server(EThread::process_event(Event*,
> int)+0x12c)[0x6fa9dc]
> /usr/local/ts/bin/traffic_server(EThread::execute()+0x9b)[0x6fabef]
> /usr/local/ts/bin/traffic_server[0x6f9b4c]
> /lib64/libpthread.so.0[0x3088e077e1]
> /lib64/libc.so.6(clone+0x6d)[0x38584e18ed]
> /lib64/libc.so.6(clone+0x6d)[0x38584e18ed]
> /lib64/libc.so.6(clone+0x6d)[0x38584e18ed]
> [May 26 16:25:14.569] Manager {140030245394400} ERROR:
> [LocalManager::-PollMgmtProcessServer] Server Process terminated due to Sig
> 11: Segmentation fault
> [May 26 16:25:14.569] Manager {140030245394400} ERROR: (last system error
> 32: Broken pipe)
> [[May 26 16:25:14.569] Manager {140030245394400} ERROR:
> [Alarms::-SignalAlarm] Server Process was reset
> [May 26 16:25:14.569] Manager {140030245394400} ERROR: (last system error
> 32: Broken pipe)
> [May 26 16:25:15.577] Manager {140030245394400} NOTE:
> [LocalManager::-StartProxy] Launching ts process
> {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-1069) better handle of the gzipped content
[ https://issues.apache.org/jira/browse/TS-1069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1069: -- Fix Version/s: (was: 3.1.4) 3.3.0 Moving all unassigned bugs out to 3.3.0. Move back and assign as necessary. > better handle of the gzipped content > > > Key: TS-1069 > URL: https://issues.apache.org/jira/browse/TS-1069 > Project: Traffic Server > Issue Type: Sub-task >Reporter: Zhao Yongming > Fix For: 3.3.0 > > > when the triggered URL is gzipped, prefetch engine will skip that request, > while not put that URL in the prefetch url list, and start another request > without accept gzip encodes? -- 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-1125) POST's with Expect: 100-continue are slowed by delayed 100 response.
[ https://issues.apache.org/jira/browse/TS-1125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1125: -- Fix Version/s: (was: 3.1.4) 3.3.0 Moving all unassigned bugs out to 3.3.0. Move back and assign as necessary. > POST's with Expect: 100-continue are slowed by delayed 100 response. > > > Key: TS-1125 > URL: https://issues.apache.org/jira/browse/TS-1125 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Affects Versions: 3.0.2 > Environment: TS 3.0.2 going to Apache 2.2 web server >Reporter: William Bardwell >Priority: Minor > Fix For: 3.3.0 > > > Sending a post like: > POST / HTTP/1.1 > Host: www.example.com > Content-Length: 10 > Expect: 100-continue > directly to the web server immediately sends back: > HTTP/1.1 100 Continue > And then when the post data is sent, a status 200 response comes back. > But when going through ATS the "HTTP/1.1 100 Continue" is not sent > immediately, and instead is sent after the POST data has been received. This > is legal, but it makes clients that are hoping for a 100 continue to wait a > little while hoping to get that, ATS should forward that response through > immediately. > Note: I see curl using "Expect: 100-continue" with > 1024 bytes of post data, > but web searching indicates that some Microsoft products also use 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-1119) fatal error when uploading gzip-transform plugin
[
https://issues.apache.org/jira/browse/TS-1119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1119:
--
Fix Version/s: (was: 3.1.4)
3.3.0
Moving all unassigned bugs out to 3.3.0. Move back and assign as necessary.
> fatal error when uploading gzip-transform plugin
>
>
> Key: TS-1119
> URL: https://issues.apache.org/jira/browse/TS-1119
> Project: Traffic Server
> Issue Type: Bug
> Components: Plugins
>Affects Versions: 3.0.2
>Reporter: angela asher
>Priority: Blocker
> Fix For: 3.3.0
>
> Attachments: gzip-transform.diff
>
>
> getting the following error on traffic.out when running the traffic server
> with gzip-transform plugin:
> [Feb 23 16:28:15.509] Server {47392853811680} DEBUG: (http) [13] calling
> plugin on hook TS_HTTP_READ_RESPONSE_HDR_HOOK at hook 0x35BBEE0
> FATAL: InkAPI.cc:3036: failed assert `sdk_sanity_check_null_ptr((void*)
> value_len_ptr) == TS_SUCCESS`
> /usr/local/bin/traffic_server - STACK TRACE:
> /usr/local/lib/libtsutil.so.3(ink_fatal_va+0x9d)[0x2b1a7ecca37d]
> /usr/local/lib/libtsutil.so.3(ink_fatal+0x88)[0x2b1a7ecca4d8]
> /usr/local/lib/libtsutil.so.3(_ink_assert+0x85)[0x2b1a7ecc8af5]
> /usr/local/bin/traffic_server(TSMimeHdrFieldValueStringGet+0x124)[0x4a9144]
> /usr/local/libexec/trafficserver/gzip-transform.so(+0x1bde)[0x2b1a8b3c7bde]
> /usr/local/libexec/trafficserver/gzip-transform.so(+0x27c4)[0x2b1a8b3c87c4]
> /usr/local/bin/traffic_server(_ZN6HttpSM17state_api_calloutEiPv+0x525)[0x52cfa5]
> /usr/local/bin/traffic_server(_ZN6HttpSM33state_read_server_response_headerEiPv+0x420)[0x52f1c0]
> /usr/local/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0xe8)[0x530568]
> /usr/local/bin/traffic_server[0x681dcb]
> /usr/local/bin/traffic_server[0x6848f1]
> /usr/local/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x2e2)[0x67d402]
> /usr/local/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0xb4)[0x6a9ce4]
> /usr/local/bin/traffic_server(_ZN7EThread7executeEv+0x4c3)[0x6aa673]
> /usr/local/bin/traffic_server(main+0x1128)[0x4c07e8]
> /lib64/libc.so.6(__libc_start_main+0xfd)[0x2b1a81092c5d]
> /usr/local/bin/traffic_server[0x47e0e9]
> [Feb 23 16:28:15.512] Manager {140400187066336} ERROR:
> [LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig 6:
> Aborted
> [Feb 23 16:28:15.512] Manager {140400187066336} ERROR: (last system error 2:
> No such file or directory)
> [Feb 23 16:28:15.512] Manager {140400187066336} ERROR: [Alarms::signalAlarm]
> Server Process was reset
> [Feb 23 16:28:15.512] Manager {140400187066336} ERROR: (last system error 2:
> No such file or directory)
> [Feb 23 16:28:16.522] Manager {140400187066336} NOTE:
> [LocalManager::startProxy] Launching ts process
> [TrafficServer] using root directory '/usr/local'
> [Feb 23 16:28:16.527] Manager {140400187066336} NOTE:
> [LocalManager::pollMgmtProcessServer] New process connecting fd '11'
> [Feb 23 16:28:16.527] Manager {140400187066336} NOTE: [Alarms::signalAlarm]
> Server Process born
> [Feb 23 16:28:17.539] {47668265021920} STATUS: opened
> /usr/local/var/log/trafficserver/diags.log
> [Feb 23 16:28:17.539] {47668265021920} NOTE: updated diags config
> [Feb 23 16:28:17.541] Server {47668265021920} DEBUG: (http_aeua)
> [HttpConfig::init_aeua_filter] - Config:
> "/usr/local/etc/trafficserver/ae_ua.config"
> [Feb 23 16:28:17.541] Server {47668265021920} DEBUG: (http_aeua)
> [HttpConfig::init_aeua_filter] - Opening config
> "/usr/local/etc/trafficserver/ae_ua.config"
> [Feb 23 16:28:17.541] Server {47668265021920} DEBUG: (http_aeua)
> [HttpConfig::init_aeua_filter] - Added 0 REGEXP filters
> [Feb 23 16:28:17.541] Server {47668265021920} DEBUG: (http_aeua)
> [init_http_aeua_filter] - Total loaded 0 REGEXP for
> Accept-Enconding/User-Agent filtering
> [Feb 23 16:28:17.542] Server {47668265021920} NOTE: cache clustering disabled
> [Feb 23 16:28:17.543] Server {47668265021920} DEBUG: (dns) ink_dns_init:
> called with init_called = 0
> [Feb 23 16:28:17.546] Server {47668265021920} DEBUG: (dns)
> localhost=isk-vsrv227
> [Feb 23 16:28:17.546] Server {47668265021920} DEBUG: (dns) Round-robin
> nameservers = 0
> [Feb 23 16:28:17.547] Server {47668265021920} NOTE: cache clustering disabled
> [Feb 23 16:28:17.568] Server {47668265021920} NOTE: logging initialized[7],
> logging_mode = 3
> [Feb 23 16:28:17.569] Server {47668265021920} NOTE: loading plugin
> '/usr/local/libexec/trafficserver/gzip-transform.so'
> [Feb 23 16:28:17.570] Server {47668265021920} DEBUG: (http_init)
> proxy.config.http.redirection_enabled = 0
> [Feb 23 16:28:17.570] Server {47668265021920} DEBUG: (http_init)
> proxy.config.http.number_of_redirections = 1
> [Feb 23 16:28:17.570] Server {47668265021920} DEBUG: (http_ini
[jira] [Updated] (TS-1058) Intercept an HTTP client's request
[
https://issues.apache.org/jira/browse/TS-1058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1058:
--
Fix Version/s: (was: 3.1.4)
3.3.0
Moving all unassigned bugs out to 3.3.0. Move back and assign as necessary.
> Intercept an HTTP client's request
> --
>
> Key: TS-1058
> URL: https://issues.apache.org/jira/browse/TS-1058
> Project: Traffic Server
> Issue Type: Bug
> Components: TS API
>Affects Versions: 3.1.1
>Reporter: Yakov Kopel
> Labels: patch
> Fix For: 3.3.0
>
> Attachments: patch.diff
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> I want that the trafficserver will give the client the response instead of
> the server.
> The trafficserver offers the INKHttpTxnIntercept api to do so, but it is not
> so convenience to use it.
> I want to use the regular flow of the trafficserver, and its regular parsing
> commands.
> The trafficserver's plugins examples also aren't using the
> INKHttpTxnIntercept , but they rather using the "rasing error" method, and
> then they response the request at the response hook.
> So, this is whta i did.
> On the global-hook at the TS_EVENT_HTTP_READ_REQUEST_HDR i raised
> TS_EVENT_HTTP_ERROR.
> I also added TS_HTTP_SEND_RESPONSE_HDR_HOOK and there i returned http
> response with the KEEP-ALIVE header.
> The problem is that the trafficserver is closing the connection although i
> added to the response the KEEP-ALIVE header.
>
> When the Trafficserver is trying to send response to the client, it terminate
> the session after it.
> Although I added the "KEEP-ALIVE" mime field - it didn't work.
> The debug dump is looking like this:
> [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http) [4]
> [&HttpSM::state_api_callback, HTTP_API_CONTINUE]
> [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http) [4]
> [&HttpSM::state_api_callout, HTTP_API_CONTINUE]
> [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_redirect)
> [HttpSM::do_redirect]
> [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_redirect)
> [HttpTunnel::deallocate_postdata_copy_buffers]
> [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_tunnel) [4]
> adding producer 'internal msg'
> [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_tunnel) [4]
> adding consumer 'user agent'
> [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_tunnel)
> tunnel_run started, p_arg is NULL
> [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_tunnel) [4]
> consumer_handler [user agent VC_EVENT_WRITE_COMPLETE]
> [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http) [4]
> [&HttpSM::tunnel_handler_ua, VC_EVENT_WRITE_COMPLETE]
> [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_cs) [4] session
> closed
> [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_cs) [4] session
> destroy
> [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http) [4]
> [HttpSM::main_handler, HTTP_TUNNEL_EVENT_DONE]
> [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http) [4]
> [&HttpSM::tunnel_handler, HTTP_TUNNEL_EVENT_DONE]
> [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_redirect)
> [HttpTunnel::deallocate_postdata_copy_buffers]
> [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http) [4] calling
> plugin on hook TS_HTTP_TXN_CLOSE_HOOK at hook 0x3B97610
> The Solution:
> I'm adding a patch of functino that rasing the internal flag of KEEP-ALIVE,
> so the trafficserver will realy believe us that we want to keep this
> connection alive :)
> Example for the usage of the new function:
> // Tell the trafficserver to not close this connection (keep-alive)
> TSHttpTxnCloseAfterResponse(txnp, 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-981) Remove libev support (it's not well support, and might crash)
[ https://issues.apache.org/jira/browse/TS-981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-981: - Summary: Remove libev support (it's not well support, and might crash) (was: ATS as transparent proxy crashes under heavy load) Changing the summary on this one, as we'll remove libev support (I checked with John on this). > Remove libev support (it's not well support, and might crash) > - > > Key: TS-981 > URL: https://issues.apache.org/jira/browse/TS-981 > Project: Traffic Server > Issue Type: Bug > Components: Core >Affects Versions: 3.0.0 > Environment: 4 core desktop. Centos 5.6, kernel 2.6.39.2 compiled > with TPROXY support. > ATS compiled as: ./configure --enable-tproxy --enable-libev >Reporter: Danny Shporer >Assignee: Leif Hedstrom >Priority: Critical > Fix For: 3.1.4 > > Attachments: records.config > > > ATS crashes under heavy load testing - around 25,000 HTTP transactions per > second. > I have tested it on both vesions 3.0.0 and 3.0.1 and the same happens. > GDB info: > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0x42174940 (LWP 6663)] > 0x0068fd4b in modify (this=0x2b12c628, event= out>, e=) at P_UnixNet.h:536 > 536 fd_change(event_loop->eio, eio.fd, 0); > (gdb) bt > #0 0x0068fd4b in modify (this=0x2b12c628, event= out>, e=) at P_UnixNet.h:536 > #1 NetHandler::mainNetEvent (this=0x2b12c628, event= out>, e=) at UnixNet.cc:432 > #2 0x006bfc4f in EThread::process_event (this=0x2b12b010, > e=0xf44570, calling_code=5) at I_Continuation.h:146 > #3 0x006c055c in EThread::execute (this=0x2b12b010) at > UnixEThread.cc:262 > #4 0x006bef8e in spawn_thread_internal (a=0xf35c90) at Thread.cc:88 > #5 0x003e9dc0673d in start_thread () from /lib64/libpthread.so.0 > #6 0x003e9d0d44bd in clone () from /lib64/libc.so.6 > (gdb) info f > Stack level 0, frame at 0x42174030: > rip = 0x68fd4b in modify (P_UnixNet.h:536); saved rip 0x6bfc4f > inlined into frame 1 > source language c++. > Arglist at unknown address. > Locals at unknown address, Previous frame's sp in rsp -- 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-1153) On Solaris, link with libumem by default
[ https://issues.apache.org/jira/browse/TS-1153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1153: -- Fix Version/s: (was: 3.1.4) 3.3.0 > On Solaris, link with libumem by default > > > Key: TS-1153 > URL: https://issues.apache.org/jira/browse/TS-1153 > Project: Traffic Server > Issue Type: Improvement > Components: Performance > Environment: Solaris >Reporter: Igor Galić > Labels: memory > Fix For: 3.3.0 > > > http://developers.sun.com/solaris/articles/multiproc/multiproc.html > Maybe we should make use of that and link to libumem by default. -- 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-1067) Remove unused config (and code) for bandwidth management
[ https://issues.apache.org/jira/browse/TS-1067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1067: -- Fix Version/s: (was: 3.1.4) 3.3.0 > Remove unused config (and code) for bandwidth management > > > Key: TS-1067 > URL: https://issues.apache.org/jira/browse/TS-1067 > Project: Traffic Server > Issue Type: Improvement > Components: Cleanup >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom > Fix For: 3.3.0 > > > There's a configuration file, and code, related to bandwidth management for > the old UDP based streaming media protocols, that were part of the core (it's > long since gone). We should remove this for now, and possibly (for future > plugins) add APIs appropriate for this. -- 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-1155) POST requests that are chunked encoding hang when going forward to origin over SSL
[ https://issues.apache.org/jira/browse/TS-1155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1155: -- Fix Version/s: 3.1.4 > POST requests that are chunked encoding hang when going forward to origin > over SSL > -- > > Key: TS-1155 > URL: https://issues.apache.org/jira/browse/TS-1155 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Affects Versions: 3.0.2 >Reporter: William Bardwell > Fix For: 3.1.4 > > > If you make a chunked encoded POST request, e.g.: > curl -H "Transfer-Encoding: chunked" -d@/etc/ca-certificates.conf > http://example.com/cgi-bin/cgi.pl > Where ATS is going forward to the origin over SSL, it junk hangs for a little > while and ends up returning a 502 response. > The problem seems to be code at proxy/http/HttpTransact.cc:5273 which only > checks for chunked encoding when the scheme is http. Just removing the extra > scheme check makes it work for me. > I don't know why it has that check, especially since it is checking for http > or https right before 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-1146) RFC 5077 TLS Session tickets
[ https://issues.apache.org/jira/browse/TS-1146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1146: -- Fix Version/s: 3.1.4 > RFC 5077 TLS Session tickets > > > Key: TS-1146 > URL: https://issues.apache.org/jira/browse/TS-1146 > Project: Traffic Server > Issue Type: Improvement > Components: SSL >Reporter: James Peach > Fix For: 3.1.4 > > > For supporting RFC 5077 TLS Session tickets across a ATS cluster, all the > machines need to have the same server ticket. > See https://github.com/apache/httpd rev > 967d943b93498233f0ec81a5b48706fdb6892dfd -- 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-1034) reduce futex locking period
[
https://issues.apache.org/jira/browse/TS-1034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1034:
--
Fix Version/s: 3.1.4
> reduce futex locking period
> ---
>
> Key: TS-1034
> URL: https://issues.apache.org/jira/browse/TS-1034
> Project: Traffic Server
> Issue Type: Improvement
> Components: Core, HTTP
>Affects Versions: 3.1.1
>Reporter: Zhao Yongming
>Assignee: Zhao Yongming
> Fix For: 3.1.4
>
>
> we need to reduce futex locking period, here is a simple testing in my
> 24cores HP380 system, with 24 ab, all cached in memory:
> {code}
> #!/bin/sh
> for i in {1..24}
> do
> ab -n 1 -c 16 -X 127.0.0.$i:8080
> http://img02.taobaocdn.com/tps/i2/T1o0ypXk4w-1000-40.png?$i &
> done
> {code}
> result:
> {code}
> Every 2.0s: echo show:proxy-stats | traffic_shell
> Mon Nov 28 16:06:42 2011
> Successfully Initialized MgmtAPI in /var/run/trafficserver
> Document Hit Rate 100.00 % *
> Bandwidth Saving - 100.00 % *
> Cache Percent Free --- 99.999619 %
> Open Server Connections -- 0
> Open Client Connections -- 9
> Open Cache Connections --- 2
> Client Throughput 6824.747070 MBit/Sec
> Transaction Per Second --- 53914.925781
> * Value represents 10 second average.
> strace -c -p 11712
> Process 11712 attached - interrupt to quit
> ^CProcess 11712 detached
> % time seconds usecs/call callserrors syscall
> -- --- --- - -
> 26.850.890335 15 58920 writev
> 24.450.810866 7118147 epoll_ctl
> 22.270.738451 13 58920 close
> 11.500.381362 6 59227 getsockname
> 9.860.326843 3119192 59228 read
> 3.530.117058 16 7100 1931 futex
> 1.530.050884 58 884 epoll_wait
> 0.000.37 0 404 rt_sigprocmask
> 0.000.00 0 3 write
> 0.000.00 0 2 brk
> 0.000.00 010 msync
> -- --- --- - -
> 100.003.315836422809 61159 total
> {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-1031) reduce lock in netHandler and reduce the possiblity of acquiring expire server sessions
[ https://issues.apache.org/jira/browse/TS-1031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1031: -- Fix Version/s: 3.1.4 > reduce lock in netHandler and reduce the possiblity of acquiring expire > server sessions > --- > > Key: TS-1031 > URL: https://issues.apache.org/jira/browse/TS-1031 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Affects Versions: 3.1.1 >Reporter: Zhao Yongming >Assignee: weijin >Priority: Minor > Fix For: 3.1.4 > > Attachments: ts-1031.diff > > > reduce lock in netHandler and reduce the possiblity of acquiring expire > server sessions. put your patch here for review :D -- 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-1169) in enable-debug and pristine_host_hdr=0 mode, TS will crash when purge a cached object which is after TSCacheUrlSet
[
https://issues.apache.org/jira/browse/TS-1169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1169:
--
Fix Version/s: 3.1.4
> in enable-debug and pristine_host_hdr=0 mode, TS will crash when purge a
> cached object which is after TSCacheUrlSet
> ---
>
> Key: TS-1169
> URL: https://issues.apache.org/jira/browse/TS-1169
> Project: Traffic Server
> Issue Type: Bug
>Affects Versions: 3.1.3, 3.0.4
> Environment: configure --enable-debug
>Reporter: Conan Wang
> Fix For: 3.1.4
>
>
> {code}
> #6 0x000100d269af in _ink_assert (a=0x1003c6be0 "md5a == md5b ||
> t_state.txn_conf->maintain_pristine_host_hdr", f=0x1003c514e "HttpSM.cc",
> l=3921) at ink_assert.cc:44
> #7 0x000100123e59 in HttpSM::do_cache_delete_all_alts (this=0x109d41190,
> cont=0x0) at HttpSM.cc:3921
> {code}
> in HttpSM::do_cache_delete_all_alts debug code, if a object key is rewritten
> by TSCacheUrlSet, md5a will not equal md5b, and it will crash because
> maintain_pristine_host_hdr = 0 ( when disable pristine_host_hdr ).
> Anyway, the cached object is purged successfully. Maybe it's just a wrong
> assert which didn't consider TSCacheUrlSet case.
> {code}
> #ifdef DEBUG
> INK_MD5 md5a;
> INK_MD5 md5b;
> t_state.hdr_info.client_request.url_get()->MD5_get(&md5a);
> t_state.cache_info.lookup_url->MD5_get(&md5b);
> ink_assert(md5a == md5b || t_state.txn_conf->maintain_pristine_host_hdr);
> #endif
> {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-1128) gcc don't like break strict-aliasing in I_ProxyAllocator.h
[
https://issues.apache.org/jira/browse/TS-1128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1128:
--
Fix Version/s: 3.1.4
> gcc don't like break strict-aliasing in I_ProxyAllocator.h
> --
>
> Key: TS-1128
> URL: https://issues.apache.org/jira/browse/TS-1128
> Project: Traffic Server
> Issue Type: Improvement
> Components: Cleanup
>Affects Versions: 3.1.4
>Reporter: Zhao Yongming
>Priority: Minor
> Fix For: 3.1.4
>
>
> {code}
> cc1plus: warnings being treated as errors
> ../../iocore/eventsystem/I_ProxyAllocator.h: In member function 'virtual
> UnixNetVConnection* SSLNetAccept::allocateThread(EThread*)':
> ../../iocore/eventsystem/I_ProxyAllocator.h:54: error: dereferencing pointer
> '' does break strict-aliasing rules
> ../../iocore/eventsystem/I_ProxyAllocator.h:54: note: initialized from here
> cc1plus: warnings being treated as errors
> ../../iocore/eventsystem/I_ProxyAllocator.h: In member function 'virtual
> UnixNetVConnection* UnixNetProcessor::allocateThread(EThread*)':
> ../../iocore/eventsystem/I_ProxyAllocator.h:54: error: dereferencing pointer
> '' does break strict-aliasing rules
> ../../iocore/eventsystem/I_ProxyAllocator.h:54: note: initialized from here
> ../../iocore/eventsystem/I_ProxyAllocator.h: In member function 'virtual
> UnixNetVConnection* SSLNetProcessor::allocateThread(EThread*)':
> ../../iocore/eventsystem/I_ProxyAllocator.h:54: error: dereferencing pointer
> '' does break strict-aliasing rules
> ../../iocore/eventsystem/I_ProxyAllocator.h:54: note: initialized from here
> cc1plus: warnings being treated as errors
> ../../iocore/eventsystem/I_ProxyAllocator.h: In member function 'virtual
> UnixNetVConnection* NetAccept::allocateThread(EThread*)':
> ../../iocore/eventsystem/I_ProxyAllocator.h:54: error: dereferencing pointer
> '' does break strict-aliasing rules
> ../../iocore/eventsystem/I_ProxyAllocator.h:54: note: initialized from here
> make[2]: *** [SSLUnixNet.o] Error 1
> make[2]: *** Waiting for unfinished jobs
> make[2]: *** [UnixNetProcessor.o] Error 1
> mv -f .deps/NetVConnection.Tpo .deps/NetVConnection.Po
> mv -f .deps/Net.Tpo .deps/Net.Po
> mv -f .deps/UDPIOEvent.Tpo .deps/UDPIOEvent.Po
> make[2]: *** [UnixNetAccept.o] Error 1
> mv -f .deps/Connection.Tpo .deps/Connection.Po
> mv -f .deps/SSLCertLookup.Tpo .deps/SSLCertLookup.Po
> mv -f .deps/UnixConnection.Tpo .deps/UnixConnection.Po
> mv -f .deps/SSLConfig.Tpo .deps/SSLConfig.Po
> mv -f .deps/SSLNet.Tpo .deps/SSLNet.Po
> mv -f .deps/UnixNet.Tpo .deps/UnixNet.Po
> mv -f .deps/UnixNetPages.Tpo .deps/UnixNetPages.Po
> mv -f .deps/Socks.Tpo .deps/Socks.Po
> mv -f .deps/SSLNetVConnection.Tpo .deps/SSLNetVConnection.Po
> mv -f .deps/UnixNetVConnection.Tpo .deps/UnixNetVConnection.Po
> make[2]: Leaving directory
> `/root/rpmbuild/BUILD/trafficserver-3.0.2/iocore/net'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/root/rpmbuild/BUILD/trafficserver-3.0.2/iocore'
> make: *** [all-recursive] Error 1
> error: Bad exit status from /var/tmp/rpm-tmp.VFqSxi (%build)
> {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-1153) On Solaris, link with libumem by default
[ https://issues.apache.org/jira/browse/TS-1153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1153: -- Fix Version/s: 3.1.4 > On Solaris, link with libumem by default > > > Key: TS-1153 > URL: https://issues.apache.org/jira/browse/TS-1153 > Project: Traffic Server > Issue Type: Improvement > Components: Performance > Environment: Solaris >Reporter: Igor Galić > Labels: memory > Fix For: 3.1.4 > > > http://developers.sun.com/solaris/articles/multiproc/multiproc.html > Maybe we should make use of that and link to libumem by default. -- 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-1135) support wildcard certificates for ServerNameIndication (SNI)
[ https://issues.apache.org/jira/browse/TS-1135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1135: -- Fix Version/s: 3.1.4 > support wildcard certificates for ServerNameIndication (SNI) > > > Key: TS-1135 > URL: https://issues.apache.org/jira/browse/TS-1135 > Project: Traffic Server > Issue Type: Improvement > Components: SSL >Reporter: James Peach >Assignee: James Peach > Fix For: 3.1.4 > > > The ServerNameIndication support added in TS-472 doesn't handle wildcard > certificates. We need to add certificate parsing support to detect wildcard > certificates and then (if there is not an exact match) choose the certificate > with the longest wildcard 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-1161) insafe raw device in storage.config
[ https://issues.apache.org/jira/browse/TS-1161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1161: -- Fix Version/s: (was: 3.1.4) 3.3.0 Moving to 3.3.0 > insafe raw device in storage.config > --- > > Key: TS-1161 > URL: https://issues.apache.org/jira/browse/TS-1161 > Project: Traffic Server > Issue Type: Bug > Components: Core >Reporter: Zhao Yongming > Fix For: 3.3.0 > > > if you system is on /dev/sda and you put /dev/sda into storage.config, TS > will destroy the data on /dev/sda without any hesitate. > this is proved to be true, please do not try, trust me. -- 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-1121) --disable-diags configuration option does not do anything
[ https://issues.apache.org/jira/browse/TS-1121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1121: -- Fix Version/s: (was: 3.1.4) 3.3.0 Moving to 3.3.0 > --disable-diags configuration option does not do anything > - > > Key: TS-1121 > URL: https://issues.apache.org/jira/browse/TS-1121 > Project: Traffic Server > Issue Type: Bug > Components: Build, Core >Affects Versions: 3.0.3 > Environment: any >Reporter: Uri Shachar >Priority: Minor > Fix For: 3.3.0 > > Original Estimate: 2h > Remaining Estimate: 2h > > The --disable-diags flag sets TS_USE_DIAGS to 0 but Diags.h tests if it is > defined or 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-808) INACTIVE_TIMEOUT for *.channel.facebook.com
[ https://issues.apache.org/jira/browse/TS-808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-808: - Fix Version/s: (was: 3.1.5) 3.3.0 Moving this out to 3.3.0, please move back to 3.1.4 if this will be worked on *soon*. Also, take a look at what can be closed here please! > INACTIVE_TIMEOUT for *.channel.facebook.com > --- > > Key: TS-808 > URL: https://issues.apache.org/jira/browse/TS-808 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Affects Versions: 2.1.8 > Environment: Linux 2.6.35.10 x86_64 >Reporter: Alvin Alexander >Priority: Critical > Fix For: 3.3.0 > > > error.log : > 20110528.13h06m13s CONNECT:[5] could not connect [INACTIVE_TIMEOUT] to > 66.220.151.83 for > 'http://0.164.channel.facebook.com/x/324863553/1802403183/false/p_11790027719=1' > 20110528.13h06m13s CONNECT:[6] could not connect [INACTIVE_TIMEOUT] to > 66.220.151.76 for > 'http://0.122.channel.facebook.com/x/461720327/101899065/false/p_1523748988=22' > 20110528.13h06m13s CONNECT:[3] could not connect [INACTIVE_TIMEOUT] to > 66.220.151.77 for > 'http://0.128.channel.facebook.com/x/2800423340/1779706821/false/p_10277560566=6' -- 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-993) Add OpenBSD support.
[ https://issues.apache.org/jira/browse/TS-993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-993: - Fix Version/s: (was: 3.1.5) 3.3.0 Moving this out to 3.3.0, please move back to 3.1.4 if this will be worked on *soon*. Also, take a look at what can be closed here please! > Add OpenBSD support. > > > Key: TS-993 > URL: https://issues.apache.org/jira/browse/TS-993 > Project: Traffic Server > Issue Type: Improvement > Environment: OpenBSD >Reporter: Piotr Sikora > Fix For: 3.3.0 > > Attachments: 0001-Add-OpenBSD-support.patch > > > Add OpenBSD support. -- 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-1058) Intercept an HTTP client's request
[
https://issues.apache.org/jira/browse/TS-1058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1058:
--
Fix Version/s: (was: 3.1.5)
3.3.0
Moving this out to 3.3.0, please move back to 3.1.4 if this will be worked on
*soon*. Also, take a look at what can be closed here please!
> Intercept an HTTP client's request
> --
>
> Key: TS-1058
> URL: https://issues.apache.org/jira/browse/TS-1058
> Project: Traffic Server
> Issue Type: Bug
> Components: TS API
>Affects Versions: 3.1.1
>Reporter: Yakov Kopel
> Labels: patch
> Fix For: 3.3.0
>
> Attachments: patch.diff
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> I want that the trafficserver will give the client the response instead of
> the server.
> The trafficserver offers the INKHttpTxnIntercept api to do so, but it is not
> so convenience to use it.
> I want to use the regular flow of the trafficserver, and its regular parsing
> commands.
> The trafficserver's plugins examples also aren't using the
> INKHttpTxnIntercept , but they rather using the "rasing error" method, and
> then they response the request at the response hook.
> So, this is whta i did.
> On the global-hook at the TS_EVENT_HTTP_READ_REQUEST_HDR i raised
> TS_EVENT_HTTP_ERROR.
> I also added TS_HTTP_SEND_RESPONSE_HDR_HOOK and there i returned http
> response with the KEEP-ALIVE header.
> The problem is that the trafficserver is closing the connection although i
> added to the response the KEEP-ALIVE header.
>
> When the Trafficserver is trying to send response to the client, it terminate
> the session after it.
> Although I added the "KEEP-ALIVE" mime field - it didn't work.
> The debug dump is looking like this:
> [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http) [4]
> [&HttpSM::state_api_callback, HTTP_API_CONTINUE]
> [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http) [4]
> [&HttpSM::state_api_callout, HTTP_API_CONTINUE]
> [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_redirect)
> [HttpSM::do_redirect]
> [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_redirect)
> [HttpTunnel::deallocate_postdata_copy_buffers]
> [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_tunnel) [4]
> adding producer 'internal msg'
> [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_tunnel) [4]
> adding consumer 'user agent'
> [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_tunnel)
> tunnel_run started, p_arg is NULL
> [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_tunnel) [4]
> consumer_handler [user agent VC_EVENT_WRITE_COMPLETE]
> [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http) [4]
> [&HttpSM::tunnel_handler_ua, VC_EVENT_WRITE_COMPLETE]
> [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_cs) [4] session
> closed
> [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_cs) [4] session
> destroy
> [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http) [4]
> [HttpSM::main_handler, HTTP_TUNNEL_EVENT_DONE]
> [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http) [4]
> [&HttpSM::tunnel_handler, HTTP_TUNNEL_EVENT_DONE]
> [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_redirect)
> [HttpTunnel::deallocate_postdata_copy_buffers]
> [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http) [4] calling
> plugin on hook TS_HTTP_TXN_CLOSE_HOOK at hook 0x3B97610
> The Solution:
> I'm adding a patch of functino that rasing the internal flag of KEEP-ALIVE,
> so the trafficserver will realy believe us that we want to keep this
> connection alive :)
> Example for the usage of the new function:
> // Tell the trafficserver to not close this connection (keep-alive)
> TSHttpTxnCloseAfterResponse(txnp, 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-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: (was: 3.1.5) 3.3.0 Moving this out to 3.3.0, please move back to 3.1.4 if this will be worked on *soon*. Also, take a look at what can be closed here please! > 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.3.0 > > > 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-645) Hard restart in the mgmt APIs is totally busted
[ https://issues.apache.org/jira/browse/TS-645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-645: - Fix Version/s: (was: 3.1.5) 3.3.0 Moving this out to 3.3.0, please move back to 3.1.4 if this will be worked on *soon*. Also, take a look at what can be closed here please! > Hard restart in the mgmt APIs is totally busted > --- > > Key: TS-645 > URL: https://issues.apache.org/jira/browse/TS-645 > Project: Traffic Server > Issue Type: Bug > Components: Management API >Reporter: Leif Hedstrom > Fix For: 3.3.0 > > > In CoreAPIRemote.cc, in HardRestart(), we assume to find some start / stop > scripts that no longer exists: > Layout::relative_to(start_path, sizeof(start_path), Layout::get()->bindir, > "start_traffic_server"); > Layout::relative_to(stop_path, sizeof(stop_path), Layout::get()->bindir, > "stop_traffic_server"); > I don't know if / when this would be used (probably only in the deprecated > Web GUI at this point), but we should fix this. -- 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-998) Broken ClientReq in TSAPI
[ https://issues.apache.org/jira/browse/TS-998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-998: - Fix Version/s: (was: 3.1.5) 3.3.0 Moving this out to 3.3.0, please move back to 3.1.4 if this will be worked on *soon*. Also, take a look at what can be closed here please! > Broken ClientReq in TSAPI > - > > Key: TS-998 > URL: https://issues.apache.org/jira/browse/TS-998 > Project: Traffic Server > Issue Type: Bug >Affects Versions: 3.0.1 > Environment: any >Reporter: Nick Kew >Assignee: Nick Kew > Fix For: 3.3.0 > > > Extracting a Request using TSHttpTxnClientReqGet API yields a bogus Request > line. > Expected behaviour: In a PRE_REMAP hook it should return the client request > line and headers, ideally verbatim. > Observed behaviour: "http://"; is prepended to the request URL: > GET /path/ HTTP/1.1 > becomes > GET http:///path/ HTTP/1.1 > (yes, that's three slashes) > Pseudo-code to reproduce from a PRE_REMAP hook: > TSHttpTxnClientReqGet(txnp, &buf, &hdr); > TSHttpHdrPrint(buf, hdr, iobuf); > reader = TSIOBufferReaderAlloc(iobuf); > block = TSIOBufferReaderStart(reader); > len = TSIOBufferBlockReadAvail(block, reader); > data = TSIOBufferBlockReadStart(block, reader, &len); > Now examine the contents of data. > Assigned to AMC as suggested yesterday on-list. -- 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-767) Make the cluster interface configurable
[ https://issues.apache.org/jira/browse/TS-767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-767: - Fix Version/s: (was: 3.1.5) 3.3.0 Moving this out to 3.3.0, please move back to 3.1.4 if this will be worked on *soon*. Also, take a look at what can be closed here please! > Make the cluster interface configurable > --- > > Key: TS-767 > URL: https://issues.apache.org/jira/browse/TS-767 > Project: Traffic Server > Issue Type: Improvement > Components: Configuration, Network >Affects Versions: 2.1.8 >Reporter: Arno Toell >Priority: Minor > Fix For: 3.3.0 > > > I consider the way how Traffic Server opens listening ports dangerous, or at > least more risky than necessary. Currently ATS allows to configure port > numbers for the related services, but not the listening interface. Instead it > binds to 0.0.0.0. Therefore I'd like to suggest > * -Allow the user to specify a listening interface, don't assume 0.0.0.0 > suits for all setups.- > * -Disable the "autoconfiguration port" (i.e. 8083 by default) unless > proxy.local.cluster.type is set to enable clustering (!= 3). I think > _traffic_shell_ and eventually _traffic_line_ use this port to configure ATS > locally. If so it should be bound to the loop back at least or using Unix > Domain Sockets or whatever local socket method you prefer.- > * Disable the "reliable service port" (i.e. 8088 by default) unless > proxy.local.cluster.type enables clustering. Similar to the > "autoconfiguration port". If _traffic_cop_ (or something else on the local > machine) is using this port, the same suggestions apply as above. > * -The "internal communication port" (8084) should not open a public socket > at all. Instead use Unix Domain Sockets or something similar.- > n.b. striked through issues are obsolete or tracked in TS-765. For the > remaining issue is worth to be added the comment from TS-765: > 8088 is no problem anymore until clustering is enabled, so there is only the > TS-766 improvement left there. However if enabled, I think it is still fairly > useful to allow the user to bind to a specific IP. Say, you run a public > facing proxy in cluster mode where you want to communicate in between on > private IPs between cluster peers. -- 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-920) HTTP CONNECT gives bad request line
[ https://issues.apache.org/jira/browse/TS-920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-920: - Fix Version/s: (was: 3.1.5) 3.3.0 Moving this out to 3.3.0, please move back to 3.1.4 if this will be worked on *soon*. Also, take a look at what can be closed here please! > HTTP CONNECT gives bad request line > --- > > Key: TS-920 > URL: https://issues.apache.org/jira/browse/TS-920 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: M. Nunberg > Fix For: 3.3.0 > > > An HTTP CONNECT tunnel request such as: > CONNECT foo.com:443 HTTP/1.1 > > is translated into: > CONNECT https://foo.com:443/ HTTP/1.1 > > and is sent as such to a parent proxy when ATS is configured to forward > requests to parent proxy. This can break the parent proxy in some (all?) > cases, since the semi-standard for CONNECT is a host specification, not a URI. > In practice, for most applications, this issue is quite rare since it is > often pointless to forward CONNECT requests, unless the parent proxy does > some special handling or man-in-the-middle operations etc. -- 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: (was: 3.1.5) 3.3.0 Moving this out to 3.3.0, please move back to 3.1.4 if this will be worked on *soon*. Also, take a look at what can be closed here please! > 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.3.0 > > > 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-1015) TSEvent is widely declared as int
[ https://issues.apache.org/jira/browse/TS-1015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1015: -- Fix Version/s: (was: 3.1.5) 3.3.0 Moving this out to 3.3.0, please move back to 3.1.4 if this will be worked on *soon*. Also, take a look at what can be closed here please! > TSEvent is widely declared as int > - > > Key: TS-1015 > URL: https://issues.apache.org/jira/browse/TS-1015 > Project: Traffic Server > Issue Type: Bug > Components: Cleanup >Reporter: Nick Kew >Priority: Minor > Fix For: 3.3.0 > > > TSEvent is an enum, defined in ts.h. But in much of the code, TSEvent is > declared as type int. This makes it harder to follow/debug using tools like > *trace or gdb. > This may usefully be fixed as and when people encounter instances 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-1006) memory management, cut down memory waste ?
[
https://issues.apache.org/jira/browse/TS-1006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1006:
--
Fix Version/s: (was: 3.1.5)
3.3.0
Moving this out to 3.3.0, please move back to 3.1.4 if this will be worked on
*soon*. Also, take a look at what can be closed here please!
> memory management, cut down memory waste ?
> --
>
> Key: TS-1006
> URL: https://issues.apache.org/jira/browse/TS-1006
> Project: Traffic Server
> Issue Type: Improvement
> Components: Core
>Affects Versions: 3.1.1
>Reporter: Zhao Yongming
>Assignee: Zhao Yongming
> Fix For: 3.3.0
>
> Attachments: memusage.ods, memusage.ods
>
>
> when we review the memory usage in the production, there is something
> abnormal, ie, looks like TS take much memory than index data + common system
> waste, and here is some memory dump result by set
> "proxy.config.dump_mem_info_frequency"
> 1, the one on a not so busy forwarding system:
> physics memory: 32G
> RAM cache: 22G
> DISK: 6140 GB
> average_object_size 64000
> {code}
> allocated |in-use | type size | free list name
> |||--
> 671088640 | 37748736 |2097152 |
> memory/ioBufAllocator[14]
> 2248146944 | 2135949312 |1048576 |
> memory/ioBufAllocator[13]
> 1711276032 | 1705508864 | 524288 |
> memory/ioBufAllocator[12]
> 1669332992 | 1667760128 | 262144 |
> memory/ioBufAllocator[11]
> 2214592512 | 221184 | 131072 |
> memory/ioBufAllocator[10]
> 2325741568 | 2323775488 | 65536 |
> memory/ioBufAllocator[9]
> 2091909120 | 2089123840 | 32768 |
> memory/ioBufAllocator[8]
> 1956642816 | 1956478976 | 16384 |
> memory/ioBufAllocator[7]
> 2094530560 | 2094071808 | 8192 |
> memory/ioBufAllocator[6]
> 356515840 | 355540992 | 4096 |
> memory/ioBufAllocator[5]
> 1048576 | 14336 | 2048 |
> memory/ioBufAllocator[4]
> 131072 | 0 | 1024 |
> memory/ioBufAllocator[3]
> 65536 | 0 |512 |
> memory/ioBufAllocator[2]
> 32768 | 0 |256 |
> memory/ioBufAllocator[1]
> 16384 | 0 |128 |
> memory/ioBufAllocator[0]
> 0 | 0 |576 |
> memory/ICPRequestCont_allocator
> 0 | 0 |112 |
> memory/ICPPeerReadContAllocator
> 0 | 0 |432 |
> memory/PeerReadDataAllocator
> 0 | 0 | 32 |
> memory/MIMEFieldSDKHandle
> 0 | 0 |240 |
> memory/INKVConnAllocator
> 0 | 0 | 96 |
> memory/INKContAllocator
>4096 | 0 | 32 |
> memory/apiHookAllocator
> 0 | 0 |288 |
> memory/FetchSMAllocator
> 0 | 0 | 80 |
> memory/prefetchLockHandlerAllocator
> 0 | 0 |176 |
> memory/PrefetchBlasterAllocator
> 0 | 0 | 80 |
> memory/prefetchUrlBlaster
> 0 | 0 | 96 | memory/blasterUrlList
> 0 | 0 | 96 |
> memory/prefetchUrlEntryAllocator
> 0 | 0 |128 |
> memory/socksProxyAllocator
> 0 | 0 |144 |
> memory/ObjectReloadCont
> 3258368 | 576016 |592 |
> memory/httpClientSessionAllocator
> 825344 | 139568 |208 |
> memory/httpServerSessionAllocator
>22597632 |1284848 | 9808 | memory/httpSMAllocator
> 0 | 0 | 32 |
> memory/CacheLookupHttpConfigAllocator
> 0 | 0 | 9856 |
> memory/httpUpdateSMAllocator
> 0 | 0 |128 |
> memory/RemapPluginsAlloc
> 0 | 0 | 48 |
> memory/CongestRequestParamAllocator
> 0 | 0 |128 |
> memory/CongestionDBContAllocator
> 5767168 | 704512 | 2048 | memory/hdrStrHeap
>18350080 |1153024 | 2048 | memory/hdrHeap
> 53248 | 2912 |
[jira] [Updated] (TS-1059) prefetch segment fault
[ https://issues.apache.org/jira/browse/TS-1059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1059: -- Fix Version/s: (was: 3.1.5) 3.3.0 Moving this out to 3.3.0, please move back to 3.1.4 if this will be worked on *soon*. Also, take a look at what can be closed here please! > prefetch segment fault > -- > > Key: TS-1059 > URL: https://issues.apache.org/jira/browse/TS-1059 > Project: Traffic Server > Issue Type: Sub-task > Components: HTTP >Affects Versions: 3.0.2 > Environment: linux(ubuntu) >Reporter: yunfei chen > Labels: crash > Fix For: 3.3.0 > > > I encountered a segment faut when I was testing Prefetch module。 > ab -n 1 -c 1 -X 192.168.16.198:8080 -d > http://club.baobao.sohu.com/r-mmbb-3954004-0-29-900.html > configuration in records.config > CONFIG proxy.config.prefetch.prefetch_enabled INT 1 > configuration in prefetch.config > prefetch_children 192.168.16.198 > html_tag img src > #0 0x08124f17 in VIO::reenable (this=0x0) at > ../iocore/eventsystem/P_VIO.h:123 > #1 0x08147fe3 in KeepAliveConn::append (this=0xab9aef20, rdr=0x9c91b794) at > Prefetch.cc:1984 > #2 0x08145fd7 in KeepAliveConnTable::append (this=0xb2393608, ip=16777343, > buf=0x9c91b780, reader=0x9c91b794) at Prefetch.cc:2039 > #3 0x0814679b in KeepAliveLockHandler::handleEvent (this=0xb23e0b30, > event=2, data=0x8ab2f60) at Prefetch.cc:2168 > #4 0x08104ba5 in Continuation::handleEvent (this=0xb23e0b30, event=2, > data=0x8ab2f60) > at ../iocore/eventsystem/I_Continuation.h:146 > #5 0x0830a9f5 in EThread::process_event (this=0xb7396008, e=0x8ab2f60, > calling_code=2) at UnixEThread.cc:140 > #6 0x0830add5 in EThread::execute (this=0xb7396008) at UnixEThread.cc:217 > #7 0x0830900e in spawn_thread_internal (a=0x895eed8) at Thread.cc:88 > #8 0x00165cc9 in start_thread (arg=0xb6f91b70) at pthread_create.c:304 > #9 0x0066f69e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130 > #0 0x08124f17 in VIO::reenable (this=0x0) at > ../iocore/eventsystem/P_VIO.h:123 > #1 0x08147fe3 in KeepAliveConn::append (this=0xa5736888, rdr=0x8d0b2f4) at > Prefetch.cc:1984 > #2 0x08145fd7 in KeepAliveConnTable::append (this=0xb2393608, ip=16777343, > buf=0x8d0b2e0, reader=0x8d0b2f4) at Prefetch.cc:2039 > #3 0x08141db3 in PrefetchUrlBlaster::udpUrlBlaster (this=0x8abd3e0, > event=3300, data=0x0) at Prefetch.cc:885 > #4 0x0813e4ea in PrefetchUrlBlaster::init (this=0x8abd3e0, > list_head=0xabc59ac0, u_proto=TCP_BLAST) at Prefetch.h:280 > #5 0x08147806 in BlasterUrlList::invokeUrlBlaster (this=0xa7c22260) at > Prefetch.h:287 > #6 0x08141ac8 in BlasterUrlList::handleEvent (this=0xa7c22260, event=3302, > data=0xabc59ac0) at Prefetch.cc:803 > #7 0x08143c89 in PrefetchBlaster::handleEvent (this=0xa5739920, event=2, > data=0x0) at Prefetch.cc:1420 > #8 0x08144f42 in PrefetchBlaster::invokeBlaster (this=0xa5739920) at > Prefetch.cc:1769 > #9 0x08143e22 in PrefetchBlaster::handleEvent (this=0xa5739920, event=1102, > data=0xb23cdca0) at Prefetch.cc:1448 > #10 0x08104ba5 in Continuation::handleEvent (this=0xa5739920, event=1102, > data=0xb23cdca0) > at ../iocore/eventsystem/I_Continuation.h:146 > #11 0x082c1abf in CacheVC::callcont (this=0xb23cdca0, event=1102) at > P_CacheInternal.h:629 > #12 0x082c1487 in CacheVC::openReadStartHead (this=0xb23cdca0, event=3900, > e=0x0) at CacheRead.cc:1115 > #13 0x08104ba5 in Continuation::handleEvent (this=0xb23cdca0, event=3900, > data=0x0) at ../iocore/eventsystem/I_Continuation.h:146 > #14 0x082c1431 in CacheVC::openReadStartHead (this=0xb23cdca0, event=2, > e=0x8ab48a0) at CacheRead.cc:1112 > #15 0x08104ba5 in Continuation::handleEvent (this=0xb23cdca0, event=2, > data=0x8ab48a0) > at ../iocore/eventsystem/I_Continuation.h:146 > #16 0x0830a9f5 in EThread::process_event (this=0xb7295008, e=0x8ab48a0, > calling_code=2) at UnixEThread.cc:140 > #17 0x0830add5 in EThread::execute (this=0xb7295008) at UnixEThread.cc:217 > #18 0x0830900e in spawn_thread_internal (a=0x895dd00) at Thread.cc:88 > #19 0x00165cc9 in start_thread (arg=0xb6e90b70) at pthread_create.c:304 > #20 0x0066f69e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130 -- 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-910) log collation in custom log will make dedicate connection to the same collation server
[ https://issues.apache.org/jira/browse/TS-910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-910: - Fix Version/s: (was: 3.1.5) 3.3.0 Moving this out to 3.3.0, please move back to 3.1.4 if this will be worked on *soon*. Also, take a look at what can be closed here please! > log collation in custom log will make dedicate connection to the same > collation server > -- > > Key: TS-910 > URL: https://issues.apache.org/jira/browse/TS-910 > Project: Traffic Server > Issue Type: Bug > Components: Logging >Affects Versions: 3.1.0 >Reporter: Zhao Yongming >Assignee: Zhao Yongming > Fix For: 3.3.0 > > > when you define LogObject in logs_xml.config, and set CollationHosts, it will > open connections for each LogObject, despite you put the same host in > CollationHosts. > it will affect the default squid logging too. -- 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-794) ssl session reuse can not pass sslswamp testing
[
https://issues.apache.org/jira/browse/TS-794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-794:
-
Fix Version/s: (was: 3.1.5)
3.3.0
Moving this out to 3.3.0, please move back to 3.1.4 if this will be worked on
*soon*. Also, take a look at what can be closed here please!
> ssl session reuse can not pass sslswamp testing
> ---
>
> Key: TS-794
> URL: https://issues.apache.org/jira/browse/TS-794
> Project: Traffic Server
> Issue Type: Bug
> Components: SSL
>Affects Versions: 2.1.8
> Environment: sslv3 tlsv1
>Reporter: Zhao Yongming
> Fix For: 3.3.0
>
>
> When I testing from the patches from qianshi, for TS-718, the ssl session
> resumption looks perfect, but still can not pass the sslswamp testing, it
> looks like the second and later request will not be handled from the https
> connection. it may be a issue for https handler, here is some information
> testing from sslswamp:
> {code}
> [root@unknown-10-62-163-x ~]# sslswamp -connect IP:10.32.21.75:443 -num 1
> -count 4 -session srrr -update 10 -request "GET
> https://img02.taobaocdn.com/tps/i2/T1.SVEXcXJ-770-300.jpg
> HTTP/1.0\r\n\r\n" -session_ids -nologo -expect 64000 -sslmeth tlsv1
> No 'cacert' supplied, trying defaults ... '/usr/share/swamp/CA.pem' found.
> no client cert provided, continuing anyway.
> Certificate verification failed, probably a self-signed server cert *or*
> the signing CA cert is not trusted by us (hint: use '-CAfile').
> This message will only be printed once
> session-id[conn:0]:04E7E83CD58E8D566673EDB244146C808ECF7AF517CF39282017E053C7A7D0CC
> session-id[conn:0]:04E7E83CD58E8D566673EDB244146C808ECF7AF517CF39282017E053C7A7D0CC
> 120 seconds since starting, 1 successful, 0 failed, resumes(+1,-0) 0.01
> ops/sec
> 120 seconds since starting, 1 successful, 1 failed, resumes(+1,-0) 0.00
> ops/sec
> 120 seconds since starting, 1 successful, 1 failed, resumes(+1,-0) 0.00
> ops/sec
> session-id[conn:0]:04E7E83CD58E8D566673EDB244146C808ECF7AF517CF39282017E053C7A7D0CC
> 120 seconds since starting, 1 successful, 1 failed, resumes(+2,-0) 0.00
> ops/sec
> 240 seconds since starting, 1 successful, 1 failed, resumes(+2,-0) 0.00
> ops/sec
> 240 seconds since starting, 1 successful, 2 failed, resumes(+2,-0) 0.00
> ops/sec
> 240 seconds since starting, 1 successful, 2 failed, resumes(+2,-0) 0.00
> ops/sec
> session-id[conn:0]:04E7E83CD58E8D566673EDB244146C808ECF7AF517CF39282017E053C7A7D0CC
> 240 seconds since starting, 1 successful, 2 failed, resumes(+3,-0) 0.00
> ops/sec
> 361 seconds since starting, 1 successful, 2 failed, resumes(+3,-0) 0.00
> ops/sec
> 361 seconds since starting, 1 successful, 3 failed, resumes(+3,-0) 0.00
> ops/sec
> {code}
> the log from traffic.out:
> {code}
> [May 20 18:30:59.544] Manager {140339380279072} NOTE:
> [LocalManager::pollMgmtProcessServer] New process connecting fd '10'
> [May 20 18:30:59.544] Manager {140339380279072} NOTE: [Alarms::signalAlarm]
> Server Process born
> [May 20 18:31:00.564] {47816222021376} STATUS: opened
> /var/log/trafficserver/diags.log
> [May 20 18:31:00.613] {47816222021376} NOTE: updated diags config
> [May 20 18:31:00.648] Server {47816222021376} NOTE: cache clustering disabled
> [May 20 18:31:00.784] Server {47816222021376} NOTE: cache clustering disabled
> [May 20 18:31:01.237] Server {47816222021376} DEBUG: (ssl)
> [SSLNetProcessor::initSSLServerCTX] set the callback for external session
> caching.
> [May 20 18:31:01.412] Server {47816222021376} NOTE: logging initialized[7],
> logging_mode = 3
> [May 20 18:31:01.669] Server {47816222021376} NOTE: traffic server running
> [May 20 18:31:01.793] Server {47816237516544} NOTE: cache enabled
> [May 20 18:31:57.001] Server {47816310503168} DEBUG: (ssl)
> [ssl_callback_NewSessionCacheEntry] store id
> [D91C5F59EB43C5E8864303B449B9B1673D3218300EE03FDC4790125A7BCB521D]'s session
> into cache.
> [May 20 18:31:57.001] Server {47816310503168} DEBUG: (ssl)
> SSLNetVConnection::sslServerHandShakeEvent, handshake completed successfully
> [May 20 18:31:57.004] Server {47816310503168} DEBUG: (ssl)
> [SSL_NetVConnection::ssl_read_from_net] b->write_avail()=4096
> [May 20 18:31:57.004] Server {47816310503168} DEBUG: (ssl)
> [SSL_NetVConnection::ssl_read_from_net] rres=82
> SSL Read
> GET https://img02.taobaocdn.com/tps/i2/T1.SVEXcXJ-770-300.jpg HTTP/1.0
> [May 20 18:31:57.004] Server {47816310503168} DEBUG: (ssl)
> [SSL_NetVConnection::ssl_read_from_net] rres=-1
> [May 20 18:31:57.004] Server {47816310503168} DEBUG: (ssl)
> [SSL_NetVConnection::ssl_read_from_net] SSL_ERROR_WOULD_BLOCK
> [May 20 18:31:57.004] Server {47816310503168} DEBUG: (ssl)
> [SSL_NetVConnection::ssl_read_from_net] bytes_read=82
> [May 20 18:31:57.004] Server {4781631050
[jira] [Updated] (TS-718) can not reuse SSL connections on RHEL5/CentOS5
[
https://issues.apache.org/jira/browse/TS-718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-718:
-
Fix Version/s: (was: 3.1.5)
3.3.0
Moving this out to 3.3.0, please move back to 3.1.4 if this will be worked on
*soon*. Also, take a look at what can be closed here please!
> can not reuse SSL connections on RHEL5/CentOS5
> --
>
> Key: TS-718
> URL: https://issues.apache.org/jira/browse/TS-718
> Project: Traffic Server
> Issue Type: Bug
> Components: SSL
>Affects Versions: 2.1.7
> Environment: RHEL5 system with TS 2.1.6 2.1.7
> compared with Apache httpd
>Reporter: Zhao Yongming
>Assignee: qianshi
> Fix For: 3.3.0
>
> Attachments: TS-718-v2.patch, TS-718.patch
>
>
> when with apache httpd default mod_ssl:
> {noformat}
> [root@ts1 httpd]# echo | openssl s_client -reconnect -connect localhost:443
> 2>&1
> CONNECTED(0003)
> depth=0
> /C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ts1.test.cnz.alimama.com/emailAddress=r...@ts1.test.cnz.alimama.com
> verify error:num=18:self signed certificate
> verify return:1
> depth=0
> /C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ts1.test.cnz.alimama.com/emailAddress=r...@ts1.test.cnz.alimama.com
> verify return:1
> ---
> Certificate chain
> 0
> s:/C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ts1.test.cnz.alimama.com/emailAddress=r...@ts1.test.cnz.alimama.com
>
> i:/C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ts1.test.cnz.alimama.com/emailAddress=r...@ts1.test.cnz.alimama.com
> ---
> Server certificate
> -BEGIN CERTIFICATE-
> MIIDSzCCArSgAwIBAgICUWcwDQYJKoZIhvcNAQEFBQAwgcExCzAJBgNVBAYTAi0t
> MRIwEAYDVQQIDAlTb21lU3RhdGUxETAPBgNVBAcMCFNvbWVDaXR5MRkwFwYDVQQK
> DBBTb21lT3JnYW5pemF0aW9uMR8wHQYDVQQLDBZTb21lT3JnYW5pemF0aW9uYWxV
> bml0MSEwHwYDVQQDDBh0czEudGVzdC5jbnouYWxpbWFtYS5jb20xLDAqBgkqhkiG
> 9w0BCQEWHXJvb3RAdHMxLnRlc3QuY256LmFsaW1hbWEuY29tMB4XDTExMDMyNDEw
> Mjk1MVoXDTEyMDMyMzEwMjk1MVowgcExCzAJBgNVBAYTAi0tMRIwEAYDVQQIDAlT
> b21lU3RhdGUxETAPBgNVBAcMCFNvbWVDaXR5MRkwFwYDVQQKDBBTb21lT3JnYW5p
> emF0aW9uMR8wHQYDVQQLDBZTb21lT3JnYW5pemF0aW9uYWxVbml0MSEwHwYDVQQD
> DBh0czEudGVzdC5jbnouYWxpbWFtYS5jb20xLDAqBgkqhkiG9w0BCQEWHXJvb3RA
> dHMxLnRlc3QuY256LmFsaW1hbWEuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB
> iQKBgQDg0xr6MMfTUooenmxTyXiaSiHMfrkbGGhjgE0slP1iWfBf62Qal1daSSb8
> hSSFCZI78RWAp/bcadHGPo43xDWBmohLyTnlWksKKcbSJ9atdijC2L2CJNXiWgKC
> cu+2jOTLAw0YJVOufuJmm8QaqmHl4y3UGE626VDN8lPGBCrQcwIDAQABo1AwTjAd
> BgNVHQ4EFgQUIAfaVLkaRWgWp+zxPtp0bWfbbsgwHwYDVR0jBBgwFoAUIAfaVLka
> RWgWp+zxPtp0bWfbbsgwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQUFAAOBgQA1
> qYMZB0MuCQz2yCAx25C3+UtoZuxdmQxekmOPjtRAm2CRccW7r0ne57BcVU79Qk2s
> 6KTU4fO7lJ1tz49ZkX5zts5WuqsWDSb4cfyDb3ybubcZwUu+eSkqVkx/7GAuVgcl
> weoLXdgpQ779T45SovOR212BXQpYI0piMDNIB9p0mA==
> -END CERTIFICATE-
> subject=/C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ts1.test.cnz.alimama.com/emailAddress=r...@ts1.test.cnz.alimama.com
> issuer=/C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ts1.test.cnz.alimama.com/emailAddress=r...@ts1.test.cnz.alimama.com
> ---
> No client certificate CA names sent
> ---
> SSL handshake has read 1418 bytes and written 319 bytes
> ---
> New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
> Server public key is 1024 bit
> Secure Renegotiation IS supported
> Compression: NONE
> Expansion: NONE
> SSL-Session:
> Protocol : TLSv1
> Cipher: DHE-RSA-AES256-SHA
> Session-ID:
> 8A72957E09AF60AD3807C1D06CE3F9BD88914886B7F1F646B03E8BDA783FAB8B
> Session-ID-ctx:
> Master-Key:
> 42808C5CDF016480F1BC7FF6F764A4886886E430F8E23400D82A9E6A6DE377A30369541E52BA06E1DC878F18DAFC2ECA
> Key-Arg : None
> Krb5 Principal: None
> Start Time: 1300962675
> Timeout : 300 (sec)
> Verify return code: 18 (self signed certificate)
> ---
> drop connection and then reconnect
> CONNECTED(0003)
> ---
> Reused, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
> Secure Renegotiation IS supported
> Compression: zlib compression
> Expansion: zlib compression
> SSL-Session:
> Protocol : TLSv1
> Cipher: DHE-RSA-AES256-SHA
> Session-ID:
> 8A72957E09AF60AD3807C1D06CE3F9BD88914886B7F1F646B03E8BDA783FAB8B
> Session-ID-ctx:
> Master-Key:
> 42808C5CDF016480F1BC7FF6F764A4886886E430F8E23400D82A9E6A6DE377A30369541E52BA06E1DC878F18DAFC2ECA
> Key-Arg : None
> Krb5 Principal: None
>Compression: 1 (zlib compression)
> Start Time: 1300962675
> Timeout : 300 (sec)
> Verify return code: 18 (self signed certificate)
> ---
> drop connection and then reconnect
> CONNECTED(0003)
> ---
> Reused, TLSv1/SSLv3,
[jira] [Updated] (TS-709) proxy.config.output.logfile is not configurable
[ https://issues.apache.org/jira/browse/TS-709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-709: - Fix Version/s: (was: 3.1.5) 3.3.0 Moving this out to 3.3.0, please move back to 3.1.4 if this will be worked on *soon*. Also, take a look at what can be closed here please! > proxy.config.output.logfile is not configurable > --- > > Key: TS-709 > URL: https://issues.apache.org/jira/browse/TS-709 > Project: Traffic Server > Issue Type: Bug > Components: Configuration >Reporter: Igor Galić >Priority: Minor > Fix For: 3.3.0 > > > The code suggests that proxy.config.output.logfile can be set to stdout, > stderr, syslog, diagslog or an arbitrary file (if relative, then relative to > $logdir). > Setting it however, has no effect, the debug output always goes to stderr. -- 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-1019) clean up access to librecords and remove wrappers
[
https://issues.apache.org/jira/browse/TS-1019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1019:
--
Fix Version/s: (was: 3.1.5)
3.3.0
Moving this out to 3.3.0, please move back to 3.1.4 if this will be worked on
*soon*. Also, take a look at what can be closed here please!
> clean up access to librecords and remove wrappers
> -
>
> Key: TS-1019
> URL: https://issues.apache.org/jira/browse/TS-1019
> Project: Traffic Server
> Issue Type: Improvement
> Components: Core
>Reporter: Bryan Call
>Assignee: Igor Galić
>Priority: Minor
> Fix For: 3.3.0
>
>
> There are unneeded define wrappers around the librecord function calls:
> {noformat}
> [bcall@Bryan-Calls-MacBook-Pro-3 traffic.git]$ grep -r REC_ConfigReadInteger
> * | grep define
> iocore/eventsystem/P_EventSystem.h:#define IOCORE_ConfigReadInteger
> REC_ConfigReadInteger
> proxy/http/HttpConfig.h:#define HTTP_ConfigReadInteger
> REC_ConfigReadInteger
> proxy/logging/LogConfig.h:#define LOG_ConfigReadInteger
> REC_ConfigReadInteger
> proxy/logging/LogConfig.h:#define LOG_LocalReadInteger
> REC_ConfigReadInteger
> proxy/Main.h:#define TS_ConfigReadIntegerREC_ConfigReadInteger
> proxy/Prefetch.h:#define TS_ConfigReadIntegerREC_ConfigReadInteger
> proxy/Update.cc:#define UPDATE_ConfigReadInteger REC_ConfigReadInteger
> {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-475) HTTP SM should support efficient byte range requests
[ https://issues.apache.org/jira/browse/TS-475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-475: - Fix Version/s: (was: 3.1.5) 3.3.0 Moving this out to 3.3.0, please move back to 3.1.4 if this will be worked on *soon*. Also, take a look at what can be closed here please! > HTTP SM should support efficient byte range requests > > > Key: TS-475 > URL: https://issues.apache.org/jira/browse/TS-475 > Project: Traffic Server > Issue Type: Bug > Components: Cache, HTTP >Reporter: Leif Hedstrom >Priority: Critical > Fix For: 3.3.0 > > Attachments: diff.out > > > The cache has support for efficiently locate a particular range in the cached > object, but the HTTP SM does not support this. In order to make Range: > request efficient (particularly on large objects), the SM should support this > new cache feature. -- This message is automatically generated by JIRA. 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-1001) reload the changes in dns.resolv_conf
[ https://issues.apache.org/jira/browse/TS-1001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1001: -- Fix Version/s: (was: 3.1.5) 3.3.0 Moving this out to 3.3.0, please move back to 3.1.4 if this will be worked on *soon*. Also, take a look at what can be closed here please! > reload the changes in dns.resolv_conf > - > > Key: TS-1001 > URL: https://issues.apache.org/jira/browse/TS-1001 > Project: Traffic Server > Issue Type: Wish > Components: DNS >Reporter: Conan Wang >Priority: Trivial > Fix For: 3.3.0 > > > a trivial wish: ATS can reload (traffic_line -x) resolv.conf if nameserver > 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-541) SplitDNS cleanup in project HostDBandDNS
[ https://issues.apache.org/jira/browse/TS-541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-541: - Fix Version/s: (was: 3.1.5) 3.3.0 Moving this out to 3.3.0, please move back to 3.1.4 if this will be worked on *soon*. Also, take a look at what can be closed here please! > SplitDNS cleanup in project HostDBandDNS > > > Key: TS-541 > URL: https://issues.apache.org/jira/browse/TS-541 > Project: Traffic Server > Issue Type: Improvement > Components: Cleanup, DNS >Reporter: Zhao Yongming >Priority: Minor > Fix For: 3.3.0 > > Attachments: TS-541.patch > > > as per https://cwiki.apache.org/confluence/display/TS/HostDBandDNS, we will > need to cleanup SplitDNS, make it out of HostDB codes, merge with common dns > processor. this may be another fix for TS-435. -- 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-977) RecCore usage cleanup
[
https://issues.apache.org/jira/browse/TS-977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-977:
-
Fix Version/s: (was: 3.1.5)
3.3.0
Moving this out to 3.3.0, please move back to 3.1.4 if this will be worked on
*soon*. Also, take a look at what can be closed here please!
> RecCore usage cleanup
> -
>
> Key: TS-977
> URL: https://issues.apache.org/jira/browse/TS-977
> Project: Traffic Server
> Issue Type: Task
> Components: Cleanup
>Reporter: Zhao Yongming
>Assignee: Zhao Yongming
>Priority: Minor
> Fix For: 3.3.0
>
>
> in RecCore.*
> {code}
> int RecGetRecordInt(const char *name, RecInt * rec_int, bool lock = true);
> //-
> // RecGetRecordXXX
> //-
> int
> RecGetRecordInt(const char *name, RecInt *rec_int, bool lock)
> {
> int err;
> RecData data;
> if ((err = RecGetRecord_Xmalloc(name, RECD_INT, &data, lock)) ==
> REC_ERR_OKAY)
> *rec_int = data.rec_int;
> return err;
> }
> {code}
> and there is something heavy used:
> {code}
> //-
> // Backwards Compatibility Items (REC_ prefix)
> //-
> #define REC_ReadConfigInt32(_var,_config_var_name) do { \
> RecInt tmp = 0; \
> RecGetRecordInt(_config_var_name, (RecInt*) &tmp); \
> _var = (int32_t)tmp; \
> } while (0)
> #define REC_ReadConfigInteger(_var,_config_var_name) do { \
> RecInt tmp = 0; \
> RecGetRecordInt(_config_var_name, &tmp); \
> _var = tmp; \
> } while (0)
> {code}
> and a real case, the REC_ReadConfigInteger is renamed to
> IOCORE_ReadConfigInteger:
> {code}
> RecInt cache_config_threads_per_disk = 12;
> #define IOCORE_ReadConfigIntegerREC_ReadConfigInteger
> IOCORE_ReadConfigInteger(cache_config_threads_per_disk,
> "proxy.config.cache.threads_per_disk");
> {code}
> my question is, why it is so complex in all these renaming? why not just:
> {code}
> RecGetRecordInt("proxy.config.cache.threads_per_disk",
> &cache_config_threads_per_disk);
> {code}
> brief talk with Leif, we may need to cleanup the use of REC_*. make it a
> small task here
--
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-942) Assert in HttpTransact::HandleCacheOpenReadMiss
[
https://issues.apache.org/jira/browse/TS-942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-942:
-
Fix Version/s: (was: 3.1.5)
3.3.0
Moving this out to 3.3.0, please move back to 3.1.4 if this will be worked on
*soon*. Also, take a look at what can be closed here please!
> Assert in HttpTransact::HandleCacheOpenReadMiss
> ---
>
> Key: TS-942
> URL: https://issues.apache.org/jira/browse/TS-942
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
>Affects Versions: 3.1.1
>Reporter: Leif Hedstrom
>Priority: Critical
> Fix For: 3.3.0
>
>
> I'm seeing a crasher (see below), and it happens in code like this:
> {code}
> if (s->current.server->ip == 0) {
> ink_release_assert(s->current.request_to == PARENT_PROXY ||
> s->http_config_param->no_dns_forward_to_parent != 0);
> if (s->current.request_to == PARENT_PROXY) {
> {code}
> What happens is that .server->ip is indeed 0, but current.request_to is !=
> PARENT_PROXY (it is instead ORIGIN_SERVER). I've not seen this before, and it
> reproduces rarely, so wondering if it could be IPv6 related.
> Crasher:
> {code}
> (gdb) bt
> #0 0x003f2de327f5 in raise (sig=6) at
> ../nptl/sysdeps/unix/sysv/linux/raise.c:64
> #1 0x003f2de33fd5 in abort () at abort.c:92
> #2 0x006407a1 in ink_die_die_die (return_code=,
> message_format=, ap=0x2b0756137600) at ink_error.cc:43
> #3 ink_fatal_va(int, const char *, typedef __va_list_tag __va_list_tag *)
> (return_code=, message_format=,
> ap=0x2b0756137600) at ink_error.cc:65
> #4 0x006408d6 in ink_fatal (return_code=,
> message_format=) at ink_error.cc:73
> #5 0x0063f761 in _ink_assert (a=0x668400 "s->current.request_to ==
> PARENT_PROXY || s->http_config_param->no_dns_forward_to_parent != 0",
> f=, l=2952) at ink_assert.cc:44
> #6 0x00516d5c in HttpTransact::HandleCacheOpenReadMiss
> (s=0x2b0763638018) at HttpTransact.cc:2952
> #7 0x004f08e2 in HttpSM::call_transact_and_set_next_state
> (this=0x2b0763637fb0, f=) at HttpSM.cc:6339
> #8 0x004fffda in HttpSM::handle_api_return (this=0x2b0763637fb0) at
> HttpSM.cc:1520
> #9 0x004f2d42 in HttpSM::state_hostdb_lookup (this= out>, event=, data=) at
> HttpSM.cc:2064
> #10 0x00503de0 in HttpSM::main_handler (this=0x2b0763637fb0,
> event=500, data=0x2b0760231860) at HttpSM.cc:2454
> #11 0x0058d07b in handleEvent (cont=0x2b0763637fb0,
> ar=0x2b0760231860) at ../../iocore/eventsystem/I_Continuation.h:146
> #12 reply_to_cont (cont=0x2b0763637fb0, ar=0x2b0760231860) at HostDB.cc:552
> #13 0x0058e939 in HostDBContinuation::dnsEvent (this= out>, event=, e=) at HostDB.cc:1504
> #14 0x0059d281 in handleEvent (this=0x2a1c340, event= out>, e=) at
> ../../iocore/eventsystem/I_Continuation.h:146
> #15 DNSEntry::postEvent (this=0x2a1c340, event=,
> e=) at DNS.cc:1265
> #16 0x00638204 in handleEvent (this=0x2b0755e36010, e=0x2a61090,
> calling_code=1) at I_Continuation.h:146
> #17 EThread::process_event (this=0x2b0755e36010, e=0x2a61090, calling_code=1)
> at UnixEThread.cc:140
> #18 0x00638c7b in EThread::execute (this=0x2b0755e36010) at
> UnixEThread.cc:189
> #19 0x00637052 in spawn_thread_internal (a=0x1b206b0) at Thread.cc:88
> #20 0x003f2e6068e0 in start_thread (arg=0x2b0756138710) at
> pthread_create.c:297
> #21 0x003f2dee0c9d in clone () at
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
> #22 0x in ?? ()
> (gdb) frame 6
> #6 0x00516d5c in HttpTransact::HandleCacheOpenReadMiss
> (s=0x2b0763638018) at HttpTransact.cc:2952
> 2952s->http_config_param->no_dns_forward_to_parent != 0);
> (gdb) print s->current.request_to
> $1 = ORIGIN_SERVER
> (gdb) print s->current.server->ip
> $2 = 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-228) Solaris 64-bit SunPro long is 64-bit while for g++ 64-bit long is 32-bit, we shoud not use "long" anywhere in TS
[ https://issues.apache.org/jira/browse/TS-228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-228: - Fix Version/s: (was: 3.1.5) 3.3.0 Moving this out to 3.3.0, please move back to 3.1.4 if this will be worked on *soon*. Also, take a look at what can be closed here please! > Solaris 64-bit SunPro long is 64-bit while for g++ 64-bit long is 32-bit, we > shoud not use "long" anywhere in TS > > > Key: TS-228 > URL: https://issues.apache.org/jira/browse/TS-228 > Project: Traffic Server > Issue Type: Bug > Components: Cleanup >Affects Versions: 2.1.0 >Reporter: John Plevyak >Assignee: John Plevyak >Priority: Critical > Fix For: 3.3.0 > > > Solaris 64-bit SunPro long is 64-bit while for g++ 64-bit long is 32-bit. > This is a potential can of worms which at the least is making records.snap > incompatible but at worse could be the cause of other bugs. > In any case we should not be using "long" in the TS code, but instead use > either "int" which is always 32-bits or "inkXXX" of a particular size. -- 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-877) Segfault caused by HTTPInfo::object_key_get
[
https://issues.apache.org/jira/browse/TS-877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-877:
-
Fix Version/s: (was: 3.1.5)
3.3.0
Moving this out to 3.3.0, please move back to 3.1.4 if this will be worked on
*soon*. Also, take a look at what can be closed here please!
> Segfault caused by HTTPInfo::object_key_get
>
>
> Key: TS-877
> URL: https://issues.apache.org/jira/browse/TS-877
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
>Affects Versions: 3.0.0
> Environment: Ubuntu 10.04tls 64bit
>Reporter: Kingsley Foreman
> Labels: crash
> Fix For: 3.3.0
>
>
> Segfault caused by HTTPInfo::object_key_get
> Reading symbols from /usr/lib/libtsutil.so.3...done.
> Loaded symbols for /usr/lib/libtsutil.so.3
> Reading symbols from /lib/libpthread.so.0...(no debugging symbols
> found)...done.
> Loaded symbols for /lib/libpthread.so.0
> Reading symbols from /lib/libnsl.so.1...(no debugging symbols found)...done.
> Loaded symbols for /lib/libnsl.so.1
> Reading symbols from /lib/libresolv.so.2...(no debugging symbols
> found)...done.
> Loaded symbols for /lib/libresolv.so.2
> Reading symbols from /lib/librt.so.1...(no debugging symbols found)...done.
> Loaded symbols for /lib/librt.so.1
> Reading symbols from /lib/libpcre.so.3...(no debugging symbols found)...done.
> Loaded symbols for /lib/libpcre.so.3
> Reading symbols from /lib/libssl.so.0.9.8...(no debugging symbols
> found)...done.
> Loaded symbols for /lib/libssl.so.0.9.8
> Reading symbols from /lib/libcrypto.so.0.9.8...(no debugging symbols
> found)...done.
> Loaded symbols for /lib/libcrypto.so.0.9.8
> Reading symbols from /usr/lib/libtcl8.4.so.0...(no debugging symbols
> found)...done.
> Loaded symbols for /usr/lib/libtcl8.4.so.0
> Reading symbols from /lib/libdl.so.2...(no debugging symbols found)...done.
> Loaded symbols for /lib/libdl.so.2
> Reading symbols from /lib/libexpat.so.1...(no debugging symbols found)...done.
> Loaded symbols for /lib/libexpat.so.1
> Reading symbols from /lib/libz.so.1...(no debugging symbols found)...done.
> Loaded symbols for /lib/libz.so.1
> Reading symbols from /usr/lib/libstdc++.so.6...(no debugging symbols
> found)...done.
> Loaded symbols for /usr/lib/libstdc++.so.6
> Reading symbols from /lib/libm.so.6...(no debugging symbols found)...done.
> Loaded symbols for /lib/libm.so.6
> Reading symbols from /lib/libgcc_s.so.1...(no debugging symbols found)...done.
> Loaded symbols for /lib/libgcc_s.so.1
> Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done.
> Loaded symbols for /lib/libc.so.6
> Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols
> found)...done.
> Loaded symbols for /lib64/ld-linux-x86-64.so.2
> Reading symbols from /lib/libnss_files.so.2...(no debugging symbols
> found)...done.
> Loaded symbols for /lib/libnss_files.so.2
> Reading symbols from /lib/libnss_dns.so.2...(no debugging symbols
> found)...done.
> Loaded symbols for /lib/libnss_dns.so.2
> Reading symbols from /usr/libexec/trafficserver/header_filter.so...done.
> Loaded symbols for /usr/libexec/trafficserver/header_filter.so
> Core was generated by `/usr/bin/traffic_server -M -A,9:X'.
> Program terminated with signal 11, Segmentation fault.
> #0 0x005975ef in HTTPInfo::object_key_get (this=0x2ae710002c58) at
> ../../proxy/hdrs/HTTP.h:1375
> 1375 ((int32_t *) & val)[0] = m_alt->m_object_key[0];
> (gdb) bt
> #0 0x005975ef in HTTPInfo::object_key_get (this=0x2ae710002c58) at
> ../../proxy/hdrs/HTTP.h:1375
> #1 0x00592c72 in HttpTransactCache::SelectFromAlternates
> (cache_vector=0x1c96568, client_request=0x1c96528,
> http_config_params=0x2ae66c4b5228)
> at HttpTransactCache.cc:213
> #2 0x006cb4f1 in CacheVC::openReadChooseWriter (this=0x1c96460,
> event=2, e=0x1e6d6d0) at CacheRead.cc:262
> #3 0x006cbc82 in CacheVC::openReadFromWriter (this=0x1c96460,
> event=2, e=0x1e6d6d0) at CacheRead.cc:332
> #4 0x004e63e8 in Continuation::handleEvent (this=0x1c96460, event=2,
> data=0x1e6d6d0) at ../iocore/eventsystem/I_Continuation.h:146
> #5 0x0072055d in EThread::process_event (this=0x2ae646b46010,
> e=0x1e6d6d0, calling_code=2) at UnixEThread.cc:140
> #6 0x0072090d in EThread::execute (this=0x2ae646b46010) at
> UnixEThread.cc:217
> #7 0x0071ec32 in spawn_thread_internal (a=0x1a14380) at Thread.cc:88
> #8 0x2ae643f639ca in start_thread () from /lib/libpthread.so.0
> #9 0x2ae64616970d in clone () from /lib/libc.so.6
> #10 0x in ?? ()
> (gdb) print *this
> $1 = {m_alt = 0x0}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administ
[jira] [Updated] (TS-346) ATS does not verify server certificate
[ https://issues.apache.org/jira/browse/TS-346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-346: - Fix Version/s: (was: 3.1.5) 3.3.0 Moving this out to 3.3.0, please move back to 3.1.4 if this will be worked on *soon*. Also, take a look at what can be closed here please! > ATS does not verify server certificate > -- > > Key: TS-346 > URL: https://issues.apache.org/jira/browse/TS-346 > Project: Traffic Server > Issue Type: Improvement > Components: SSL >Reporter: vijaya bhaskar mamidi >Assignee: Igor Galić >Priority: Critical > Fix For: 3.3.0 > > > ATS does not verify the certificates correctly. -- 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-1003) prefetch: the config file
[ https://issues.apache.org/jira/browse/TS-1003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1003: -- Fix Version/s: (was: 3.1.5) 3.3.0 Moving this out to 3.3.0, please move back to 3.1.4 if this will be worked on *soon*. Also, take a look at what can be closed here please! > prefetch: the config file > - > > Key: TS-1003 > URL: https://issues.apache.org/jira/browse/TS-1003 > Project: Traffic Server > Issue Type: Sub-task > Components: Configuration >Reporter: Zhao Yongming >Assignee: Zhao Yongming > Fix For: 3.3.0 > > Attachments: TS-1003.patch > > > PreFetch and Update is the most strange plugin that keep in the proxy dir. > and we have some PreFetch API that should make some usage, but the config > file for prefetch and configs not managed live other config files in the > tree. we should make PreFetch a big feature for TS, and smooth all the ugly > coded issue. -- 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-802) Unique KA pools for SOCKS/src IP parameters
[ https://issues.apache.org/jira/browse/TS-802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-802: - Fix Version/s: (was: 3.1.5) 3.3.0 Moving this out to 3.3.0, please move back to 3.1.4 if this will be worked on *soon*. Also, take a look at what can be closed here please! > Unique KA pools for SOCKS/src IP parameters > --- > > Key: TS-802 > URL: https://issues.apache.org/jira/browse/TS-802 > Project: Traffic Server > Issue Type: Wish > Components: HTTP >Reporter: M. Nunberg > Fix For: 3.3.0 > > > From what I've observed, ATS' keepalive/connection cache only indexes by the > OS server or next proxy server, but not by other types of > connection/transport/socket parameters, specifically in my case, negotiated > SOCKS connections and outgoing connections which are bound to a specific > source IP > Is it possible to have such functionality in the near future? Currently I've > been forced to write my own 'KA gateway' which pretends to be an HTTP server > (to which ATS can maintain unique connections) and have that do SOCKS/source > ip bind()ing for me. -- 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-207) [Gsoc2011] FreeBSD: Add raw disk support for the cache
[ https://issues.apache.org/jira/browse/TS-207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-207: - Fix Version/s: (was: 3.1.5) 3.3.0 Moving this out to 3.3.0, please move back to 3.1.4 if this will be worked on *soon*. Also, take a look at what can be closed here please! > [Gsoc2011] FreeBSD: Add raw disk support for the cache > -- > > Key: TS-207 > URL: https://issues.apache.org/jira/browse/TS-207 > Project: Traffic Server > Issue Type: Bug > Components: Cache >Affects Versions: 2.1.0 > Environment: FreeBSD >Reporter: George Paul >Assignee: Dan Mercer > Labels: gsoc2011 > Fix For: 3.3.0 > > > Currently only a file cache is supported on FreeBSD. Raw Disk support should > be added before 2.1 release. > -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-895) Unable to compile trafficserver 3.0.1 with WCCP support on ubuntu lucid (10.04)
[
https://issues.apache.org/jira/browse/TS-895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-895:
-
Fix Version/s: (was: 3.1.5)
3.3.0
Moving this out to 3.3.0, please move back to 3.1.4 if this will be worked on
*soon*. Also, take a look at what can be closed here please!
> Unable to compile trafficserver 3.0.1 with WCCP support on ubuntu lucid
> (10.04)
> ---
>
> Key: TS-895
> URL: https://issues.apache.org/jira/browse/TS-895
> Project: Traffic Server
> Issue Type: Bug
>Affects Versions: 3.0.1
> Environment: Ubuntu lucid (10.04) LTS, 64bit
>Reporter: Brane F. Gračnar
>Assignee: Alan M. Carroll
> Fix For: 3.3.0
>
>
> I'm unable to compile ATS 3.0.1 on my 64bit ubuntu lucid server.
> Configure flags:
> ./configure --prefix=/usr --sysconfdir=/etc/trafficserver --enable-wccp
> --enable-tproxy=auto --with-pic
> make dies with the following error:
> make[2]: Entering directory `/export/tmp/ats/trafficserver-3.0.1/lib/tsconfig'
> /bin/bash ../../build/aux/ylwrap TsConfigGrammar.y y.tab.c TsConfigGrammar.c
> y.tab.h TsConfigGrammar.h y.output TsConfigGrammar.output -- byacc -d -p
> tsconfig
> byacc: e - line 1 of
> "/export/tmp/ats/trafficserver-3.0.1/lib/tsconfig/TsConfigGrammar.y", syntax
> error
> %code top {
> ^
> make[2]: *** [TsConfigGrammar.c] Error 1
> make[2]: Leaving directory `/export/tmp/ats/trafficserver-3.0.1/lib/tsconfig'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/export/tmp/ats/trafficserver-3.0.1/lib'
> make: *** [all-recursive] Error 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-1051) Updating logs_xml.config requires full restart
[
https://issues.apache.org/jira/browse/TS-1051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1051:
--
Fix Version/s: (was: 3.1.5)
3.3.0
Moving this out to 3.3.0, please move back to 3.1.4 if this will be worked on
*soon*. Also, take a look at what can be closed here please!
> Updating logs_xml.config requires full restart
> --
>
> Key: TS-1051
> URL: https://issues.apache.org/jira/browse/TS-1051
> Project: Traffic Server
> Issue Type: Bug
> Components: Logging
>Affects Versions: 3.1.2
>Reporter: Billy Vierra
>Assignee: Zhao Yongming
> Fix For: 3.3.0
>
>
> Using SVN Rev: 1214051
> URL: http://svn.apache.org/repos/asf/trafficserver/traffic/trunk
> upon adding a new LogObject and doing traffic_line -x you get the following
> in traffic.out
> [Dec 14 12:31:48.533] Manager {0x7f2f2abef700} NOTE: User has changed config
> file logs_xml.config
> However it does not go into effect (new log is not created). Upon full
> restart: trafficserver stop, trafficserver start it will add the new log file
> as expected.
> Not sure if it is a bug with docs or in 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-1007) SSN Close called before TXN Close
[ https://issues.apache.org/jira/browse/TS-1007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1007: -- Fix Version/s: (was: 3.1.5) 3.3.0 Moving this out to 3.3.0, please move back to 3.1.4 if this will be worked on *soon*. Also, take a look at what can be closed here please! > SSN Close called before TXN Close > - > > Key: TS-1007 > URL: https://issues.apache.org/jira/browse/TS-1007 > Project: Traffic Server > Issue Type: Bug > Components: TS API >Affects Versions: 3.0.1 >Reporter: Nick Kew >Priority: Critical > Fix For: 3.3.0 > > > Where a plugin implements both SSN_CLOSE_HOOK and TXN_CLOSE_HOOK, the > SSN_CLOSE_HOOK is called first of the two. This messes up normal cleanups! > Details: > Register a SSN_START event globally > In the SSN START, add a TXN_START and a SSN_CLOSE > In the TXN START, add a TXN_CLOSE > Stepping through, I see the order of events actually called, for the simple > case of a one-off HTTP request with no keepalive: > SSN_START > TXN_START > SSN_END > TXN_END > Whoops, SSN_END cleaned up the SSN context, leaving dangling pointers in the > TXN! -- 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: (was: 3.1.5)
3.3.0
Moving this out to 3.3.0, please move back to 3.1.4 if this will be worked on
*soon*. Also, take a look at what can be closed here please!
> 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.3.0
>
>
> {{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-208) OSX: Add raw disk support for the cache
[ https://issues.apache.org/jira/browse/TS-208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-208: - Fix Version/s: (was: 3.1.5) 3.3.0 Moving this out to 3.3.0, please move back to 3.1.4 if this will be worked on *soon*. Also, take a look at what can be closed here please! > OSX: Add raw disk support for the cache > --- > > Key: TS-208 > URL: https://issues.apache.org/jira/browse/TS-208 > Project: Traffic Server > Issue Type: Bug > Components: Cache >Affects Versions: 2.1.0 > Environment: OSX(10.5,10.6) >Reporter: George Paul >Assignee: Dan Mercer > Fix For: 3.3.0 > > > Currently only a file cache is supported on OSX. It would be nice to have Raw > Disk support before 2.1 release. > -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-745) Support ssd
[ https://issues.apache.org/jira/browse/TS-745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-745: - Fix Version/s: (was: 3.1.5) 3.3.0 Moving this out to 3.3.0, please move back to 3.1.4 if this will be worked on *soon*. Also, take a look at what can be closed here please! > Support ssd > --- > > Key: TS-745 > URL: https://issues.apache.org/jira/browse/TS-745 > Project: Traffic Server > Issue Type: New Feature > Components: Cache >Reporter: mohan_zl >Assignee: mohan_zl > Fix For: 3.3.0 > > Attachments: TS-ssd-2.patch, TS-ssd.patch > > > A patch for supporting, not work well for a long time with --enable-debug -- 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-986) ts/experimental has a dependency on netinet/net.h (for struct in_addr)
[ https://issues.apache.org/jira/browse/TS-986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-986: - Fix Version/s: (was: 3.1.5) 3.3.0 Moving this out to 3.3.0, please move back to 3.1.4 if this will be worked on *soon*. Also, take a look at what can be closed here please! > ts/experimental has a dependency on netinet/net.h (for struct in_addr) > -- > > Key: TS-986 > URL: https://issues.apache.org/jira/browse/TS-986 > Project: Traffic Server > Issue Type: Improvement > Components: TS API >Reporter: Leif Hedstrom > Fix For: 3.3.0 > > > Alan seems to indicate this is wrong anyways, but just adding this bug so we > remember it's probably a bad idea. The offending API is > tsapi int TSNodeHandleToIPAddr(TSNodeHandle_t *h, struct in_addr *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-892) request for bulk setting in remap.config for refer filter
[
https://issues.apache.org/jira/browse/TS-892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-892:
-
Fix Version/s: (was: 3.1.5)
3.3.0
Moving this out to 3.3.0, please move back to 3.1.4 if this will be worked on
*soon*. Also, take a look at what can be closed here please!
> request for bulk setting in remap.config for refer filter
> -
>
> Key: TS-892
> URL: https://issues.apache.org/jira/browse/TS-892
> Project: Traffic Server
> Issue Type: Improvement
> Components: Configuration, HTTP
>Affects Versions: 3.1.0
>Reporter: Zhao Yongming
> Labels: remap
> Fix For: 3.3.0
>
>
> when we put our TS online, we find out we are complex when handling squid's
> default filter rule such as:
> {code}
> acl ctoc referer_regex -i XXXa\.com\/ XXXb\.com\/ XXXc\.com\/
> http_access deny ctoc
> {code}
> we have to convert every map rule to map_with_referer, and get very ugly. if
> we can get the referer filter config in the bulk way as IP based filter in
> the remap.config, it will make the config file clear and clean
>
--
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.6)
3.3.0
Moving out to v3.3.0, move back to 3.1.4 if this will be work on *soon*.
> 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.0.0
> Environment: Linux, Debian, Amd64 + GCC 4.6.1
>Reporter: Igor Galić
>Assignee: Igor Galić
> Fix For: 3.3.0
>
> 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-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.6) 3.3.0 Moving out to v3.3.0, move back to 3.1.4 if this will be work on *soon*. > 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 >Affects Versions: 3.0.0 >Reporter: Zhao Yongming >Assignee: Zhao Yongming > Fix For: 3.3.0 > > > 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-1068) we should not wait all the prefetch clients finish
[ https://issues.apache.org/jira/browse/TS-1068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1068: -- Fix Version/s: (was: 3.1.6) 3.3.0 Moving out to v3.3.0, move back to 3.1.4 if this will be work on *soon*. > we should not wait all the prefetch clients finish > -- > > Key: TS-1068 > URL: https://issues.apache.org/jira/browse/TS-1068 > Project: Traffic Server > Issue Type: Sub-task > Components: HTTP >Affects Versions: 3.1.1 >Reporter: Zhao Yongming > Fix For: 3.3.0 > > > when one request is on prefetching, we should not wait for all the prefetch > clients, as there will be minutes or even hours. -- 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.6) 3.3.0 Moving out to v3.3.0, move back to 3.1.4 if this will be work on *soon*. > 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.3.0 > > 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-983) prefetch: the documents
[ https://issues.apache.org/jira/browse/TS-983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-983: - Fix Version/s: (was: 3.1.6) 3.3.0 Moving out to v3.3.0, move back to 3.1.4 if this will be work on *soon*. > prefetch: the documents > --- > > Key: TS-983 > URL: https://issues.apache.org/jira/browse/TS-983 > Project: Traffic Server > Issue Type: Sub-task >Reporter: Zhao Yongming >Assignee: Zhao Yongming > Fix For: 3.3.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-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.6)
3.3.0
Moving out to v3.3.0, move back to 3.1.4 if this will be work on *soon*.
> 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
>Affects Versions: 3.0.0
> Environment: Wherever ATS might run
>Reporter: M. Nunberg
> Fix For: 3.3.0
>
>
> 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) {
> +//Needs to be don
[jira] [Updated] (TS-1063) prefetch resource leak
[
https://issues.apache.org/jira/browse/TS-1063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1063:
--
Fix Version/s: (was: 3.1.6)
3.3.0
Moving out to v3.3.0, move back to 3.1.4 if this will be work on *soon*.
> prefetch resource leak
> ---
>
> Key: TS-1063
> URL: https://issues.apache.org/jira/browse/TS-1063
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
>Affects Versions: 3.0.2
> Environment: linux（ubuntu）
>Reporter: yunfei chen
> Fix For: 3.3.0
>
>
> configuration：
> records.config
>CONFIG proxy.config.prefetch.prefetch_enabled INT 1
>CONFIG proxy.config.prefetch.default_url_proto STRING udp
>CONFIG proxy.config.prefetch.default_data_proto STRING udp
> prefetch.config
>prefetch child
> [Dec 26 10:07:44.129] Server {2964810608} WARNING: too many connections,
> throttling
> [Dec 26 10:17:44.176] Server {2964810608} WARNING: too many connections,
> throttling
> FATAL: ink_memalign: couldn't allocate 524288 bytes at alignment 4096 -
> insufficient memory
> /usr/local/bin/traffic_server - STACK TRACE:
> FATAL: ink_memalign: couldn't allocate 524288 bytes at alignment 4096 -
> insufficient memory
> FATAL: ink_memalign: couldn't allocate 524288 bytes at alignment 4096 -
> insufficient memory
> /usr/local/bin/traffic_server - STACK TRACE:
> /usr/local/bin/traffic_server - STACK TRACE:
> FATAL: ink_memalign: couldn't allocate 524288 bytes at alignment 4096 -
> insufficient memory
> /usr/local/bin/traffic_server - STACK TRACE:
> FATAL: ink_memalign: couldn't allocate 524288 bytes at alignment 4096 -
> insufficient memory
> /usr/local/bin/traffic_server - STACK TRACE:
> terminate called after throwing an instance of 'std::bad_alloc'
> what(): std::bad_alloc
>
>
>
> #0 0x0012e416 in __kernel_vsyscall ()
> #1 0x005c9941 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
> #2 0x005cce42 in abort () at abort.c:92
> #3 0x00520055 in __gnu_cxx::__verbose_terminate_handler() () from
> /usr/lib/libstdc++.so.6
> #4 0x0051df35 in ?? () from /usr/lib/libstdc++.so.6
> #5 0x0051df72 in std::terminate() () from /usr/lib/libstdc++.so.6
> #6 0x0051e0e1 in __cxa_throw () from /usr/lib/libstdc++.so.6
> #7 0x0051e677 in operator new(unsigned int) () from /usr/lib/libstdc++.so.6
> #8 0x0051e74d in operator new[](unsigned int) () from /usr/lib/libstdc++.so.6
> #9 0x081488fd in DynArray::resize (this=0x748ff4c, new_size=64) at
> ../lib/ts/DynArray.h:174
> #10 0x0815d5da in DynArray::operator() (this=0x748ff4c, idx=0) at
> ../lib/ts/DynArray.h:122
> #11 0x0815a9bb in HtmlParser::ScanHtmlForURL (this=0x748ff3c, r=0xbabb3ac0,
> url=0xb70921ec, url_end=0xb70921e8) at Update.cc:1874
> #12 0x0815a86a in HtmlParser::ParseHtml (this=0x748ff3c, r=0xbabb3ac0,
> url=0xb70921ec, url_end=0xb70921e8) at Update.cc:1820
> #13 0x08140816 in PrefetchTransform::parse_data (this=0x748fe88,
> reader=0xbabb3ac0) at Prefetch.cc:543
> #14 0x0813ffe8 in PrefetchTransform::handle_event (this=0x748fe88, event=1,
> edata=0x5991b530) at Prefetch.cc:435
> #15 0x08104ba5 in Continuation::handleEvent (this=0x748fe88, event=1,
> data=0x5991b530)
> at ../iocore/eventsystem/I_Continuation.h:146
> #16 0x0830a9f5 in EThread::process_event (this=0xb7497008, e=0x5991b530,
> calling_code=1) at UnixEThread.cc:140
> #17 0x0830ac38 in EThread::execute (this=0xb7497008) at UnixEThread.cc:189
> #18 0x0830900e in spawn_thread_internal (a=0x895df28) at Thread.cc:88
> #19 0x00165cc9 in start_thread (arg=0xb7092b70) at pthread_create.c:304
> #20 0x0066f69e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130
--
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.6) 3.3.0 Moving out to v3.3.0, move back to 3.1.4 if this will be work on *soon*. > 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.0.0 >Reporter: Zhao Yongming >Assignee: Zhao Yongming >Priority: Minor > Fix For: 3.3.0 > > > 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-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.6) 3.3.0 Moving out to v3.3.0, move back to 3.1.4 if this will be work on *soon*. > 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 >Affects Versions: 3.0.0 > Environment: all >Reporter: John Plevyak >Assignee: John Plevyak > Fix For: 3.3.0 > > 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-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.6) 3.3.0 Moving out to v3.3.0, move back to 3.1.4 if this will be work on *soon*. > 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.3.0 > > > 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-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.6) 3.3.0 Moving out to v3.3.0, move back to 3.1.4 if this will be work on *soon*. > 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: 3.0.0 >Reporter: Zhao Yongming >Assignee: mohan_zl > Fix For: 3.3.0 > > 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.6) 3.3.0 Moving out to v3.3.0, move back to 3.1.4 if this will be work on *soon*. > 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: 3.0.0 >Reporter: Naveen > Labels: api-change, function > Fix For: 3.3.0 > > > 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-725) Crash Report: url_host_set in 2.1.6
[
https://issues.apache.org/jira/browse/TS-725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-725:
-
Fix Version/s: (was: 3.1.6)
3.3.0
Moving out to v3.3.0, move back to 3.1.4 if this will be work on *soon*.
> Crash Report: url_host_set in 2.1.6
> ---
>
> Key: TS-725
> URL: https://issues.apache.org/jira/browse/TS-725
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
>Affects Versions: 2.1.6
>Reporter: Zhao Yongming
> Labels: crash
> Fix For: 3.3.0
>
>
> reported by user:
> {code:none}
> NOTE: Traffic Server received Sig 11: Segmentation fault
> /usr/local/ts/bin/traffic_server - STACK TRACE:
> [0x4001c420]
> /lib/tls/i686/cmov/libc.so.6(memcpy+0x15)[0x404a19b5]
> [0xf]
> /usr/local/ts/bin/traffic_server(url_host_set(HdrHeap*, URLImpl*, char
> const*, int, bool)+0x51)[0x8229631]
> NOTE: Traffic Server received Sig 11: Segmentation fault
> /usr/local/ts/bin/traffic_server - STACK TRACE:
> [0x4001c420]
> /lib/tls/i686/cmov/libc.so.6(memcpy+0x15)[0x404a19b5]
> [0xf]
> /usr/local/ts/bin/traffic_server(url_host_set(HdrHeap*, URLImpl*, char
> const*, int, bool)+0x51)[0x8229631]
> /usr/local/ts/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void
> (*)(HttpTransact::State*))+0xab)[0x816a8eb]
> /usr/local/ts/bin/traffic_server(HttpSM::state_read_client_request_header(int,
> void*)+0x321)[0x817acc1]
> /usr/local/ts/bin/traffic_server(HttpSM::main_handler(int,
> void*)+0x1a4)[0x8184894]
> /usr/local/ts/bin/traffic_server[0x82f880c]
> /usr/local/ts/bin/traffic_server(NetHandler::mainNetEvent(int,
> Event*)+0x4ce)[0x82edffe]
> /usr/local/ts/bin/traffic_server(EThread::process_event(Event*,
> int)+0x1ff)[0x83226bf]
> /usr/local/ts/bin/traffic_server(EThread::execute()+0x449)[0x8322e69]
> /usr/local/ts/bin/traffic_server[0x8321abc]
> /lib/tls/i686/cmov/libpthread.so.0[0x400284fb]
> /lib/tls/i686/cmov/libc.so.6(clone+0x5e)[0x40504e5e]
> /lib/tls/i686/cmov/libc.so.6(clone+0x5e)[0x40504e5e]
> [Mar 8 11:02:52.960] Manager {3080226496} ERROR:
> [LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig
> 11: Segmenta
> tion fault
> [Mar 8 11:02:52.960] Manager {3080226496} ERROR: (last system error 2: No
> such file or directory)
> [Mar 8 11:02:52.961] Manager {3080226496} ERROR: [Alarms::signalAlarm]
> Server Process was reset
> [Mar 8 11:02:52.961] Manager {3080226496} ERROR: (last system error 2: No
> such file or directory)
> [Mar 8 11:02:53.964] Manager {3080226496} NOTE: [LocalManager::startProxy]
> Launching ts process
> [TrafficServer] using root directory '/usr/local/ts'
> [Mar 8 11:02:53.973] Manager {3080226496} NOTE:
> [LocalManager::pollMgmtProcessServer] New process connecting fd '12'
> [Mar 8 11:02:53.973] Manager {3080226496} NOTE: [Alarms::signalAlarm] Server
> Process born
> [Mar 8 11:02:55.015] {1079500240} STATUS: opened
> /usr/local/ts/var/log/trafficserver/diags.log
> [Mar 8 11:02:55.015] {1079500240} NOTE: updated diags config
> [Mar 8 11:02:55.024] Server {1079500240} NOTE: cache clustering disabled
> [Mar 8 11:02:55.069] Server {1079500240} NOTE: cache clustering disabled
> [Mar 8 11:02:55.274] Server {1079500240} STATUS: Rolling disabled for
> /usr/local/ts/var/log/trafficserver/access.log.pipe
> [Mar 8 11:02:55.325] Server {1079500240} NOTE: logging initialized[7],
> logging_mode = 3
> [Mar 8 11:02:55.368] Server {1079500240} NOTE: traffic server running
> [Mar 8 11:02:58.584] Server {1096645520} NOTE: cache enabled
> {code}
--
This message is automatically generated by JIRA.
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.6) 3.3.0 Moving out to v3.3.0, move back to 3.1.4 if this will be work on *soon*. > 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 >Affects Versions: 3.0.0 >Reporter: Manjesh Nilange >Priority: Minor > Fix For: 3.3.0 > > > 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-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.6) 3.3.0 Moving out to v3.3.0, move back to 3.1.4 if this will be work on *soon*. > 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.3.0 > > > 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-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.6)
3.3.0
Moving out to v3.3.0, move back to 3.1.4 if this will be work on *soon*.
> 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: 3.0.0
>Reporter: Mladen Turk
>Assignee: Mladen Turk
>Priority: Minor
> Fix For: 3.3.0
>
>
> 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
