[jira] [Commented] (TS-621) writing 0 bytes to the HTTP cache means only update the header... need a new API: update_header_only() to allow 0 byte files to be cached
[ https://issues.apache.org/jira/browse/TS-621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13257302#comment-13257302 ] weijin commented on TS-621: --- John: the patch was just a temporary solution and I did not take into account this situation you mentioned (even did not know). So if you have any ideas about it, tell me. On Thu, 2012-04-19 at 03:51 +, John Plevyak (Commented) (JIRA) > writing 0 bytes to the HTTP cache means only update the header... need a new > API: update_header_only() to allow 0 byte files to be cached > - > > Key: TS-621 > URL: https://issues.apache.org/jira/browse/TS-621 > Project: Traffic Server > Issue Type: Improvement > Components: Cache >Affects Versions: 2.1.5 >Reporter: John Plevyak >Assignee: weijin > Fix For: 3.1.4 > > Attachments: TS-621_cluster_zero_size_objects.patch, > force_empty.diff, ts-621-jp-1.patch, ts-621-jp-2.patch, ts-621-jp-3.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
Re: [jira] [Commented] (TS-621) writing 0 bytes to the HTTP cache means only update the header... need a new API: update_header_only() to allow 0 byte files to be cached
John: the patch was just a temporary solution and I did not take into account this situation you mentioned (even did not know). So if you have any ideas about it, tell me. On Thu, 2012-04-19 at 03:51 +, John Plevyak (Commented) (JIRA) wrote: > [ > https://issues.apache.org/jira/browse/TS-621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13257197#comment-13257197 > ] > > John Plevyak commented on TS-621: > - > > weijin, your patch relies on the Content-Length: header. That is probably > safe and covers most situations, but I don't know that it will work in all > situations. Old school servers (1.0) which don't use Content-Length: will > not benefit. I have to admit that it does finesse the compatibility issues, > but I was hoping for a "complete" solution. Perhaps we can look at using > some combination of the patches whereby we use the API changes I am proposing > and verify that we are doing the right thing with the Content-Length and > perhaps use your flag? > > I'll look into it as well. > > > writing 0 bytes to the HTTP cache means only update the header... need a > > new API: update_header_only() to allow 0 byte files to be cached > > - > > > > Key: TS-621 > > URL: https://issues.apache.org/jira/browse/TS-621 > > Project: Traffic Server > > Issue Type: Improvement > > Components: Cache > >Affects Versions: 2.1.5 > >Reporter: John Plevyak > >Assignee: weijin > > Fix For: 3.1.4 > > > > Attachments: TS-621_cluster_zero_size_objects.patch, > > force_empty.diff, ts-621-jp-1.patch, ts-621-jp-2.patch, ts-621-jp-3.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] [Commented] (TS-621) writing 0 bytes to the HTTP cache means only update the header... need a new API: update_header_only() to allow 0 byte files to be cached
[ https://issues.apache.org/jira/browse/TS-621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13257197#comment-13257197 ] John Plevyak commented on TS-621: - weijin, your patch relies on the Content-Length: header. That is probably safe and covers most situations, but I don't know that it will work in all situations. Old school servers (1.0) which don't use Content-Length: will not benefit. I have to admit that it does finesse the compatibility issues, but I was hoping for a "complete" solution. Perhaps we can look at using some combination of the patches whereby we use the API changes I am proposing and verify that we are doing the right thing with the Content-Length and perhaps use your flag? I'll look into it as well. > writing 0 bytes to the HTTP cache means only update the header... need a new > API: update_header_only() to allow 0 byte files to be cached > - > > Key: TS-621 > URL: https://issues.apache.org/jira/browse/TS-621 > Project: Traffic Server > Issue Type: Improvement > Components: Cache >Affects Versions: 2.1.5 >Reporter: John Plevyak >Assignee: weijin > Fix For: 3.1.4 > > Attachments: TS-621_cluster_zero_size_objects.patch, > force_empty.diff, ts-621-jp-1.patch, ts-621-jp-2.patch, ts-621-jp-3.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] [Assigned] (TS-1210) remove 3.0.x deprecated APIs
[ https://issues.apache.org/jira/browse/TS-1210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach reassigned TS-1210: --- Assignee: James Peach > remove 3.0.x deprecated APIs > > > Key: TS-1210 > URL: https://issues.apache.org/jira/browse/TS-1210 > Project: Traffic Server > Issue Type: Bug > Components: TS API >Reporter: James Peach >Assignee: James Peach > Fix For: 3.1.4 > > > We should remove the following APIs that were deprecated in 3.0: > tsapi TSReturnCode TSUrlDestroy(TSMBuffer bufp, TSMLoc offset); > tsapi TS_DEPRECATED unsigned int TSHttpTxnClientIPGet(TSHttpTxn txnp); > tsapi TS_DEPRECATED TSReturnCode TSHttpTxnClientRemotePortGet(TSHttpTxn > txnp, int* portp); > tsapi TS_DEPRECATED int TSHttpTxnClientIncomingPortGet(TSHttpTxn txnp); > tsapi TS_DEPRECATED unsigned int TSHttpTxnServerIPGet(TSHttpTxn txnp); > tsapi TS_DEPRECATED unsigned int TSHttpTxnNextHopIPGet(TSHttpTxn txnp); > tsapi TS_DEPRECATED int TSHttpTxnNextHopPortGet(TSHttpTxn txnp); > tsapi TS_DEPRECATED int TSHttpTxnMaxArgCntGet(void); > tsapi TS_DEPRECATED unsigned int TSNetVConnRemoteIPGet(TSVConn vc); > tsapi TS_DEPRECATED int TSNetVConnRemotePortGet(TSVConn vc); > tsapi TS_DEPRECATED unsigned int TSHostLookupResultIPGet(TSHostLookupResult > lookup_result); > tsapi TS_DEPRECATED void TSOSIpSet(TSHttpTxn txnp, unsigned int ip); > tsapi TS_DEPRECATED void TSIOBufferAppend(TSIOBuffer bufp, TSIOBufferBlock > blockp); > tsapi TS_DEPRECATED TSIOBufferData TSIOBufferDataCreate(void* data, int > size, TSIOBufferDataFlags flags); > tsapi TS_DEPRECATED TSIOBufferBlock TSIOBufferBlockCreate(TSIOBufferData > datap, int size, int offset); -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: 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
> MIME.cc:3034
> 3034 s_str = heap->duplicate_str(s_str, s_len);
> (gdb) l
> 3029//either NULL or be valid ptr for a string already
> 3030//the string heaps
> 3031heap->free_string(*d_str, *d_len);
> 3032
> 3033if (must_copy && s_str) {
> 3034 s_str = heap->duplicate_str(s_str, s_len);
> 303
[jira] [Updated] (TS-1201) Crash report: hostdb multicache, double free
[
https://issues.apache.org/jira/browse/TS-1201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1201:
--
Fix Version/s: 3.1.4
> Crash report: hostdb multicache, double free
>
>
> Key: TS-1201
> URL: https://issues.apache.org/jira/browse/TS-1201
> Project: Traffic Server
> Issue Type: Bug
>Reporter: Zhao Yongming
>Assignee: weijin
> Fix For: 3.1.4
>
>
> {code}
> *** glibc detected *** /usr/bin/traffic_server: corrupted double-linked list:
> 0x1fe10ef0 ***
> === Backtrace: =
> /lib64/libc.so.6[0x3db2072555]
> /lib64/libc.so.6(cfree+0x4b)[0x3db20728bb]
> /usr/bin/traffic_server(MultiCacheSync::mcEvent(int, Event*)+0xa4)[0x5dae04]
> /usr/bin/traffic_server(EThread::process_event(Event*, int)+0x22f)[0x691c8f]
> /usr/bin/traffic_server(EThread::execute()+0x6a1)[0x692681]
> /usr/bin/traffic_server[0x69115e]
> /lib64/libpthread.so.0[0x3db280673d]
> /lib64/libc.so.6(clone+0x6d)[0x3db20d44bd]
> === Memory map:
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1211) listen queue doesn't get modified for traffic_manager when setting configuration option in records.config
[ https://issues.apache.org/jira/browse/TS-1211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1211: -- Fix Version/s: 3.1.4 > listen queue doesn't get modified for traffic_manager when setting > configuration option in records.config > - > > Key: TS-1211 > URL: https://issues.apache.org/jira/browse/TS-1211 > Project: Traffic Server > Issue Type: Bug >Affects Versions: 3.1.3 >Reporter: Bryan Call > Fix For: 3.1.4 > > > listen queue only gets modified if you are running the traffic_server binary > and not if you use traffic_cop or the startup scripts > traffic_manager is hardcoded to have a listen backlog of 1024. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1204) Crash report: HttpSM::main_handler HttpSM.cc:2412: failed assert `magic == HTTP_SM_MAGIC_ALIVE`
[
https://issues.apache.org/jira/browse/TS-1204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1204:
--
Fix Version/s: 3.1.4
> Crash report: HttpSM::main_handler HttpSM.cc:2412: failed assert `magic ==
> HTTP_SM_MAGIC_ALIVE`
> ---
>
> Key: TS-1204
> URL: https://issues.apache.org/jira/browse/TS-1204
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
>Affects Versions: 3.1.3
> Environment: git master Sat Apr 7 03:29:50 2012. forwarding proxy on
> centos 6.2 x86_64, with cacheurl plugin
>Reporter: Zhao Yongming
> Fix For: 3.1.4
>
>
> {code}
> FATAL: HttpSM.cc:2412: failed assert `magic == HTTP_SM_MAGIC_ALIVE`
> /usr/bin/traffic_server - STACK TRACE:
> /usr/lib64/trafficserver/libtsutil.so.3(ink_fatal+0x88)[0x3ddba14368]
> /usr/lib64/trafficserver/libtsutil.so.3(_ink_assert+0x1f)[0x3ddba12c6f]
> /usr/bin/traffic_server(HttpSM::main_handler(int, void*)+0x2e)[0x5163fe]
> /usr/bin/traffic_server[0x628b4b]
> /usr/bin/traffic_server(write_to_net_io(NetHandler*, UnixNetVConnection*,
> EThread*)+0x353)[0x62c7a3]
> /usr/bin/traffic_server(NetHandler::mainNetEvent(int, Event*)+0x2fe)[0x624cce]
> /usr/bin/traffic_server(EThread::process_event(Event*, int)+0xb4)[0x6494f4]
> /usr/bin/traffic_server(EThread::execute()+0x4c3)[0x649e83]
> /usr/bin/traffic_server[0x648832]
> /lib64/libpthread.so.0[0x380dc077f1]
> /lib64/libc.so.6(clone+0x6d)[0x380d0e592d]
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (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:comment-tabpanel&focusedCommentId=13257075#comment-13257075 ] Bryan Call commented on TS-1211: commit d3bc98bca9c13595409ad58b9be38ad74be52211 Author: Bryan Call Date: Wed Apr 18 16:13:32 2012 -0700 TS-1211 Read backlog config value to set the listen backlog > 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 > > 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] [Commented] (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:comment-tabpanel&focusedCommentId=13257071#comment-13257071 ] Bryan Call commented on TS-1211: with fix that reads the config value: [bcall@snowball trafficserver]$ sudo strace -f /usr/local/bin/traffic_cop 2> [pid ... 10385] listen(7, 2048 ... [bcall@snowball trafficserver]$ tail -1 /usr/local/etc/trafficserver/records.config CONFIG proxy.config.net.listen_backlog INT 2048 > 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 > > 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] [Issue Comment Edited] (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:comment-tabpanel&focusedCommentId=13257067#comment-13257067 ] Bryan Call edited comment on TS-1211 at 4/18/12 11:11 PM: -- doesn't use the configuration value in records.config: [bcall@snowball trafficserver]$ sudo strace -f /usr/local/bin/traffic_cop 2> /dev/stdout | grep listen ... [pid 9401] listen(7, 1024 ... [bcall@snowball trafficserver]$ tail -1 /usr/local/etc/trafficserver/records.config CONFIG proxy.config.net.listen_backlog INT 2048 was (Author: bcall): # doesn't use the configuration value in records.config: [bcall@snowball trafficserver]$ sudo strace -f /usr/local/bin/traffic_cop 2> /dev/stdout | grep listen ... [pid 9401] listen(7, 1024 ... [bcall@snowball trafficserver]$ tail -1 /usr/local/etc/trafficserver/records.config CONFIG proxy.config.net.listen_backlog INT 2048 > 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 > > 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] [Commented] (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:comment-tabpanel&focusedCommentId=13257067#comment-13257067 ] Bryan Call commented on TS-1211: # doesn't use the configuration value in records.config: [bcall@snowball trafficserver]$ sudo strace -f /usr/local/bin/traffic_cop 2> /dev/stdout | grep listen ... [pid 9401] listen(7, 1024 ... [bcall@snowball trafficserver]$ tail -1 /usr/local/etc/trafficserver/records.config CONFIG proxy.config.net.listen_backlog INT 2048 > 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 > > 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] [Created] (TS-1211) listen queue doesn't get modified for traffic_manager when setting configuration option in records.config
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 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-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] [Commented] (TS-1210) remove 3.0.x deprecated APIs
[ https://issues.apache.org/jira/browse/TS-1210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13256718#comment-13256718 ] James Peach commented on TS-1210: - TSUrlDestroy() was deprecated in 3.1.x; we might want to keep that for 3.2.x. > remove 3.0.x deprecated APIs > > > Key: TS-1210 > URL: https://issues.apache.org/jira/browse/TS-1210 > Project: Traffic Server > Issue Type: Bug > Components: TS API >Reporter: James Peach > Fix For: 3.1.4 > > > We should remove the following APIs that were deprecated in 3.0: > tsapi TSReturnCode TSUrlDestroy(TSMBuffer bufp, TSMLoc offset); > tsapi TS_DEPRECATED unsigned int TSHttpTxnClientIPGet(TSHttpTxn txnp); > tsapi TS_DEPRECATED TSReturnCode TSHttpTxnClientRemotePortGet(TSHttpTxn > txnp, int* portp); > tsapi TS_DEPRECATED int TSHttpTxnClientIncomingPortGet(TSHttpTxn txnp); > tsapi TS_DEPRECATED unsigned int TSHttpTxnServerIPGet(TSHttpTxn txnp); > tsapi TS_DEPRECATED unsigned int TSHttpTxnNextHopIPGet(TSHttpTxn txnp); > tsapi TS_DEPRECATED int TSHttpTxnNextHopPortGet(TSHttpTxn txnp); > tsapi TS_DEPRECATED int TSHttpTxnMaxArgCntGet(void); > tsapi TS_DEPRECATED unsigned int TSNetVConnRemoteIPGet(TSVConn vc); > tsapi TS_DEPRECATED int TSNetVConnRemotePortGet(TSVConn vc); > tsapi TS_DEPRECATED unsigned int TSHostLookupResultIPGet(TSHostLookupResult > lookup_result); > tsapi TS_DEPRECATED void TSOSIpSet(TSHttpTxn txnp, unsigned int ip); > tsapi TS_DEPRECATED void TSIOBufferAppend(TSIOBuffer bufp, TSIOBufferBlock > blockp); > tsapi TS_DEPRECATED TSIOBufferData TSIOBufferDataCreate(void* data, int > size, TSIOBufferDataFlags flags); > tsapi TS_DEPRECATED TSIOBufferBlock TSIOBufferBlockCreate(TSIOBufferData > datap, int size, int offset); -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1210) remove 3.0.x deprecated APIs
remove 3.0.x deprecated APIs Key: TS-1210 URL: https://issues.apache.org/jira/browse/TS-1210 Project: Traffic Server Issue Type: Bug Components: TS API Reporter: James Peach Fix For: 3.1.4 We should remove the following APIs that were deprecated in 3.0: tsapi TSReturnCode TSUrlDestroy(TSMBuffer bufp, TSMLoc offset); tsapi TS_DEPRECATED unsigned int TSHttpTxnClientIPGet(TSHttpTxn txnp); tsapi TS_DEPRECATED TSReturnCode TSHttpTxnClientRemotePortGet(TSHttpTxn txnp, int* portp); tsapi TS_DEPRECATED int TSHttpTxnClientIncomingPortGet(TSHttpTxn txnp); tsapi TS_DEPRECATED unsigned int TSHttpTxnServerIPGet(TSHttpTxn txnp); tsapi TS_DEPRECATED unsigned int TSHttpTxnNextHopIPGet(TSHttpTxn txnp); tsapi TS_DEPRECATED int TSHttpTxnNextHopPortGet(TSHttpTxn txnp); tsapi TS_DEPRECATED int TSHttpTxnMaxArgCntGet(void); tsapi TS_DEPRECATED unsigned int TSNetVConnRemoteIPGet(TSVConn vc); tsapi TS_DEPRECATED int TSNetVConnRemotePortGet(TSVConn vc); tsapi TS_DEPRECATED unsigned int TSHostLookupResultIPGet(TSHostLookupResult lookup_result); tsapi TS_DEPRECATED void TSOSIpSet(TSHttpTxn txnp, unsigned int ip); tsapi TS_DEPRECATED void TSIOBufferAppend(TSIOBuffer bufp, TSIOBufferBlock blockp); tsapi TS_DEPRECATED TSIOBufferData TSIOBufferDataCreate(void* data, int size, TSIOBufferDataFlags flags); tsapi TS_DEPRECATED TSIOBufferBlock TSIOBufferBlockCreate(TSIOBufferData datap, int size, int offset); -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1209) background_fill values don't seem to be working
[ https://issues.apache.org/jira/browse/TS-1209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13256656#comment-13256656 ] Robert Logue commented on TS-1209: -- ok so there is a function HttpSM::is_bg_fill_necessary that lets TS know if it should do a background fill. In here it checks 3 items, initially, 2 of which are ok but one fails. The check that fails is c->producer->vc_type == HT_HTTP_SERVER, in my scenario c->producer->vc_type == HT_TRANSFORM. Also I have a transform plugin running. If I remove the transformation plugin the background fill works fine. > background_fill values don't seem to be working > --- > > Key: TS-1209 > URL: https://issues.apache.org/jira/browse/TS-1209 > Project: Traffic Server > Issue Type: Bug > Components: Cache >Affects Versions: 3.0.4 >Reporter: Robert Logue >Priority: Minor > > If I request a 57 MB file TS caches the fill no problem and on subsequent > requests the file gets served from cache. If I cut the request early, about > 40MB downloaded and I have > proxy.config.http.background_fill_completed_threshold = 0.5 and > proxy.config.http.background_fill_active_timeout is suitably high, the file > is not cached. I am of the understanding that the background fill values > should keep the OS connection open and allow the full item to be cached > though this is not happening. > I have tried various values for > proxy.config.http.background_fill_completed_threshold ranging from 0.0 -> > 0.5, none seem to work. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1209) background_fill values don't seem to be working
background_fill values don't seem to be working --- Key: TS-1209 URL: https://issues.apache.org/jira/browse/TS-1209 Project: Traffic Server Issue Type: Bug Components: Cache Affects Versions: 3.0.4 Reporter: Robert Logue Priority: Minor If I request a 57 MB file TS caches the fill no problem and on subsequent requests the file gets served from cache. If I cut the request early, about 40MB downloaded and I have proxy.config.http.background_fill_completed_threshold = 0.5 and proxy.config.http.background_fill_active_timeout is suitably high, the file is not cached. I am of the understanding that the background fill values should keep the OS connection open and allow the full item to be cached though this is not happening. I have tried various values for proxy.config.http.background_fill_completed_threshold ranging from 0.0 -> 0.5, none seem to work. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TS-1051) Updating logs_xml.config requires full restart
[
https://issues.apache.org/jira/browse/TS-1051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zhao Yongming closed TS-1051.
-
Resolution: Not A Problem
Fix Version/s: (was: 3.3.0)
sometime
reopen if it still valid
> Updating logs_xml.config requires full restart
> --
>
> Key: TS-1051
> URL: https://issues.apache.org/jira/browse/TS-1051
> Project: Traffic Server
> Issue Type: Bug
> Components: Logging
>Affects Versions: 3.1.2
>Reporter: Billy Vierra
>Assignee: Zhao Yongming
> Fix For: sometime
>
>
> Using SVN Rev: 1214051
> URL: http://svn.apache.org/repos/asf/trafficserver/traffic/trunk
> upon adding a new LogObject and doing traffic_line -x you get the following
> in traffic.out
> [Dec 14 12:31:48.533] Manager {0x7f2f2abef700} NOTE: User has changed config
> file logs_xml.config
> However it does not go into effect (new log is not created). Upon full
> restart: trafficserver stop, trafficserver start it will add the new log file
> as expected.
> Not sure if it is a bug with docs or in code.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-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] [Work started] (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 ] Work on TS-1208 started by Zhao Yongming. > 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-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] [Created] (TS-1208) check_memory() in traffic_cop never active on linux
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 Reporter: Zhao Yongming Assignee: Zhao Yongming 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
