[jira] [Updated] (TS-1001) reload the changes in dns.resolv_conf
[ https://issues.apache.org/jira/browse/TS-1001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1001: -- Fix Version/s: 3.1.3 > reload the changes in dns.resolv_conf > - > > Key: TS-1001 > URL: https://issues.apache.org/jira/browse/TS-1001 > Project: Traffic Server > Issue Type: Wish > Components: DNS >Reporter: Conan Wang >Priority: Trivial > Fix For: 3.1.3 > > > a trivial wish: ATS can reload (traffic_line -x) resolv.conf if nameserver > changed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1008) TCP connection data isn't available from TSHttpSsn Object
[ https://issues.apache.org/jira/browse/TS-1008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1008: -- Fix Version/s: 3.1.2 > TCP connection data isn't available from TSHttpSsn Object > - > > Key: TS-1008 > URL: https://issues.apache.org/jira/browse/TS-1008 > Project: Traffic Server > Issue Type: Bug > Components: TS API >Affects Versions: 3.0.1 >Reporter: Nick Kew >Assignee: Nick Kew > Fix For: 3.1.2 > > > TCP connection data can be obtained through several API functions, such as > TSHttpTxnClientAddrGet. > But the connection naturally belongs not to the TXN object but to the SSN > object. There should be a TSHttpSsn*AddrGet family of functions that can be > used in a SSN_START (or any later) hook to obtain connection information. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1014) slow log can not print logs well on 32-bit system, I changed the %d to RPI64
[ https://issues.apache.org/jira/browse/TS-1014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1014: -- Fix Version/s: 3.1.2 > slow log can not print logs well on 32-bit system, I changed the %d to RPI64 > > > Key: TS-1014 > URL: https://issues.apache.org/jira/browse/TS-1014 > Project: Traffic Server > Issue Type: Bug >Affects Versions: 3.1.0 > Environment: 32-bit system >Reporter: weijin >Priority: Minor > Fix For: 3.1.2 > > Attachments: slow_log.diff > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1002) log unmapped HOST when pristine_host_hdr disabled
[
https://issues.apache.org/jira/browse/TS-1002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1002:
--
Fix Version/s: 3.1.2
> log unmapped HOST when pristine_host_hdr disabled
> -
>
> Key: TS-1002
> URL: https://issues.apache.org/jira/browse/TS-1002
> Project: Traffic Server
> Issue Type: Wish
> Components: Logging
>Reporter: Conan Wang
>Priority: Minor
> Fix For: 3.1.2
>
>
> I want to log user request's "Host" in http header before remap. I write
> logs_xml.config, like: %<{Host}cqh>
> When proxy.config.url_remap.pristine_host_hdr is enabled, I will get the
> right "Host" which is not rewritten.
> When disable the config, I always get the rewritten/mapped "Host" which is
> not what I need.
> logs_xml reference:
> http://trafficserver.apache.org/docs/v2/admin/logfmts.htm#66912
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
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: 3.1.2 > 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: Alan M. Carroll > Fix For: 3.1.2 > > > 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-981) ATS as transparent proxy crashes under heavy load
[ https://issues.apache.org/jira/browse/TS-981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-981: - Fix Version/s: 3.1.2 > ATS as transparent proxy crashes under heavy load > - > > 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 >Priority: Critical > Fix For: 3.1.2 > > 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-1015) TSEvent is widely declared as int
[ https://issues.apache.org/jira/browse/TS-1015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1015: -- Fix Version/s: 3.1.2 > TSEvent is widely declared as int > - > > Key: TS-1015 > URL: https://issues.apache.org/jira/browse/TS-1015 > Project: Traffic Server > Issue Type: Bug >Reporter: Nick Kew >Priority: Minor > Fix For: 3.1.2 > > > TSEvent is an enum, defined in ts.h. But in much of the code, TSEvent is > declared as type int. This makes it harder to follow/debug using tools like > *trace or gdb. > This may usefully be fixed as and when people encounter instances of it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1019) clean up access to librecords and remove wrappers
[
https://issues.apache.org/jira/browse/TS-1019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1019:
--
Fix Version/s: 3.1.2
> clean up access to librecords and remove wrappers
> -
>
> Key: TS-1019
> URL: https://issues.apache.org/jira/browse/TS-1019
> Project: Traffic Server
> Issue Type: Improvement
> Components: Core
>Reporter: Bryan Call
>Assignee: Igor Galić
>Priority: Minor
> Fix For: 3.1.2
>
>
> There are unneeded define wrappers around the librecord function calls:
> {noformat}
> [bcall@Bryan-Calls-MacBook-Pro-3 traffic.git]$ grep -r REC_ConfigReadInteger
> * | grep define
> iocore/eventsystem/P_EventSystem.h:#define IOCORE_ConfigReadInteger
> REC_ConfigReadInteger
> proxy/http/HttpConfig.h:#define HTTP_ConfigReadInteger
> REC_ConfigReadInteger
> proxy/logging/LogConfig.h:#define LOG_ConfigReadInteger
> REC_ConfigReadInteger
> proxy/logging/LogConfig.h:#define LOG_LocalReadInteger
> REC_ConfigReadInteger
> proxy/Main.h:#define TS_ConfigReadIntegerREC_ConfigReadInteger
> proxy/Prefetch.h:#define TS_ConfigReadIntegerREC_ConfigReadInteger
> proxy/Update.cc:#define UPDATE_ConfigReadInteger REC_ConfigReadInteger
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1007) SSN Close called before TXN Close
[ https://issues.apache.org/jira/browse/TS-1007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1007: -- Fix Version/s: 3.1.2 > SSN Close called before TXN Close > - > > Key: TS-1007 > URL: https://issues.apache.org/jira/browse/TS-1007 > Project: Traffic Server > Issue Type: Bug > Components: TS API >Affects Versions: 3.0.1 >Reporter: Nick Kew >Priority: Critical > Fix For: 3.1.2 > > > Where a plugin implements both SSN_CLOSE_HOOK and TXN_CLOSE_HOOK, the > SSN_CLOSE_HOOK is called first of the two. This messes up normal cleanups! > Details: > Register a SSN_START event globally > In the SSN START, add a TXN_START and a SSN_CLOSE > In the TXN START, add a TXN_CLOSE > Stepping through, I see the order of events actually called, for the simple > case of a one-off HTTP request with no keepalive: > SSN_START > TXN_START > SSN_END > TXN_END > Whoops, SSN_END cleaned up the SSN context, leaving dangling pointers in the > TXN! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1024) remap_required 0 not functioning in revproxy mode
[ https://issues.apache.org/jira/browse/TS-1024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1024: -- Fix Version/s: 3.1.2 > remap_required 0 not functioning in revproxy mode > - > > Key: TS-1024 > URL: https://issues.apache.org/jira/browse/TS-1024 > Project: Traffic Server > Issue Type: Bug > Components: Remap API >Affects Versions: 3.0.2 >Reporter: Greg Dallavalle >Priority: Minor > Labels: parent, remap_required > Fix For: 3.1.2 > > > with > [records.config] > proxy.config.url_remap.remap_required INT 0 > proxy.config.http.parent_proxy_routing_enable INT 1 > proxy.config.http.no_dns_just_forward_to_parent INT 1 > ATS still requires a remap URL to be used. The way I worked around this was > to have remapped URLs to themselves: > [remap.config] > map http://example.com http://example.com > map http://sub.example.com http://sub.example.com > With those settings all requests are passed through to my origin, or "parent > cache" servers. The pass to the parent cache did not work in 3.0.1. I had > to build from the 3.0.x branch for this to function. > [parent.config] > dest_domain=. parent="1.2.3.4:80; 4.5.6.7:80" round_robin=strict > I think this is convoluted given my fairly common setup of two reverse > proxies caching/load balancing round robin to a few origin servers. I guess > the only "bug" here is that the remap_required parameter is not functioning > as well as it could be. I hope for improvement in the way this setup is > handled. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-996) HTTPHdr::m_host goes stale if HdrHeap::evacuate_from_str_heaps is called
[ https://issues.apache.org/jira/browse/TS-996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-996: - Fix Version/s: 3.1.2 > HTTPHdr::m_host goes stale if HdrHeap::evacuate_from_str_heaps is called > > > Key: TS-996 > URL: https://issues.apache.org/jira/browse/TS-996 > Project: Traffic Server > Issue Type: Bug > Components: HTTP, MIME >Affects Versions: 3.1.0 >Reporter: B Wyatt > Fix For: 3.1.2 > > Attachments: m_host.V2.patch, m_host.patch > > > class HTTPHdr stores a copy of the string pointer from either the URLimpl or > the MIMEHdr for the host name in m_host. In both cases, these strings can be > moved to a new heap underneath the HTTPHdr. When this happens, the process > will, at best read stale memory and be fine and at worst read unmapped memory > and segfault. > Currently, HdrHeap::evacuate_from_str_heaps is called to coalesce multiple > heaps into a single heap. When this happens it will directly access the low > level objects via ::move_strings calls. These objects do not posses the > necessary information to inform parent objects about the change, nor does the > HdrHeap directly inform interested parties. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-1024) remap_required 0 not functioning in revproxy mode
[ https://issues.apache.org/jira/browse/TS-1024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-1024: - Assignee: Leif Hedstrom > remap_required 0 not functioning in revproxy mode > - > > Key: TS-1024 > URL: https://issues.apache.org/jira/browse/TS-1024 > Project: Traffic Server > Issue Type: Bug > Components: Remap API >Affects Versions: 3.0.2 >Reporter: Greg Dallavalle >Assignee: Leif Hedstrom >Priority: Minor > Labels: parent, remap_required > Fix For: 3.1.2 > > > with > [records.config] > proxy.config.url_remap.remap_required INT 0 > proxy.config.http.parent_proxy_routing_enable INT 1 > proxy.config.http.no_dns_just_forward_to_parent INT 1 > ATS still requires a remap URL to be used. The way I worked around this was > to have remapped URLs to themselves: > [remap.config] > map http://example.com http://example.com > map http://sub.example.com http://sub.example.com > With those settings all requests are passed through to my origin, or "parent > cache" servers. The pass to the parent cache did not work in 3.0.1. I had > to build from the 3.0.x branch for this to function. > [parent.config] > dest_domain=. parent="1.2.3.4:80; 4.5.6.7:80" round_robin=strict > I think this is convoluted given my fairly common setup of two reverse > proxies caching/load balancing round robin to a few origin servers. I guess > the only "bug" here is that the remap_required parameter is not functioning > as well as it could be. I hope for improvement in the way this setup is > handled. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-999) Deprecate TSUrlDestroy ?
[ https://issues.apache.org/jira/browse/TS-999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-999: - Assignee: Leif Hedstrom > Deprecate TSUrlDestroy ? > > > Key: TS-999 > URL: https://issues.apache.org/jira/browse/TS-999 > Project: Traffic Server > Issue Type: Improvement > Components: TS API >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom > Fix For: 3.1.2 > > > This API is a complete no-op as of quite a while ago. Should we just > deprecate it? Or, does anyone foresee a future where we actually need to call > TSUrlDestroy? Alan? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-1006) memory management, cut down memory waste ?
[
https://issues.apache.org/jira/browse/TS-1006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13153365#comment-13153365
]
Zhao Yongming commented on TS-1006:
---
we have made some enhancement and the result looks like the following, and we
are still tracking for bugs and this is the first try, we will submit then
codes after it stable for our usage.
{code}
[Nov 19 11:25:42.351] Server {0x4257a940} WARNING: Document 644CE0FF truncated
at 10485040 of 21289520, missing fragment 9DD38ED0
allocated |in-use | type size | free list name
|||--
67108864 | 0 |2097152 |
memory/cacheBufAllocator[14]
33554432 | 0 |1048576 |
memory/cacheBufAllocator[13]
33554432 |1572864 | 524288 |
memory/cacheBufAllocator[12]
33554432 |6029312 | 262144 |
memory/cacheBufAllocator[11]
37748736 | 17301504 | 131072 |
memory/cacheBufAllocator[10]
35651584 | 32964608 | 65536 |
memory/cacheBufAllocator[9]
70254592 | 64782336 | 32768 |
memory/cacheBufAllocator[8]
55574528 | 46366720 | 16384 |
memory/cacheBufAllocator[7]
28573696 | 22749184 | 8192 |
memory/cacheBufAllocator[6]
11534336 |320 | 4096 |
memory/cacheBufAllocator[5]
0 | 0 | 2048 |
memory/cacheBufAllocator[4]
0 | 0 | 1024 |
memory/cacheBufAllocator[3]
0 | 0 |512 |
memory/cacheBufAllocator[2]
0 | 0 |256 |
memory/cacheBufAllocator[1]
0 | 0 |128 |
memory/cacheBufAllocator[0]
1572864 | 997376 | 2048 | memory/hdrStrHeap
2621440 |1466368 | 2048 | memory/hdrHeap
262144 | 203776 | 1024 | memory/ArenaBlock
dallocated |in-use | type size | free list name
|||--
0 | 0 |2097152 |
memory/ioBufAllocator[14]
0 | 0 |1048576 |
memory/ioBufAllocator[13]
0 | 0 | 524288 |
memory/ioBufAllocator[12]
0 | 0 | 262144 |
memory/ioBufAllocator[11]
0 | 0 | 131072 |
memory/ioBufAllocator[10]
0 | 0 | 65536 | memory/ioBufAllocator[9]
7340032 |6455296 | 32768 | memory/ioBufAllocator[8]
1048576 | 720896 | 16384 | memory/ioBufAllocator[7]
1310720 |1048576 | 8192 | memory/ioBufAllocator[6]
1572864 | 929792 | 4096 | memory/ioBufAllocator[5]
0 | 0 | 2048 | memory/ioBufAllocator[4]
0 | 0 | 1024 | memory/ioBufAllocator[3]
0 | 0 |512 | memory/ioBufAllocator[2]
0 | 0 |256 | memory/ioBufAllocator[1]
0 | 0 |128 | memory/ioBufAllocator[0]
0 | 0 |592 |
memory/ICPRequestCont_allocator
0 | 0 |128 |
memory/ICPPeerReadContAllocator
0 | 0 |432 |
memory/PeerReadDataAllocator
0 | 0 | 32 |
memory/MIMEFieldSDKHandle
0 | 0 |256 | memory/INKVConnAllocator
0 | 0 |112 | memory/INKContAllocator
0 | 0 | 32 | memory/apiHookAllocator
0 | 0 |304 | memory/FetchSMAllocator
0 | 0 | 80 |
memory/prefetchLockHandlerAllocator
0 | 0 |176 |
memory/PrefetchBlasterAllocator
0 | 0 | 80 |
memory/prefetchUrlBlaster
0 | 0 | 96 | memory/blasterUrlList
0 | 0 | 96 |
memory/prefetchUrlEntryAllocator
0 | 0 |128 |
memory/socksProxyAllocator
0 | 0 |160 | memory/ObjectReloadCont
155648 | 120992 |608 |
memory/httpClientSessionAllocator
266
