[jira] [Updated] (TS-1130) ink_time_t is 64bit on x86_64
[ https://issues.apache.org/jira/browse/TS-1130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] weijin updated TS-1130: --- Attachment: TS-1130.try2.diff > ink_time_t is 64bit on x86_64 > - > > Key: TS-1130 > URL: https://issues.apache.org/jira/browse/TS-1130 > Project: Traffic Server > Issue Type: Sub-task > Components: Core >Reporter: Zhao Yongming >Assignee: weijin > Fix For: 3.1.4 > > Attachments: TS-1130.diff, TS-1130.try2.diff > > > Weijin: paste your patch here, :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-1213) Crash report: update will crash at HttpTransact::process_quick_http_filter
[
https://issues.apache.org/jira/browse/TS-1213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zhao Yongming updated TS-1213:
--
Component/s: HTTP
Affects Version/s: 3.1.3
> Crash report: update will crash at HttpTransact::process_quick_http_filter
> --
>
> Key: TS-1213
> URL: https://issues.apache.org/jira/browse/TS-1213
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
>Affects Versions: 3.1.3
> Environment: git master with update enabled.
>Reporter: Zhao Yongming
>
> the new ip_allow & quick filter may affect the scheduled update functions:
> {code}
> NOTE: Traffic Server received Sig 11: Segmentation fault
> /opt/ats/bin/traffic_server - STACK TRACE:
> /lib64/libpthread.so.0(+0x10bc0)[0x2ab9e4318bc0]
> /opt/ats/bin/traffic_server(HttpTransact::process_quick_http_filter(HttpTransact::State*,
> int)+0x3b)[0x5501db]
> /opt/ats/bin/traffic_server(HttpTransact::EndRemapRequest(HttpTransact::State*)+0x3a1)[0x55ed91]
> /opt/ats/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void
> (*)(HttpTransact::State*))+0x62)[0x530202]
> /opt/ats/bin/traffic_server(HttpSM::set_next_state()+0x54a)[0x54031a]
> /opt/ats/bin/traffic_server(HttpSM::set_next_state()+0x41c)[0x5401ec]
> /opt/ats/bin/traffic_server(HttpSM::set_next_state()+0x41c)[0x5401ec]
> /opt/ats/bin/traffic_server(HttpSM::state_add_to_list(int,
> void*)+0x18f)[0x53b2df]
> /opt/ats/bin/traffic_server(HttpSM::main_handler(int, void*)+0xe8)[0x53c288]
> /opt/ats/bin/traffic_server(HttpUpdateSM::start_scheduled_update(Continuation*,
> HTTPHdr*)+0x1c7)[0x576d97]
> /opt/ats/bin/traffic_server(UpdateSM::http_scheme(UpdateSM*)+0x197)[0x4fbd77]
> /opt/ats/bin/traffic_server(UpdateSM::HandleSMEvent(int,
> Event*)+0x378)[0x4f7198]
> /opt/ats/bin/traffic_server(EThread::process_event(Event*,
> int)+0x90)[0x6b0250]
> /opt/ats/bin/traffic_server(EThread::execute()+0x5eb)[0x6b0e0b]
> /opt/ats/bin/traffic_server[0x6af042]
> /lib64/libpthread.so.0(+0x8e2c)[0x2ab9e4310e2c]
> /lib64/libc.so.6(clone+0x6d)[0x2ab9e6beb35d]
> {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-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
> M
[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-990) IPv6 support for clustering
[ https://issues.apache.org/jira/browse/TS-990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-990: --- Fix Version/s: (was: 3.1.4) 3.2.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.2.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-1208) check_memory() in traffic_cop never active on linux
[ https://issues.apache.org/jira/browse/TS-1208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zhao Yongming updated TS-1208: -- Attachment: TS-1208.patch also cleanup some unused variables|defines > check_memory() in traffic_cop never active on linux > --- > > Key: TS-1208 > URL: https://issues.apache.org/jira/browse/TS-1208 > Project: Traffic Server > Issue Type: Bug > Components: Management >Affects Versions: 3.1.3 >Reporter: Zhao Yongming >Assignee: Zhao Yongming > Fix For: 3.1.4 > > Attachments: TS-1208.patch > > > check_memory() will check system memory usage to prevent OOM. and it is still > on linux v2.2 codes. -- 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-1208) check_memory() in traffic_cop never active on linux
[ https://issues.apache.org/jira/browse/TS-1208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zhao Yongming updated TS-1208: -- Affects Version/s: 3.1.3 Fix Version/s: 3.1.4 > check_memory() in traffic_cop never active on linux > --- > > Key: TS-1208 > URL: https://issues.apache.org/jira/browse/TS-1208 > Project: Traffic Server > Issue Type: Bug > Components: Management >Affects Versions: 3.1.3 >Reporter: Zhao Yongming >Assignee: Zhao Yongming > Fix For: 3.1.4 > > > check_memory() will check system memory usage to prevent OOM. and it is still > on linux v2.2 codes. -- 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-1070) replace and deprecate TSFetchURL()
[
https://issues.apache.org/jira/browse/TS-1070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach updated TS-1070:
Fix Version/s: (was: 3.1.4)
3.3.0
Out of time for 3.2 release; punt to 3.3.
> replace and deprecate TSFetchURL()
> --
>
> Key: TS-1070
> URL: https://issues.apache.org/jira/browse/TS-1070
> Project: Traffic Server
> Issue Type: Improvement
> Components: TS API
>Reporter: James Peach
>Assignee: James Peach
>Priority: Minor
> Fix For: 3.3.0
>
>
> TSFetchURL() has a number of shortcomings:
> 1. it's not cancellable
> 2. the event delivery is bizarre
> 3. it doesn't play nicely with the TSHttpHdr*() API.
> I propose the following API changes:
> typedef enum
> {
> ...
> TS_EVENT_FETCH_SUCCESS,
> TS_EVENT_FETCH_FAILURE
> } TSEvent;
> TSAction TSFetchResource(TSCont, TSMBuffer, TSLoc, const sockaddr *,
> TSFetchWakeUpOptions);
> TSFetchResource() takes a TSMBuffer/TSLoc pair that must contain the HTTP and
> MIME headers. If the HTTP method in the HTTP header is not GET, and a error
> will be reported.
> The continuation callback will be invoked with either TS_EVENT_FETCH_SUCCESS
> or TS_EVENT_FETCH_SUCCESS. For TS_EVENT_FETCH_SUCCESS, the edata pointer will
> be a HttpTxn pointer suitable for call TSFetchRespGet() or TSFetchHdrGet().
> For TS_EVENT_FETCH_FAILURE, I'd like to arrange a way to get the HTTP error
> code. Hopefully there is some existing precedent to follow.
> TSFetchResource() should be cancellable via the TSAction return value.
> I'm not sure whether TSFetchWakeUpOptions is really necessary, but if we
> eliminate this, I'd argue for a uint64_t flags parameter.
--
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-1062) TSFetchUrl doesn't handle chunked encoding
[ https://issues.apache.org/jira/browse/TS-1062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-1062: Fix Version/s: (was: 3.1.4) 3.2.0 Not a regression; push out to 3.2. > TSFetchUrl doesn't handle chunked encoding > -- > > Key: TS-1062 > URL: https://issues.apache.org/jira/browse/TS-1062 > Project: Traffic Server > Issue Type: Bug > Components: TS API >Reporter: James Peach >Assignee: James Peach > Fix For: 3.2.0 > > > If you use TSFetchUrl() to fetch a resource and the response comes back with > chunked encoding, you are basically hosed. The caller never gets the SUCCESS > event because FetchSM does not know how to decode the body. There's no > content-length header and the origin server doesn't drop the TCP connection, > so we just sit there waiting for the response to finish forever (well until > the origin server drops the connection 10s later). -- 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-1202) install traffic_shell man/doc pages in a more appropriate location
[ https://issues.apache.org/jira/browse/TS-1202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Brezac updated TS-1202: Attachment: doc.patch > install traffic_shell man/doc pages in a more appropriate location > -- > > Key: TS-1202 > URL: https://issues.apache.org/jira/browse/TS-1202 > Project: Traffic Server > Issue Type: Improvement >Affects Versions: 3.1.4 >Reporter: Igor Brezac >Priority: Minor > Fix For: 3.1.4 > > Attachments: doc.patch > > -- 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-1201) Crash report: hostdb multicache, double free
[
https://issues.apache.org/jira/browse/TS-1201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zhao Yongming updated TS-1201:
--
Description:
{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}
was:
{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(_ZN14MultiCacheSync7mcEventEiP5Event+0xa4)[0x5dae04]
/usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x22f)[0x691c8f]
/usr/bin/traffic_server(_ZN7EThread7executeEv+0x6a1)[0x692681]
/usr/bin/traffic_server[0x69115e]
/lib64/libpthread.so.0[0x3db280673d]
/lib64/libc.so.6(clone+0x6d)[0x3db20d44bd]
=== Memory map:
{code}
> 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
>
> {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-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-207) [GSoC] 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 ] Igor Galić updated TS-207: -- Description: Currently only a file cache is supported on FreeBSD. Raw Disk support should be added before 3.3 release. -George was: Currently only a file cache is supported on FreeBSD. Raw Disk support should be added before 2.1 release. -George Affects Version/s: 3.1.3 3.0.3 > [GSoC] 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: 3.1.3, 3.0.3, 2.1.0 > Environment: FreeBSD >Reporter: George Paul >Assignee: Dan Mercer > Labels: freebsd, gsoc > Fix For: 3.3.0 > > > Currently only a file cache is supported on FreeBSD. Raw Disk support should > be added before 3.3 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-207) [GSoC] 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 ] Igor Galić updated TS-207: -- Summary: [GSoC] FreeBSD: Add raw disk support for the cache (was: [Gsoc2011] FreeBSD: Add raw disk support for the cache) > [GSoC] 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: 3.1.3, 3.0.3, 2.1.0 > Environment: FreeBSD >Reporter: George Paul >Assignee: Dan Mercer > Labels: freebsd, gsoc > 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-1116) Fix build issues with clang (particularly on OSX)
[ https://issues.apache.org/jira/browse/TS-1116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić updated TS-1116: --- Affects Version/s: 3.0.4 3.0.3 Backport to Version: 3.0.5 > Fix build issues with clang (particularly on OSX) > - > > Key: TS-1116 > URL: https://issues.apache.org/jira/browse/TS-1116 > Project: Traffic Server > Issue Type: Improvement >Affects Versions: 3.0.4, 3.0.3 >Reporter: Leif Hedstrom >Assignee: Igor Galić > Fix For: 3.1.3 > > Attachments: TS-1116.diff > > > We should get it to compile with clang again, specially since on OSX, clang > is the 'future'. -- 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
]
Jan-Frode Myklebust updated TS-1185:
Attachment: trafficserver-gcc47.patch
patch for adding these commits to v3.0.4:
9e3459a1006ad2e4381d20fe5374a11994dccf88
TS-1116 fix clang warnings and errors, especially with make check
cea3c71360a066a24b39e36ee116e83ea1db1bc8
TS-1116 fix clang warnings
> 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
>
> Attachments: trafficserver-gcc47.patch
>
>
> 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-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-1197) Build fails when building outside the source tree
[ https://issues.apache.org/jira/browse/TS-1197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yossi Gottlieb updated TS-1197: --- Attachment: ats_build_fix.diff > Build fails when building outside the source tree > - > > Key: TS-1197 > URL: https://issues.apache.org/jira/browse/TS-1197 > Project: Traffic Server > Issue Type: Bug > Components: Build >Affects Versions: 3.1.3 >Reporter: Yossi Gottlieb >Priority: Minor > Fix For: 3.1.4 > > Attachments: ats_build_fix.diff > > > Currently some Makefiles assume $(builddir) == $(srcdir), which is an > incorrect assumption. -- 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-1130) ink_time_t is 64bit on x86_64
[ https://issues.apache.org/jira/browse/TS-1130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] weijin updated TS-1130: --- Attachment: TS-1130.diff time_t in x86_64 is 64 bit. If we use the 64 bit atomic operation on time_t variables. > ink_time_t is 64bit on x86_64 > - > > Key: TS-1130 > URL: https://issues.apache.org/jira/browse/TS-1130 > Project: Traffic Server > Issue Type: Sub-task > Components: Core >Reporter: Zhao Yongming >Assignee: weijin > Fix For: 3.1.4 > > Attachments: TS-1130.diff > > > Weijin: paste your patch here, :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-1079) Add an API function to turn debugging on for specific transactions/sessions
[ https://issues.apache.org/jira/browse/TS-1079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uri Shachar updated TS-1079: Attachment: benchmarks.tgz Uploaded benchmark results tarball > Add an API function to turn debugging on for specific transactions/sessions > --- > > Key: TS-1079 > URL: https://issues.apache.org/jira/browse/TS-1079 > Project: Traffic Server > Issue Type: Improvement > Components: Core, HTTP >Reporter: Uri Shachar >Assignee: Leif Hedstrom >Priority: Minor > Fix For: 3.1.4 > > Attachments: benchmarks.tgz, debug_specific.patch, > debug_specific_2.patch, debug_specific_3.patch, debug_specific_4.patch > > Original Estimate: 72h > Remaining Estimate: 72h > > When attempting to troubleshoot issues on a production ATS system, it > is often impossible/difficult to turn on any of the 'high-volume' debug tags > like http due to the performance impact. > > This enhancement allows a plugin to set a debug flag for a specific txn/ssn, > and replaces some of the internal Debug calls with a new function that checks > if the flag is turned on, and outputs the debug line regardless of the tag if > it is (The diags enable/disable flag is still taken into account). > The API will also have TSDebugSpecific in order to allow plugins to use the > same functionality. > In addition, we might consider adding an internal config file (remap-like) to > allow turning this flag on without plugin intervention. > -- 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-1075) Port range bottleneck in transparent proxy mode
[ https://issues.apache.org/jira/browse/TS-1075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] B Wyatt updated TS-1075: Fix Version/s: (was: 3.1.4) 3.3.0 > Port range bottleneck in transparent proxy mode > --- > > Key: TS-1075 > URL: https://issues.apache.org/jira/browse/TS-1075 > Project: Traffic Server > Issue Type: Bug > Components: Core >Affects Versions: 3.0.1 > Environment: Centos 5.6, kernel 2.6.39.2 compiled with TPROXY support > ATS compiled as: ./configure --enable-tproxy >Reporter: Danny Shporer >Assignee: B Wyatt > Fix For: 3.3.0 > > Attachments: ports.patch > > > The Linux TPROXY stack only takes into account the local addresses when using > dynamic bind (bind without specifying a specific port). This limits the port > range to only the local range (around 30K by default and can be extended to > around 64K) - this together with the TIME-WAIT Linux method of releasing > ports causes a bottleneck). > One symptom of this is that traffic_cop cannot open a connection to the > server to monitor it (it gets error 99 - address already in use) and kills > it. > Another issue is when opening the connection to the server. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1163) Raw disks with more than (2^32)-1 sectors (usually 2TB) are not supported on linux
[ https://issues.apache.org/jira/browse/TS-1163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] B Wyatt updated TS-1163: Fix Version/s: (was: 3.1.4) 3.3.0 > Raw disks with more than (2^32)-1 sectors (usually 2TB) are not supported on > linux > -- > > Key: TS-1163 > URL: https://issues.apache.org/jira/browse/TS-1163 > Project: Traffic Server > Issue Type: Bug > Components: Cache >Reporter: B Wyatt >Assignee: B Wyatt > Fix For: 3.3.0 > > Attachments: blkgetsize64.bwyatt.patch > > > Due to 32bit integers in both the trafficersever code and the ioctl used to > determine raw disk size, the number of sectors reported to the cache storage > system is bound to 0-0x. If a disk has 512 byte sectors and is > larger than 2TB it will report (num_sectors % 0x) * 512 bytes > avaliable. -- 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-1090) Configuration and plugin support for SO_MARK (on supporting platforms)
[ https://issues.apache.org/jira/browse/TS-1090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] B Wyatt updated TS-1090: Fix Version/s: (was: 3.1.4) 3.3.0 > Configuration and plugin support for SO_MARK (on supporting platforms) > -- > > Key: TS-1090 > URL: https://issues.apache.org/jira/browse/TS-1090 > Project: Traffic Server > Issue Type: New Feature > Components: HTTP, Network, TS API >Reporter: B Wyatt >Assignee: B Wyatt > Fix For: 3.3.0 > > Attachments: so_mark.patch > > > SO_MARK allows for all packets sent out via a given socket to be pre-marked > (similar to the -j MARK target in iptables, or the fwmark semantic in ip > rules). This feature allows configuration to dictate SO_MARKs for accepting > sockets, cluster sockets and origin server sockets independently. > Additionally, plugins and internal systems can set per-transaction SO_MARKS > for outgoing packets. -- 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-1087) TSHttpTxnOutgoingAddrSet forward declaration does not match implementation
[
https://issues.apache.org/jira/browse/TS-1087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
B Wyatt updated TS-1087:
Fix Version/s: (was: 3.1.4)
3.3.0
> TSHttpTxnOutgoingAddrSet forward declaration does not match implementation
> --
>
> Key: TS-1087
> URL: https://issues.apache.org/jira/browse/TS-1087
> Project: Traffic Server
> Issue Type: Bug
> Components: TS API
>Affects Versions: 3.1.0
>Reporter: B Wyatt
>Assignee: B Wyatt
>Priority: Trivial
> Fix For: 3.3.0
>
> Attachments: txn-outgoing-addr.patch
>
> Original Estimate: 1m
> Remaining Estimate: 1m
>
> ts.h.in lists the following declaration:
> {code}TSReturnCode TSHttpTxnOutgoingAddrSet(TSHttpTxn txnp, struct sockaddr
> const* addr);{code}
> However, the current implementation has this function sig:
> {code}tsapi TSReturnCode TSHttpTxnOutgoingAddrSet(TSHttpTxn txnp, struct
> sockaddr const* addr, socklen_t addrlen);{code}
> Trafficserver is unable to load plugins which use this function due to the
> unresolved symbol.
--
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-980) change client_session schedule from global to thread local, and reduce the try_locks in UnixNetVConnection::reenable
[
https://issues.apache.org/jira/browse/TS-980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zhao Yongming updated TS-980:
-
Fix Version/s: (was: 3.1.4)
3.3.0
reschedule to 3.3.0, may need more tweak & testing
> change client_session schedule from global to thread local, and reduce the
> try_locks in UnixNetVConnection::reenable
> -
>
> Key: TS-980
> URL: https://issues.apache.org/jira/browse/TS-980
> Project: Traffic Server
> Issue Type: Improvement
> Components: Network, Performance
>Affects Versions: 3.1.0, 3.0.0
> Environment: all
>Reporter: weijin
>Assignee: weijin
> Fix For: 3.3.0
>
> Attachments: ts-980.diff
>
>
> I did some performance test on ats last days(disable cache, set share_server
> session 2, pure proxy mode), I did see significant improvement on low load,
> but it dropped rapidly when load is high. meanwhile, some stability problems
> happened. Through gdb, I found the client_session`s mutex can be acquired by
> two or more threads, I believe some schedules happened during the sm
> life_time. May be we need do some work to find these eventProcessor.schedules
> and change them to thread schedules.
> UnixVConnecton::reenable {
> if (nh->mutex->thread_holding == t) {
> // put into ready_list
> } else {
>MUTEX_TRY_LOCK(lock, nh->mutex, t);
>if (!lock) {
> // put into enable_list;
>} else {
> // put into ready_list;
>}
> }
> remove UnixNetVConnection::reenable try_lock operations, 3 reasons
> 1. try_lock operation means obj allocation and deallocation operation.
> frequently
> 2. try_lock hardly can lock the net-handler`s mutex.(net-handler is schedule
> by as soon as possible)
> 3. try_lock should not acquire the net-handler`s mutex. That may lead more
> net io latency if it is an epoll event need to be processed in other threads.
> If it is not an epoll event(time event), I don`t think putting vc in
> ready_list has any advantage than in enable_list.
> may be we can change reenale function like this:
> UnixVConnecton::reenable {
> if (nh->mutex->thread_holding == t) {
> // put into ready_list;
> } else {
> // put into enable_list;
> }
> my buddies, any advice?
--
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-1193) Traffic Server building on OpenBSD
[ https://issues.apache.org/jira/browse/TS-1193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Geffon updated TS-1193: - Affects Version/s: 3.1.3 > Traffic Server building on OpenBSD > -- > > Key: TS-1193 > URL: https://issues.apache.org/jira/browse/TS-1193 > Project: Traffic Server > Issue Type: Improvement >Affects Versions: 3.1.3 >Reporter: Brian Geffon >Assignee: Brian Geffon > > This is a parent issue for the task of getting traffic server building on > OpenBSD. -- 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-899) ts crash
[ https://issues.apache.org/jira/browse/TS-899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zhao Yongming updated TS-899: - Fix Version/s: (was: 3.1.4) 3.3.0 > ts crash > > > Key: TS-899 > URL: https://issues.apache.org/jira/browse/TS-899 > Project: Traffic Server > Issue Type: Sub-task > Components: HTTP, MIME >Affects Versions: 3.0.1 > Environment: readhat5.5, ts-3.0.1, X86-64 >Reporter: weijin >Assignee: weijin > Fix For: 3.3.0 > > > If a request url is forbidden then redirected to another url, TS crash. -- 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-1054) TSFetchUrl takes an address but does the DNS lookup anyway
[
https://issues.apache.org/jira/browse/TS-1054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach updated TS-1054:
Fix Version/s: (was: 3.1.4)
3.3.0
I won't have time to investigate for 3.2. Move out to 3.3.
> TSFetchUrl takes an address but does the DNS lookup anyway
> --
>
> Key: TS-1054
> URL: https://issues.apache.org/jira/browse/TS-1054
> Project: Traffic Server
> Issue Type: Bug
> Components: Performance
>Affects Versions: 3.0.2
>Reporter: James Peach
>Assignee: James Peach
>Priority: Minor
> Fix For: 3.3.0
>
>
> TSFetchUrl() takes an IP address as one of its arguments, so the API client
> has to resolve the hostname portion of any URL it wants to fetch. However
> once you get into the HTTP state machine, the host gets resolved again. One
> of these DNS queries is redundant for performance reasons. Additionally, the
> plugin might have some special knowledge about which IP address to use that
> the DNS resolver doesn't, in which case the result would be wrong.
> [Dec 14 20:36:29.414] Server {0x7fff7b5f9960} DIAG: (plugin) [1] http request
> (90 of 90 bytes):
> GET http://www.iana.org//_css/2011.1/fonts/OpenSans-SemiBold.ttf HTTP/1.1
> accept: */*
> [Dec 14 20:36:29.415] Server {0x7fff7b5f9960} DEBUG: (FetchSM) [init] FetchSM
> initialized for request with headers
> --
> GET http://www.iana.org//_css/2011.1/fonts/OpenSans-SemiBold.ttf HTTP/1.1
> accept: */*
> --
> [Dec 14 20:36:29.424] Server {0x7fff7b5f9960} DEBUG: (FetchSM) [httpConnect]
> calling httpconnect write
> [Dec 14 20:36:29.424] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Created
> PluginVCCore at 0x102872c00, active 0x102872c38, passive 0x102872e10
> [Dec 14 20:36:29.424] Server {0x7fff7b5f9960} DEBUG: (http_seq)
> HttpAccept:mainEvent] accepted connection
> [Dec 14 20:36:29.425] Server {0x7fff7b5f9960} DEBUG: (http_cs) [0] session
> born, netvc 0x102872e10
> [Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (http_cs) [0] using
> accept inactivity timeout [120 seconds]
> [Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (http_cs) [0] Starting
> transaction 1 using sm [0]
> [Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Passive:
> do_io_read for 0 bytes
> [Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Passive:
> do_io_read for -1 bytes
> [Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Active:
> do_io_read for -1 bytes
> [Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Active:
> do_io_write for 90 bytes
> [Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc_event) [0] Passive:
> Received event 1
> [Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Passive:
> process_read_side
> [Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Passive:
> process_read_side; act_on 0
> [Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Passive:
> closed? 0 shutdown? 0
> [Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc_event) [0] Active:
> Received event 1
> [Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Active:
> process_read_side
> [Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Active:
> process_read_side; act_on 0
> [Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Active:
> closed? 0 shutdown? 0
> [Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Active:
> process_write_side
> [Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Active:
> process_write_side; act_on 90
> [Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Active:
> process_write_side; added 90
> [Dec 14 20:36:29.437] Server {0x7fff7b5f9960} DEBUG: (FetchSM)
> [fetch_handler] calling fetch_plugin
> [Dec 14 20:36:29.437] Server {0x7fff7b5f9960} DEBUG: (FetchSM)
> [process_fetch_write] calling process write
> [Dec 14 20:36:29.437] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Passive:
> process_read_side
> [Dec 14 20:36:29.437] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Passive:
> process_read_side; act_on 90
> [Dec 14 20:36:29.437] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Passive:
> process_read_side; added 90
> [Dec 14 20:36:29.437] Server {0x7fff7b5f9960} DEBUG: (http) [0]
> [HttpSM::main_handler, VC_EVENT_READ_READY]
> [Dec 14 20:36:29.437] Server {0x7fff7b5f9960} DEBUG: (http) [0]
> [&HttpSM::state_read_client_request_header, VC_EVENT_READ_READY]
> [Dec 14 20:36:29.437] Server {0x7fff7b5f9960} DEBUG: (http) [0] do
[jira] [Updated] (TS-1085) traffic_shell enable command doesn't work
[ https://issues.apache.org/jira/browse/TS-1085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-1085: Fix Version/s: (was: 3.1.4) 3.3.0 Maybe we will fix this by removing traffic_shell in 3.3. > traffic_shell enable command doesn't work > - > > Key: TS-1085 > URL: https://issues.apache.org/jira/browse/TS-1085 > Project: Traffic Server > Issue Type: Bug > Components: Management >Reporter: James Peach >Assignee: James Peach > Fix For: 3.3.0 > > > Let's try this as root: > blacko:trafficserver.git jpeach$ sudo /opt/ats/bin/traffic_shell > Successfully Initialized MgmtAPI in /opt/ats/var/trafficserver > % trafficserver> enable > Already Enabled > trafficserver> exit > Ok, to let's try as non-root: > blacko:trafficserver.git jpeach$ /opt/ats/bin/traffic_shell > [connect] ERROR (main_socket_fd 3): Permission denied > TSInit 5: Failed to initialize MgmtAPI in /opt/ats/var/trafficserver > [connect] ERROR (main_socket_fd 3): Permission denied > % trafficserver> enable > FATAL: ConfigCmd.cc:137: failed assert `enable_restricted_commands` > /opt/ats/bin/traffic_shell - STACK TRACE: > 0 libtsutil.3.dylib 0x00010cec8b8b ink_fatal_va + 283 > 1 libtsutil.3.dylib 0x00010cec8e94 ink_fatal + 356 > 2 libtsutil.3.dylib 0x00010cec66ff _ink_assert + 271 > 3 traffic_shell 0x00010ce253ab > _Z10Cmd_EnablePvP10Tcl_InterpiPPKc + 395 > 4 Tcl 0x00010cf34261 > TclInvokeStringCommand + 121 > 5 Tcl 0x00010cf360b7 > Tcl_GetMathFuncInfo + 2533 > 6 Tcl 0x00010cf36d14 > Tcl_GetMathFuncInfo + 5698 > 7 Tcl 0x00010cf370d2 Tcl_Eval + 42 > So either enable does nothing or it crashes. Seems like we should fix or > remove 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-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-703) cannot find server response 502 :( plz help me!!
[ https://issues.apache.org/jira/browse/TS-703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-703: -- Backport to Version: (was: 3.3.0) Fix Version/s: 3.3.0 > cannot find server response 502 :( plz help me!! > > > Key: TS-703 > URL: https://issues.apache.org/jira/browse/TS-703 > Project: Traffic Server > Issue Type: Test >Reporter: KenYun > Fix For: 3.3.0 > > > Finally, I installed ASF with a rpm vesrsion but I faced with the other > problem as you see just under. > I will really appreciate if you could help me :) > This just under is a message after I put ' curl -v http://localhost/ ' to > test if AFS works. > ] curl -v http://localhost/ > . > . > . > > FYI, > Of course I did following things, > CONFIG proxy.config.proxy_name STRING kenyun > CONFIG proxy.config.http.server_port INT 80 > map http://localhost:80/ http://localhost:8080/ > map http://kenyun:80/ http://localhost:8080/ > Listen 8080 > Plz tell me if I did something wrong 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-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
]
Igor Galić updated TS-1184:
---
Description:
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}
was:
Config looked like this:
CONFIG proxy.config.alarm_email STRING nobody
The username had a trailing space. ATS fails to start, and the following
messages appear in /var/log/messages:
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
Fascinating. I didn't even know we used that config option.
Kurt, does this type of error occur also with
{noformat}
CONFIG proxy.config.admin.user_id STRING nobody
{noformat}
> 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
>Priority: Minor
>
> 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 - (
[jira] [Updated] (TS-1109) stack dump may crash too
[ https://issues.apache.org/jira/browse/TS-1109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić updated TS-1109: --- Backport to Version: 3.0.5 > stack dump may crash too > > > Key: TS-1109 > URL: https://issues.apache.org/jira/browse/TS-1109 > Project: Traffic Server > Issue Type: Bug > Components: Core >Affects Versions: 3.1.2 >Reporter: Zhao Yongming >Assignee: weijin > Labels: crash > Fix For: 3.1.3 > > Attachments: cop_crash.diff > > > the codes doing stack dump may crash, in this case you will not able to get a > core file, that will hide most of the rare issues. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1111) crash in RangeTransform::handle_event
[
https://issues.apache.org/jira/browse/TS-?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Galić updated TS-:
---
Backport to Version: 3.0.5
> crash in RangeTransform::handle_event
> -
>
> Key: TS-
> URL: https://issues.apache.org/jira/browse/TS-
> Project: Traffic Server
> Issue Type: Bug
>Reporter: Zhao Yongming
>Assignee: Zhao Yongming
> Labels: crash
> Fix For: 3.1.3
>
> Attachments: transform.patch
>
>
> we have some crashing in range requesting processing, it is on our own tree
> based on 3.0.x, that maybe the root cause of the do_io_close issue, we are
> still look at how to fix that, feedback is welcome
> {code}
> #0 0x004dc624 in RangeTransform::handle_event (this=0x2aaed0001fb0,
> event=1, edata=) at Transform.cc:926
> 926 Debug("transform_range", "RangeTransform destroy: %d",
> m_output_vio ? m_output_vio->ndone : 0);
> (gdb) bt
> #0 0x004dc624 in RangeTransform::handle_event (this=0x2aaed0001fb0,
> event=1, edata=) at Transform.cc:926
> #1 0x0069145f in EThread::process_event (this=0x2b332010,
> e=0x591d410, calling_code=1) at I_Continuation.h:146
> #2 0x00691b8b in EThread::execute (this=0x2b332010) at
> UnixEThread.cc:218
> #3 0x0069092e in spawn_thread_internal (a=0x440bfa0) at Thread.cc:88
> #4 0x00359fe0673d in pthread_create@@GLIBC_2.2.5 () from
> /lib64/libpthread.so.0
> #5 0x in ?? ()
> (gdb) p m_output_vio
> $1 = (VIO *) 0x2aaed0029fe8
> (gdb) p *m_output_vio
> Cannot access memory at address 0x2aaed0029fe8
> {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-949) key->volume hash table is not consistent when a disk is marked as bad or removed due to failure
[
https://issues.apache.org/jira/browse/TS-949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Galić updated TS-949:
--
Backport to Version: 3.0.5
> key->volume hash table is not consistent when a disk is marked as bad or
> removed due to failure
> ---
>
> Key: TS-949
> URL: https://issues.apache.org/jira/browse/TS-949
> Project: Traffic Server
> Issue Type: Bug
> Components: Cache
>Affects Versions: 3.1.0
> Environment: Multi-volume cache with apparently faulty drives
>Reporter: B Wyatt
>Assignee: John Plevyak
> Fix For: 3.1.2
>
> Attachments: TS-949-jp-1.patch, TS-949-jp2.patch, TS949-BW-p1.patch,
> explicit-pair.patch
>
>
> The method for resolving collisions when distributing hash-table space to
> volumes for the object_key->volume hash table creates inconsistency when a
> disk is determined to be bad, or when a failed disk is removed from the
> volume.config.
> Background:
> The hash space is distributed by round robin draft where each volume "drafts"
> a random index in the hash table until the hash space is exhausted. The
> random order in which a given volume drafts hash table slots is consistent
> across reboot/crash/disk-failure, however when a volume attempts to draft a
> slot which has already been occupied, it skips to its next random pick and
> attempts to draft that slot until it finds an open slot. This ensures that
> the hash is partitioned evenly between volumes.
> The issue:
> Resolving slot contention breaks the consistency as it is dependent on the
> order that the volumes draft. When rebuilding the hash after disk failure or
> reboot with fewer drives, a volume may secure an index that was previously
> occupied by the dead-disk. In the old hash, the surviving volume would have
> selected another random index due to contention. If this index is taken, by
> the next draft round it will represent an inconsistent key->volume result.
> The effects of one inconsistency will then cascade as whichever volume
> occupies that index after removing a dead disk is now behind on its draft
> sequence as well.
> An Example:
> ||Disk||Draft Sequence||
> |A|1,4,7,5|
> |B|4,2,8,1|
> |C|3,7,5,2|
> Pre-failure Hash Table after 2 rounds of draft:
> |A|B|C|B|C|?|A|?|
> Post-failure of drive B Hash Table after 3 rounds of draft:
> |A|C|C|A|{color:red}A{color}|?|{color:red}C{color}|?|
> Two slots have become inconsistent and more will probably follow. These
> inconsistencies become objects stored in a volume but lost to the top level
> cache for open/lookup.
--
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-1164) a race condition in cache init
[ https://issues.apache.org/jira/browse/TS-1164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić updated TS-1164: --- Comment: was deleted (was: This hasn't been committed yet, so I'm removing the fix version.) > a race condition in cache init > --- > > Key: TS-1164 > URL: https://issues.apache.org/jira/browse/TS-1164 > Project: Traffic Server > Issue Type: Bug > Components: Cache >Affects Versions: 3.1.1, 3.0.0 > Environment: all >Reporter: weijin >Assignee: weijin > Fix For: 3.1.4 > > Attachments: taorui-cache.diff > > > there is a race condition in CacheProcessor::diskInitialized, which may lead > to cache can not be enabled. -- 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-1164) a race condition in cache init
[ https://issues.apache.org/jira/browse/TS-1164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić updated TS-1164: --- Fix Version/s: 3.1.4 > a race condition in cache init > --- > > Key: TS-1164 > URL: https://issues.apache.org/jira/browse/TS-1164 > Project: Traffic Server > Issue Type: Bug > Components: Cache >Affects Versions: 3.1.1, 3.0.0 > Environment: all >Reporter: weijin >Assignee: weijin > Fix For: 3.1.4 > > Attachments: taorui-cache.diff > > > there is a race condition in CacheProcessor::diskInitialized, which may lead > to cache can not be enabled. -- 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-1164) a race condition in cache init
[ https://issues.apache.org/jira/browse/TS-1164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić updated TS-1164: --- Fix Version/s: (was: 3.1.4) This hasn't been fixed yet, so I'm removing the fix version. > a race condition in cache init > --- > > Key: TS-1164 > URL: https://issues.apache.org/jira/browse/TS-1164 > Project: Traffic Server > Issue Type: Bug > Components: Cache >Affects Versions: 3.1.1, 3.0.0 > Environment: all >Reporter: weijin >Assignee: weijin > Attachments: taorui-cache.diff > > > there is a race condition in CacheProcessor::diskInitialized, which may lead > to cache can not be enabled. -- 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-1049) TS hangs (dead lock) on HTTPS POST requests
[ https://issues.apache.org/jira/browse/TS-1049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić updated TS-1049: --- Backport to Version: 3.0.5 (was: 3.0.3) > TS hangs (dead lock) on HTTPS POST requests > --- > > Key: TS-1049 > URL: https://issues.apache.org/jira/browse/TS-1049 > Project: Traffic Server > Issue Type: Bug > Components: Core, HTTP, SSL >Affects Versions: 3.1.1, 3.1.0, 3.0.2 > Environment: RedHat Enterprise Linux 6.0, Intel 32-bit >Reporter: Wilson Ho >Assignee: Igor Galić >Priority: Blocker > Fix For: 3.1.2 > > Attachments: records.config > > > A very reproducible bug where the body of a HTTPS POST request is never > forwarded to the origin server. > Client submits a HTTPS POST request to TS, which is supposed to forward to > the backend/origin server via HTTP. TS process the HTTP headers and > establishes connection to the origin server, but the body of the HTTPS POST > is never read. This hangs until the client times out and shuts down the > connection. > To reproduce: > # Client connects to TS using HTTPS (works OK if it is just HTTP). > # It must be a POST request. > # TS must use at least 2 worker threads. > # Easier to reproduce when the connections to the origin server is HTTP (not > HTTPS). > # POST body must be large enough so that the HTTP request headers and POST > body do *NOT* fit within the same TCP packet. (2000 bytes is a good size) > # I can consistently reproduce this problem using 2 separate clients each > simultaneously submitting 2 requests back to back (i.e., 2 requests from each > client, a total of 4 requests). This gives you a high probability that at > least one of the requests would hang. > Observation: > # Thread A accepted and processed the HTTP headers, and called > "UnixNetProcessor::connect_re" to prepare a new connection to the origin > server. > # Thread A must not have read the body of the POST. Otherwise, it works fine. > # Thread B was assigned the task to handle the origin server connection. If > the same thread A was picked, then everything works fine. > # Apparently, one of the first things that thread B does is to acquire the > mutex for reading from the client. (Why does it do that??) > # While thread B was holding the mutex, thread A proceeded in > "SSLNetVConnection::net_read_io", tried and failed to acquire the mutex. > Thread A typically re-tried calling "SSLNetVConnection::net_read_io" soon, > but gave up after the second failure. But if thread B released the mutex soon > enough, that thread A could proceed happily and everything works. > # From this point, the body of the POST is never read from the client, and > there is nothing to be proxy'd to the origin server, and both the consumer > and producer tasks are never scheduled to run again -- or until the client > times out. I tried setting the client-side time out to as long as 3-5 > minutes and TS really does not recover by itself until the client closed the > connection. > This is the first time I uses this bug system. Please let me know how I > could produce the configuration files and trace logs, etc. Thanks! -- 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-tra
[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-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
]
Igor Galić updated TS-1185:
---
Comment: was deleted
(was: {noformat}
CXXFLAGS="-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"
{noformat})
> 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
>
> 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-1170) ats_ip_getbestaddrinfo should provide better options
[ https://issues.apache.org/jira/browse/TS-1170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-1170: Description: ats_ip_getbestaddrinfo should support better options about how it selects addresses. * Pick just one address that can be either family. * Force IPv4, IPv6 or be able to prefer if two are equivalent. was: ats_ip_getaddrinfo should support better options about how it selects addresses. * Pick just one address that can be either family. * Force IPv4, IPv6 or be able to prefer if two are equivalent. > ats_ip_getbestaddrinfo should provide better options > > > Key: TS-1170 > URL: https://issues.apache.org/jira/browse/TS-1170 > Project: Traffic Server > Issue Type: Improvement > Components: Network >Affects Versions: 3.1.3 >Reporter: Alan M. Carroll >Assignee: Alan M. Carroll >Priority: Minor > Labels: ipv6 > Fix For: sometime > > > ats_ip_getbestaddrinfo should support better options about how it selects > addresses. > * Pick just one address that can be either family. > * Force IPv4, IPv6 or be able to prefer if two are equivalent. -- 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-1079) Add an API function to turn debugging on for specific transactions/sessions
[ https://issues.apache.org/jira/browse/TS-1079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uri Shachar updated TS-1079: Attachment: debug_specific_4.patch This time including the ts.h.in changes... > Add an API function to turn debugging on for specific transactions/sessions > --- > > Key: TS-1079 > URL: https://issues.apache.org/jira/browse/TS-1079 > Project: Traffic Server > Issue Type: Improvement > Components: Core, HTTP >Reporter: Uri Shachar >Assignee: Leif Hedstrom >Priority: Minor > Fix For: 3.1.4 > > Attachments: debug_specific.patch, debug_specific_2.patch, > debug_specific_3.patch, debug_specific_4.patch > > Original Estimate: 72h > Remaining Estimate: 72h > > When attempting to troubleshoot issues on a production ATS system, it > is often impossible/difficult to turn on any of the 'high-volume' debug tags > like http due to the performance impact. > > This enhancement allows a plugin to set a debug flag for a specific txn/ssn, > and replaces some of the internal Debug calls with a new function that checks > if the flag is turned on, and outputs the debug line regardless of the tag if > it is (The diags enable/disable flag is still taken into account). > The API will also have TSDebugSpecific in order to allow plugins to use the > same functionality. > In addition, we might consider adding an internal config file (remap-like) to > allow turning this flag on without plugin intervention. > -- 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-1079) Add an API function to turn debugging on for specific transactions/sessions
[ https://issues.apache.org/jira/browse/TS-1079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uri Shachar updated TS-1079: Attachment: debug_specific_3.patch Rabased patch to current HEAD > Add an API function to turn debugging on for specific transactions/sessions > --- > > Key: TS-1079 > URL: https://issues.apache.org/jira/browse/TS-1079 > Project: Traffic Server > Issue Type: Improvement > Components: Core, HTTP >Reporter: Uri Shachar >Priority: Minor > Fix For: 3.1.4 > > Attachments: debug_specific.patch, debug_specific_2.patch, > debug_specific_3.patch > > Original Estimate: 72h > Remaining Estimate: 72h > > When attempting to troubleshoot issues on a production ATS system, it > is often impossible/difficult to turn on any of the 'high-volume' debug tags > like http due to the performance impact. > > This enhancement allows a plugin to set a debug flag for a specific txn/ssn, > and replaces some of the internal Debug calls with a new function that checks > if the flag is turned on, and outputs the debug line regardless of the tag if > it is (The diags enable/disable flag is still taken into account). > The API will also have TSDebugSpecific in order to allow plugins to use the > same functionality. > In addition, we might consider adding an internal config file (remap-like) to > allow turning this flag on without plugin intervention. > -- 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 ] Zhao Yongming updated TS-1031: -- Fix Version/s: (was: 3.1.4) 3.3.0 I think the patch should not be required after we fix the do_io_close issue, let us focus on other enhancement later. > 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.3.0 > > 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-1034) reduce futex locking period
[
https://issues.apache.org/jira/browse/TS-1034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zhao Yongming updated TS-1034:
--
Fix Version/s: (was: 3.1.4)
3.3.0
> 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.3.0
>
>
> 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-1058) Intercept an HTTP client's request
[
https://issues.apache.org/jira/browse/TS-1058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yakov Kopel updated TS-1058:
Fix Version/s: (was: 3.3.0)
3.1.4
I attached a patch that is working
> 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.1.4
>
> 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-1154) quick_filter on HEAD does not work
[ https://issues.apache.org/jira/browse/TS-1154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zhao Yongming updated TS-1154: -- Fix Version/s: (was: 3.1.4) 3.0.4 we do not need to fix the current git master, let us just fix it in 3.0.4 > quick_filter on HEAD does not work > -- > > Key: TS-1154 > URL: https://issues.apache.org/jira/browse/TS-1154 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: Zhao Yongming >Assignee: weijin > Fix For: 3.0.4 > > Attachments: head_method.diff > > > we take quick filter as a good solution for some security concern, but when I > set it to 0x0733, it does not allow HEAD in, but setting as 0x0723 does that. > Weijin have the patch in our tree: > https://gitorious.org/trafficserver/taobao/commit/cb23b87d167da4074e047fabc94786003ee94e9a/diffs/db7d0e5be69988b531e8d1e4eea717e6d46df5cd > I will commit if no one complain in 2 days. -- 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-1147) deprecate records.config SSL configuration
[ https://issues.apache.org/jira/browse/TS-1147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-1147: Fix Version/s: (was: 3.1.4) 3.1.5 Assignee: James Peach I'm going to investigate this for 3.1.5 (aka. 3.2). > deprecate records.config SSL configuration > -- > > Key: TS-1147 > URL: https://issues.apache.org/jira/browse/TS-1147 > Project: Traffic Server > Issue Type: Improvement > Components: SSL >Reporter: James Peach >Assignee: James Peach >Priority: Minor > Fix For: 3.1.5 > > > Since ssl_multicert.config is a strict superset of the SSL certificate > configuration in records.config, we should deprecate configuring SSL > certificates in records.config and make ssl_multicert.config the One True Way. -- 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
