[jira] [Updated] (TS-484) INKHttpTxnSetRespCacheableSet() vs INKHttpTxnServerRespNoStore()
[ https://issues.apache.org/jira/browse/TS-484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-484: - Component/s: TS API > INKHttpTxnSetRespCacheableSet() vs INKHttpTxnServerRespNoStore() > > > Key: TS-484 > URL: https://issues.apache.org/jira/browse/TS-484 > Project: Traffic Server > Issue Type: Improvement > Components: TS API >Reporter: Leif Hedstrom > Fix For: 3.5.0 > > > it seems that the logic around the new API INKHttpTxnSetRespCacheableSet() is > very similar to the old, existing INKHttpTxnServerRespNoStore(). Would it be > possible to "merge" the new API logic into the existing one (without changing > the old API) ? This would be a great thing to fix before we finalize v2.2, > to avoid breaking / adding more APIs. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-656) reimplement Connection Collapsing in a smoth way
[ https://issues.apache.org/jira/browse/TS-656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-656: - Component/s: HTTP > reimplement Connection Collapsing in a smoth way > > > Key: TS-656 > URL: https://issues.apache.org/jira/browse/TS-656 > Project: Traffic Server > Issue Type: Improvement > Components: HTTP >Affects Versions: 2.1.6 > Environment: per discussed in IRC, we'd like to clean the current CC > codes from trunk. >Reporter: Zhao Yongming > Fix For: 3.5.0 > > > we should figure out how to implement the Connection Collapsing that not so > ugly. target for V3.1 or so. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-754) Reduce memory usage on idle connections
[ https://issues.apache.org/jira/browse/TS-754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-754: - Component/s: Core > Reduce memory usage on idle connections > --- > > Key: TS-754 > URL: https://issues.apache.org/jira/browse/TS-754 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Reporter: Leif Hedstrom > Fix For: 3.5.0 > > > We should examine what memory (if any) can be returned to class allocators / > freelist when a connection is idle (in keep-alive). Right now, I suspect we > hold on to more memory than is necessary, which limits the number of KA > connections a server can have. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1622) Add an API to query if a response header would be cacheable
[ https://issues.apache.org/jira/browse/TS-1622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1622: -- Component/s: TS API > Add an API to query if a response header would be cacheable > --- > > Key: TS-1622 > URL: https://issues.apache.org/jira/browse/TS-1622 > Project: Traffic Server > Issue Type: Improvement > Components: TS API >Reporter: Leif Hedstrom > Fix For: 3.5.0 > > > It would be useful for a plugin to be able to take e.g. a response header (a > Hdr object) and ask the HttpSM if this response would be cacheable or not. It > should use the same logic (and configs) as the core does normally. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-893) the prefetch function in codes need more love to show up
[ https://issues.apache.org/jira/browse/TS-893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-893: - Component/s: HTTP Cache > the prefetch function in codes need more love to show up > > > Key: TS-893 > URL: https://issues.apache.org/jira/browse/TS-893 > Project: Traffic Server > Issue Type: Improvement > Components: Cache, HTTP >Affects Versions: 3.0.0 >Reporter: Zhao Yongming >Assignee: Zhao Yongming > Fix For: 3.5.0 > > > the prefetch function in proxy is a good solution when you really need to > faster up your user download time, it can parse any allowed plean html file, > get all resource tags out and do batch loading from OS. I am going to preload > my site before we put it online, as it will get about 1 month to get the disk > full and hit rate stable. it is a cool feature but it have the following > issues: > 1, the prefetch config file is not managed well. ie, it is not managed by > cluster > 2, the it does not any document in the admin guide or old pdf file. > 3, prefetching just care plean html file, without compressing, should we do > some decompressing? is that possible? > hopes this is the starting of make prefetch really useful for some cutting > edge situation. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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: - Component/s: Build > Add OpenBSD support. > > > Key: TS-993 > URL: https://issues.apache.org/jira/browse/TS-993 > Project: Traffic Server > Issue Type: Improvement > Components: Build > Environment: OpenBSD >Reporter: Piotr Sikora > Fix For: 3.5.0 > > Attachments: 0001-Add-OpenBSD-support.patch, freebsd.patch > > > Add OpenBSD support. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1665) Remove TCL dependency
[ https://issues.apache.org/jira/browse/TS-1665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1665: -- Component/s: Core > Remove TCL dependency > - > > Key: TS-1665 > URL: https://issues.apache.org/jira/browse/TS-1665 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Reporter: Phil Sorber >Assignee: Phil Sorber > Fix For: 3.5.0 > > > Remove all references to TCL and provide suitable replacements where > necessary. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (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:comment-tabpanel&focusedCommentId=13613451#comment-13613451 ] Leif Hedstrom commented on TS-1067: --- I'm going to remove bandwidth_mgmt_xml.config and all teh code related to this. If someone has a concern with this, please let me know. This is, as far as I can tell, a remnant from the old MIXed streaming media protocols, that were half plugins - half TS core implementations. IF/when we support bandwidth management properly we can revisit this, but right now, this is really dead code. Please speak up if you wish the code to be preserved, and I'll leave that, but I'll still remove the config file support, since it's confusing. > 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.2 > > > 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 For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1776) Range requests not working right in 3.2.4
[ https://issues.apache.org/jira/browse/TS-1776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13613422#comment-13613422 ] William Bardwell commented on TS-1776: -- It should be pretty easy to add tests, just need to do a full load of a cachable object, and then a range load 1-10 or some such. > Range requests not working right in 3.2.4 > - > > Key: TS-1776 > URL: https://issues.apache.org/jira/browse/TS-1776 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Affects Versions: 3.2.4 >Reporter: William Bardwell > > With the patch in 3.2.4 for TS-1575 that tries to turn off the new range > code, range requests aren't work right for me. The responses have all of the > multi-part header markings, but the Content-Length and Content-Range headers > should be used for single range requests. Also when I do a range that starts > > 0, the content is wrong. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1776) Range requests not working right in 3.2.4
[ https://issues.apache.org/jira/browse/TS-1776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Bardwell updated TS-1776: - Affects Version/s: 3.2.4 > Range requests not working right in 3.2.4 > - > > Key: TS-1776 > URL: https://issues.apache.org/jira/browse/TS-1776 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Affects Versions: 3.2.4 >Reporter: William Bardwell > > With the patch in 3.2.4 for TS-1575 that tries to turn off the new range > code, range requests aren't work right for me. The responses have all of the > multi-part header markings, but the Content-Length and Content-Range headers > should be used for single range requests. Also when I do a range that starts > > 0, the content is wrong. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1776) Range requests not working right in 3.2.4
[ https://issues.apache.org/jira/browse/TS-1776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13613419#comment-13613419 ] James Peach commented on TS-1776: - William, do you think it's tractable to add unit tests for this stuff? > Range requests not working right in 3.2.4 > - > > Key: TS-1776 > URL: https://issues.apache.org/jira/browse/TS-1776 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: William Bardwell > > With the patch in 3.2.4 for TS-1575 that tries to turn off the new range > code, range requests aren't work right for me. The responses have all of the > multi-part header markings, but the Content-Length and Content-Range headers > should be used for single range requests. Also when I do a range that starts > > 0, the content is wrong. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1717) static library build fails with duplicate symbols
[ https://issues.apache.org/jira/browse/TS-1717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13613416#comment-13613416 ] James Peach commented on TS-1717: - I have a patch that mostly works. Once that's approved and committed we can look into tidying up the loose ends. > static library build fails with duplicate symbols > - > > Key: TS-1717 > URL: https://issues.apache.org/jira/browse/TS-1717 > Project: Traffic Server > Issue Type: Bug > Components: Build >Reporter: James Peach >Assignee: James Peach > Fix For: 3.3.2 > > > fish:trafficserver.git jpeach$ ./config.nice --disable-shared --enable-static > && make -j && sudo make install > ... > CXXLDtraffic_manager > AR libmgmt_p.a > duplicate symbol _diags in: > Main.o > ../lib/ts/.libs/libtsutil.a(Diags.o) > ld: 1 duplicate symbol for architecture x86_64 > example/app-template/app-template.cc://Diags *diags = NULL; > iocore/aio/test_AIO.i:Diags *diags; > iocore/cluster/test_I_Cluster.cc:Diags *diags; > iocore/cluster/test_P_Cluster.cc:Diags *diags; > iocore/dns/test_I_DNS.cc:Diags *diags; > iocore/dns/test_P_DNS.cc:Diags *diags; > iocore/eventsystem/test_Buffer.cc:Diags *diags; > iocore/eventsystem/test_Event.i:Diags *diags; > iocore/hostdb/test_I_HostDB.cc:Diags *diags; > iocore/hostdb/test_P_HostDB.cc:Diags *diags; > iocore/net/test_I_Net.cc:Diags *diags; > iocore/net/test_I_UDPNet.cc:Diags *diags; > iocore/net/test_P_Net.cc:Diags *diags; > iocore/net/test_P_UDPNet.cc:Diags *diags; > iocore/utils/diags.i://Diags *diags; > lib/records/I_RecCore.h:int RecSetDiags(Diags * diags); > lib/records/I_RecLocal.h:int RecLocalInit(Diags * diags = NULL); > lib/records/I_RecProcess.h:int RecProcessInit(RecModeT mode_type, Diags * > diags = NULL); > lib/records/P_RecCore.h:int RecCoreInit(RecModeT mode_type, Diags * diags); > lib/records/RecCore.cc:Diags *g_diags = NULL; > lib/records/RecCore.cc:RecCoreInit(RecModeT mode_type, Diags *_diags) > lib/records/RecCore.cc:RecSetDiags(Diags * _diags) > lib/records/RecLocal.cc:RecLocalInit(Diags * _diags) > lib/records/RecProcess.cc:RecProcessInit(RecModeT mode_type, Diags *_diags) > lib/records/RecUtils.cc:extern Diags *g_diags; > lib/records/test_I_RecLocal.cc:Diags *diags = NULL; > lib/records/test_RecProcess.i:Diags *diags = NULL; > lib/ts/Diags.cc:inkcoreapi Diags *diags = NULL; > lib/ts/Diags.h:extern inkcoreapi Diags *diags; > mgmt/Main.cc:inkcoreapi Diags *diags; > proxy/DiagsConfig.h: Diags *diags; > proxy/Initialize.h:extern Diags *diags; > proxy/Main.cc://inkcoreapi Diags *diags = NULL; > proxy/hdrs/load_http_hdr.cc://Diags *diags; > proxy/logging/LogStandalone.cc:Diags *diags = NULL; > Additionally, AFAICT diags.i is not used and can be removed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1715) Possibly range related crashing since upgrading to 3.2.4
[
https://issues.apache.org/jira/browse/TS-1715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13613390#comment-13613390
]
Alan M. Carroll commented on TS-1715:
-
No update that I can remember, will check on it tomrrow.
Monday, March 25, 2013, 3:15:16 PM, you wrote:
> Possibly range related crashing since upgrading to 3.2.4
>
>
> Key: TS-1715
> URL: https://issues.apache.org/jira/browse/TS-1715
> Project: Traffic Server
> Issue Type: Bug
> Components: Cache, Core
>Affects Versions: 3.2.4
>Reporter: David Carlin
>Assignee: Alan M. Carroll
> Fix For: 3.3.2
>
>
> This might be related to TS-1574
> I upgraded one box to 3.2.4, and and I am experiencing the following crash
> approximately twice a day:
> Backtraces - the first happens more frequently:
> {noformat}
> #0 RangeTransform::transform_to_range (this=0x2b40e40973d0) at
> Transform.cc:843
> #1 0x004e52e8 in RangeTransform::handle_event (this=0x2b40e40973d0,
> event=, edata=) at Transform.cc:816
> #2 0x006970f4 in handleEvent (this=0x2b40b9762010, e=0x2b40dc47f9e0,
> calling_code=1) at I_Continuation.h:146
> #3 EThread::process_event (this=0x2b40b9762010, e=0x2b40dc47f9e0,
> calling_code=1) at UnixEThread.cc:142
> #4 0x00697b6b in EThread::execute (this=0x2b40b9762010) at
> UnixEThread.cc:191
> #5 0x006960c2 in spawn_thread_internal (a=0x15e04a0) at Thread.cc:88
> #6 0x0031f8c07851 in start_thread () from /lib64/libpthread.so.0
> #7 0x0031f88e76dd in clone () from /lib64/libc.so.6
> #0 RangeTransform::transform_to_range (this=0x2b11441773f0) at
> Transform.cc:843
> #1 0x004e52e8 in RangeTransform::handle_event (this=0x2b11441773f0,
> event=, edata=) at Transform.cc:816
> #2 0x006970f4 in handleEvent (this=0x2b109f266010, e=0x2b110006f360,
> calling_code=1) at I_Continuation.h:146
> #3 EThread::process_event (this=0x2b109f266010, e=0x2b110006f360,
> calling_code=1) at UnixEThread.cc:142
> #4 0x00697b6b in EThread::execute (this=0x2b109f266010) at
> UnixEThread.cc:191
> #5 0x004c28c9 in main (argc=, argv= optimized out>) at Main.cc:1822
> {noformat}
> From /var/log/messages:
> {noformat}
> Feb 16 11:43:26 l4 kernel: [ET_NET 18][16876]: segfault at 155 ip
> 00567571 sp 2b04d1412b40 error 4 in
> traffic_server[40+341000]
> {noformat}
> From traffic.out:
> {noformat}
> /home/y/bin/traffic_server - STACK TRACE:
> /lib64/libpthread.so.0[0x31f8c0f500]
> /home/y/bin/traffic_server(_ZN14RangeTransform18transform_to_rangeEv+0x83)[0x4e4b63]
> /home/y/bin/traffic_server(_ZN14RangeTransform12handle_eventEiPv+0x158)[0x4e52e8]
> /home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0xb4)[0x6970f4]
> /home/y/bin/traffic_server(_ZN7EThread7executeEv+0x5ab)[0x697b6b]
> /home/y/bin/traffic_server[0x6960c2]
> /lib64/libpthread.so.0[0x31f8c07851]
> /lib64/libc.so.6(clone+0x6d)[0x31f88e76dd]
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1776) Range requests not working right in 3.2.4
[ https://issues.apache.org/jira/browse/TS-1776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13613388#comment-13613388 ] William Bardwell commented on TS-1776: -- The fix for TS-1574 (commit 1199e991424d8495a80075718d8ec95a64f3a712) has most of the same fixes but done differently (based on the new range stuff being active in more cases, and a few changes in the 3.3.X code line.) (But it doesn't fix the content-length issues, although they may not happen in the read_while_writer cases since it doesn't have a known content-length anyway.) > Range requests not working right in 3.2.4 > - > > Key: TS-1776 > URL: https://issues.apache.org/jira/browse/TS-1776 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: William Bardwell > > With the patch in 3.2.4 for TS-1575 that tries to turn off the new range > code, range requests aren't work right for me. The responses have all of the > multi-part header markings, but the Content-Length and Content-Range headers > should be used for single range requests. Also when I do a range that starts > > 0, the content is wrong. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1776) Range requests not working right in 3.2.4
[ https://issues.apache.org/jira/browse/TS-1776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13613377#comment-13613377 ] William Bardwell commented on TS-1776: -- It seems like the changes to try to add fancy range support left behind the old transform code, but missing the handling for calculating the proper content-length. And the full content length is used to start writing the data, and the change_response_headers() now unconditionally does multipart stuff. Also the code in HttpTunnel calculates read_start_pos and does a do_io_pread() to seek even when the fix has claimed that pread() shouldn't be used, and the RangeTransform code is going to try to do the seeking by skipping. (So now the start skip amount get skipped twice.) > Range requests not working right in 3.2.4 > - > > Key: TS-1776 > URL: https://issues.apache.org/jira/browse/TS-1776 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: William Bardwell > > With the patch in 3.2.4 for TS-1575 that tries to turn off the new range > code, range requests aren't work right for me. The responses have all of the > multi-part header markings, but the Content-Length and Content-Range headers > should be used for single range requests. Also when I do a range that starts > > 0, the content is wrong. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1776) Range requests not working right in 3.2.4
William Bardwell created TS-1776: Summary: Range requests not working right in 3.2.4 Key: TS-1776 URL: https://issues.apache.org/jira/browse/TS-1776 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: William Bardwell With the patch in 3.2.4 for TS-1575 that tries to turn off the new range code, range requests aren't work right for me. The responses have all of the multi-part header markings, but the Content-Length and Content-Range headers should be used for single range requests. Also when I do a range that starts > 0, the content is wrong. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1717) static library build fails with duplicate symbols
[ https://issues.apache.org/jira/browse/TS-1717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13613324#comment-13613324 ] Uri Shachar commented on TS-1717: - I've had a go at this -- didn't end well :-( Getting just libtsutil in statically is easy enough -- getting a clean, completely static build is a different story. In any case, a first step would be to remove the AC_DISABLE_STATIC from configure.ac -- I missed it and spent hours trying to figure out why libtool was ignoring me > static library build fails with duplicate symbols > - > > Key: TS-1717 > URL: https://issues.apache.org/jira/browse/TS-1717 > Project: Traffic Server > Issue Type: Bug > Components: Build >Reporter: James Peach >Assignee: James Peach > Fix For: 3.3.2 > > > fish:trafficserver.git jpeach$ ./config.nice --disable-shared --enable-static > && make -j && sudo make install > ... > CXXLDtraffic_manager > AR libmgmt_p.a > duplicate symbol _diags in: > Main.o > ../lib/ts/.libs/libtsutil.a(Diags.o) > ld: 1 duplicate symbol for architecture x86_64 > example/app-template/app-template.cc://Diags *diags = NULL; > iocore/aio/test_AIO.i:Diags *diags; > iocore/cluster/test_I_Cluster.cc:Diags *diags; > iocore/cluster/test_P_Cluster.cc:Diags *diags; > iocore/dns/test_I_DNS.cc:Diags *diags; > iocore/dns/test_P_DNS.cc:Diags *diags; > iocore/eventsystem/test_Buffer.cc:Diags *diags; > iocore/eventsystem/test_Event.i:Diags *diags; > iocore/hostdb/test_I_HostDB.cc:Diags *diags; > iocore/hostdb/test_P_HostDB.cc:Diags *diags; > iocore/net/test_I_Net.cc:Diags *diags; > iocore/net/test_I_UDPNet.cc:Diags *diags; > iocore/net/test_P_Net.cc:Diags *diags; > iocore/net/test_P_UDPNet.cc:Diags *diags; > iocore/utils/diags.i://Diags *diags; > lib/records/I_RecCore.h:int RecSetDiags(Diags * diags); > lib/records/I_RecLocal.h:int RecLocalInit(Diags * diags = NULL); > lib/records/I_RecProcess.h:int RecProcessInit(RecModeT mode_type, Diags * > diags = NULL); > lib/records/P_RecCore.h:int RecCoreInit(RecModeT mode_type, Diags * diags); > lib/records/RecCore.cc:Diags *g_diags = NULL; > lib/records/RecCore.cc:RecCoreInit(RecModeT mode_type, Diags *_diags) > lib/records/RecCore.cc:RecSetDiags(Diags * _diags) > lib/records/RecLocal.cc:RecLocalInit(Diags * _diags) > lib/records/RecProcess.cc:RecProcessInit(RecModeT mode_type, Diags *_diags) > lib/records/RecUtils.cc:extern Diags *g_diags; > lib/records/test_I_RecLocal.cc:Diags *diags = NULL; > lib/records/test_RecProcess.i:Diags *diags = NULL; > lib/ts/Diags.cc:inkcoreapi Diags *diags = NULL; > lib/ts/Diags.h:extern inkcoreapi Diags *diags; > mgmt/Main.cc:inkcoreapi Diags *diags; > proxy/DiagsConfig.h: Diags *diags; > proxy/Initialize.h:extern Diags *diags; > proxy/Main.cc://inkcoreapi Diags *diags = NULL; > proxy/hdrs/load_http_hdr.cc://Diags *diags; > proxy/logging/LogStandalone.cc:Diags *diags = NULL; > Additionally, AFAICT diags.i is not used and can be removed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1541) forward proxy should be able to be configured to prefer IPv6 over IPv4 for outbond connections
[ https://issues.apache.org/jira/browse/TS-1541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-1541: Fix Version/s: (was: 3.3.4) 3.3.1 > forward proxy should be able to be configured to prefer IPv6 over IPv4 for > outbond connections > -- > > Key: TS-1541 > URL: https://issues.apache.org/jira/browse/TS-1541 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Affects Versions: 3.2.0 > Environment: Debian Sid amd64, with ATS/3.2.0 >Reporter: Aron Xu >Assignee: Alan M. Carroll > Fix For: 3.3.1 > > > When the forward proxy cache server is connected to a dual stack network > which both IPv4 and IPv6 are available, it should be able to be configured to > prefer IPv6 over IPv4 for outbond connections, as it's now a common behavior > of various software including all mainstream web browsers. > I didn't check the code but now there seems to be no such a switch to tweak > the preferred protocol, and it seems it prefers IPv4 over IPv6 (or maybe it's > because DNS resolving is faster for IPv4?). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TS-1541) forward proxy should be able to be configured to prefer IPv6 over IPv4 for outbond connections
[ https://issues.apache.org/jira/browse/TS-1541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll closed TS-1541. --- Resolution: Implemented The TS-1307 enhancement should handle this as a subcase (by specifying "ip-resolve=ipv6,ipv4" as a proxy port option. > forward proxy should be able to be configured to prefer IPv6 over IPv4 for > outbond connections > -- > > Key: TS-1541 > URL: https://issues.apache.org/jira/browse/TS-1541 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Affects Versions: 3.2.0 > Environment: Debian Sid amd64, with ATS/3.2.0 >Reporter: Aron Xu >Assignee: Alan M. Carroll > Fix For: 3.3.4 > > > When the forward proxy cache server is connected to a dual stack network > which both IPv4 and IPv6 are available, it should be able to be configured to > prefer IPv6 over IPv4 for outbond connections, as it's now a common behavior > of various software including all mainstream web browsers. > I didn't check the code but now there seems to be no such a switch to tweak > the preferred protocol, and it seems it prefers IPv4 over IPv6 (or maybe it's > because DNS resolving is faster for IPv4?). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1775) Cleanup of ink_hrtime.{cc,h}
[
https://issues.apache.org/jira/browse/TS-1775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13613262#comment-13613262
]
Leif Hedstrom commented on TS-1775:
---
It seems some of the wrappers in ink_hrtime.h() might no longer be used either,
e.g. ink_gettimeofday() is never used, so lets get rid of that shit.
> Cleanup of ink_hrtime.{cc,h}
>
>
> Key: TS-1775
> URL: https://issues.apache.org/jira/browse/TS-1775
> Project: Traffic Server
> Issue Type: Improvement
>Reporter: Leif Hedstrom
>
> A few things comes to mind:
> 1) Why do we have a NEED_HRTIME define? It's always on as far as I can tell,
> and I can't imagine there's a reason to not have it on (it'd completely break
> like everything, in fact it would fail to compile since gethrtime() doesn't
> exist?).
> 2) We should eliminate the USE_TIME_STAMP_COUNTER_HRTIME define, and the code
> that implements our own TSC code. Modern Unix flavors implements this already
> in various way (e.g. glibc's gettimeofday() wrapper has a TSC user space
> implementation).
> 3) On FreeBSD, jpeach points out that CLOCK_REALTIME is probably not the
> optimal way to use clock_gettime(). He suggest using CLOCK_REALTIME_FAST or
> CLOCK_MONOTONIC_FAST which is similar to the optimizations done with TSC for
> gettimeofday() on linux.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1775) Cleanup of ink_hrtime.{cc,h}
[
https://issues.apache.org/jira/browse/TS-1775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13613259#comment-13613259
]
James Peach commented on TS-1775:
-
http://stackoverflow.com/questions/6498972/faster-equivalent-of-gettimeofday
> Cleanup of ink_hrtime.{cc,h}
>
>
> Key: TS-1775
> URL: https://issues.apache.org/jira/browse/TS-1775
> Project: Traffic Server
> Issue Type: Improvement
>Reporter: Leif Hedstrom
>
> A few things comes to mind:
> 1) Why do we have a NEED_HRTIME define? It's always on as far as I can tell,
> and I can't imagine there's a reason to not have it on (it'd completely break
> like everything, in fact it would fail to compile since gethrtime() doesn't
> exist?).
> 2) We should eliminate the USE_TIME_STAMP_COUNTER_HRTIME define, and the code
> that implements our own TSC code. Modern Unix flavors implements this already
> in various way (e.g. glibc's gettimeofday() wrapper has a TSC user space
> implementation).
> 3) On FreeBSD, jpeach points out that CLOCK_REALTIME is probably not the
> optimal way to use clock_gettime(). He suggest using CLOCK_REALTIME_FAST or
> CLOCK_MONOTONIC_FAST which is similar to the optimizations done with TSC for
> gettimeofday() on linux.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1775) Cleanup of ink_hrtime.{cc,h}
[
https://issues.apache.org/jira/browse/TS-1775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13613253#comment-13613253
]
Leif Hedstrom commented on TS-1775:
---
Looking some more, it seems ink_get_based_hrtime_internal() is not only
pointless (since we don't support USE_TIME_STAMP_COUNTER_HRTIME), it's also
confusing in that on Linux, it'll end up using clock_gettime(). And it doesn't
do the right thing at all on FreeBSD. I say we get rid of
ink_get_based_hrtime_internal() completely, in favor of
ink_get_hrtime_internal() and ink_get_hrtime() (for Thread's).
> Cleanup of ink_hrtime.{cc,h}
>
>
> Key: TS-1775
> URL: https://issues.apache.org/jira/browse/TS-1775
> Project: Traffic Server
> Issue Type: Improvement
>Reporter: Leif Hedstrom
>
> A few things comes to mind:
> 1) Why do we have a NEED_HRTIME define? It's always on as far as I can tell,
> and I can't imagine there's a reason to not have it on (it'd completely break
> like everything, in fact it would fail to compile since gethrtime() doesn't
> exist?).
> 2) We should eliminate the USE_TIME_STAMP_COUNTER_HRTIME define, and the code
> that implements our own TSC code. Modern Unix flavors implements this already
> in various way (e.g. glibc's gettimeofday() wrapper has a TSC user space
> implementation).
> 3) On FreeBSD, jpeach points out that CLOCK_REALTIME is probably not the
> optimal way to use clock_gettime(). He suggest using CLOCK_REALTIME_FAST or
> CLOCK_MONOTONIC_FAST which is similar to the optimizations done with TSC for
> gettimeofday() on linux.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1775) Cleanup of ink_hrtime.{cc,h}
Leif Hedstrom created TS-1775:
-
Summary: Cleanup of ink_hrtime.{cc,h}
Key: TS-1775
URL: https://issues.apache.org/jira/browse/TS-1775
Project: Traffic Server
Issue Type: Improvement
Reporter: Leif Hedstrom
A few things comes to mind:
1) Why do we have a NEED_HRTIME define? It's always on as far as I can tell,
and I can't imagine there's a reason to not have it on (it'd completely break
like everything, in fact it would fail to compile since gethrtime() doesn't
exist?).
2) We should eliminate the USE_TIME_STAMP_COUNTER_HRTIME define, and the code
that implements our own TSC code. Modern Unix flavors implements this already
in various way (e.g. glibc's gettimeofday() wrapper has a TSC user space
implementation).
3) On FreeBSD, jpeach points out that CLOCK_REALTIME is probably not the
optimal way to use clock_gettime(). He suggest using CLOCK_REALTIME_FAST or
CLOCK_MONOTONIC_FAST which is similar to the optimizations done with TSC for
gettimeofday() on linux.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1774) Make ink_hrtime_get() in Thread.cc member of the Thread class
Leif Hedstrom created TS-1774: - Summary: Make ink_hrtime_get() in Thread.cc member of the Thread class Key: TS-1774 URL: https://issues.apache.org/jira/browse/TS-1774 Project: Traffic Server Issue Type: Improvement Components: Core Reporter: Leif Hedstrom It's somewhat confusing that e..g ink_get_hrtime() is not a member of the Thread class, yet, relies on Thread::cur_time. Why is that ? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1403) f_inbound_transparency is not handled by all accept cases
[ https://issues.apache.org/jira/browse/TS-1403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uri Shachar updated TS-1403: Assignee: Uri Shachar > f_inbound_transparency is not handled by all accept cases > - > > Key: TS-1403 > URL: https://issues.apache.org/jira/browse/TS-1403 > Project: Traffic Server > Issue Type: Bug > Components: Network >Affects Versions: 3.2.0 >Reporter: Yossi Gottlieb >Assignee: Uri Shachar >Priority: Minor > Fix For: sometime > > Attachments: transparency.diff > > > The inbound transparency flag does not always take affect, depending on the > accept configuration. This is not currently an issue because TSAPI doesn't > provide a standard transparent accept API, but it will become an issue once > the interface is created. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1540) better handle of the over connection warnings
[
https://issues.apache.org/jira/browse/TS-1540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13613207#comment-13613207
]
Leif Hedstrom commented on TS-1540:
---
yongming; This looks like a Debug() message, is this running with tracers on ?
I agree with the stats though, but it wouldn't be per host, just a "total".
> better handle of the over connection warnings
> -
>
> Key: TS-1540
> URL: https://issues.apache.org/jira/browse/TS-1540
> Project: Traffic Server
> Issue Type: Improvement
> Components: HTTP
>Affects Versions: 3.3.0
> Environment: taobao own issue here
>Reporter: Zhao Yongming
>Assignee: Leif Hedstrom
> Fix For: 3.3.2
>
>
> on a high load server, we get many WARNINGs in the traffic.out, which result
> into about 500iops disk write, we may need to decrease the logging speed or
> convert it to some stats instead.
> {code}
> [Oct 18 12:30:29.015] Server {0x2b0b5e24d700} WARNING: [874028856] over the
> number of connection for this host: 253840494
> [Oct 18 12:30:29.015] Server {0x2b0b5e44f700} WARNING: [874058392] over the
> number of connection for this host: 253840494
> [Oct 18 12:30:29.015] Server {0x2b0b5e752700} WARNING: [874102720] over the
> number of connection for this host: 253840494
> [Oct 18 12:30:29.015] Server {0x2b0b5e853700} WARNING: [873849436] over the
> number of connection for this host: 253840494
> [Oct 18 12:30:29.015] Server {0x2b0b5d1b8c00} WARNING: [874091635] over the
> number of connection for this host: 253840494
> [Oct 18 12:30:29.015] Server {0x2b0b5e954700} WARNING: [874102614] over the
> number of connection for this host: 253840494
> [Oct 18 12:30:29.015] Server {0x2b0b5e34e700} WARNING: [874008652] over the
> number of connection for this host: 253840494
> [Oct 18 12:30:29.016] Server {0x2b0b5e550700} WARNING: [874102763] over the
> number of connection for this host: 253840494
> [Oct 18 12:30:29.016] Server {0x2b0b5e550700} WARNING: [874099447] over the
> number of connection for this host: 253840494
> [Oct 18 12:30:29.016] Server {0x2b0b5d1b8c00} WARNING: [874124453] over the
> number of connection for this host: 253840494
> [Oct 18 12:30:29.020] Server {0x2b0b5e853700} WARNING: [874119636] over the
> number of connection for this host: 253840494
> [Oct 18 12:30:29.020] Server {0x2b0b5e44f700} WARNING: [874119708] over the
> number of connection for this host: 253840494
> [Oct 18 12:30:29.020] Server {0x2b0b5e853700} WARNING: [874034770] over the
> number of connection for this host: 253840494
> [Oct 18 12:30:29.020] Server {0x2b0b5e954700} WARNING: [874107245] over the
> number of connection for this host: 253840494
> [Oct 18 12:30:29.020] Server {0x2b0b5e44f700} WARNING: [874024156] over the
> number of connection for this host: 253840494
> [Oct 18 12:30:29.020] Server {0x2b0b5e24d700} WARNING: [874118129] over the
> number of connection for this host: 253840494
> [Oct 18 12:30:29.020] Server {0x2b0b5e44f700} WARNING: [874123046] over the
> number of connection for this host: 253840494
> [Oct 18 12:30:29.020] Server {0x2b0b5e954700} WARNING: [874121399] over the
> number of connection for this host: 253840494
> [Oct 18 12:30:29.020] Server {0x2b0b5e651700} WARNING: [873939682] over the
> number of connection for this host: 253840494
> [Oct 18 12:30:29.020] Server {0x2b0b5e550700} WARNING: [874043351] over the
> number of connection for this host: 253840494
> [Oct 18 12:30:29.020] Server {0x2b0b5e651700} WARNING: [874116643] over the
> number of connection for this host: 253840494
> [Oct 18 12:30:29.020] Server {0x2b0b5e34e700} WARNING: [874072524] over the
> number of connection for this host: 253840494
> [Oct 18 12:30:29.020] Server {0x2b0b5e752700} WARNING: [874031734] over the
> number of connection for this host: 253840494
> [Oct 18 12:30:29.020] Server {0x2b0b5e651700} WARNING: [874107262] over the
> number of connection for this host: 253840494
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1586) spdy plugin doesn't build under latest trunk
[
https://issues.apache.org/jira/browse/TS-1586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13613186#comment-13613186
]
Leif Hedstrom commented on TS-1586:
---
Where are we on this one? James ?
> spdy plugin doesn't build under latest trunk
>
>
> Key: TS-1586
> URL: https://issues.apache.org/jira/browse/TS-1586
> Project: Traffic Server
> Issue Type: Bug
> Components: Build, Plugins
>Affects Versions: 3.3.1
> Environment: llvm/clang from trunk (on Linux, haven't tested on other
> platforms yet)
>Reporter: Igor Galić
>Assignee: Igor Galić
> Fix For: 3.3.2
>
> Attachments: restrict.patch
>
>
> {noformat}
> Making all in spdy
> gmake[3]: Entering directory
> `/home/igalic/src/asf/trafficserver/CLANG/plugins/experimental/spdy'
> /bin/sh ../../../libtool --tag=CXX --mode=compile clang++ -DHAVE_CONFIG_H
> -I. -I../../../../plugins/experimental/spdy -I../../../lib/ts
> -I../../../../plugins/experimental/spdy/lib -I../../../proxy/api
> -D__STDC_FORMAT_MACROS=1 -D_LARGEFILE64_SOURCE=1 -D_COMPILE64BIT_SOURCE=1
> -D_GNU_SOURCE -D_REENTRANT -Dlinux -DDEBUG -D_DEBUG -std=c++11 -ggdb3
> -Werror -Qunused-arguments -Wno-invalid-offsetof -MT message.lo -MD -MP -MF
> .deps/message.Tpo -c -o message.lo `test -f 'lib/spdy/message.cc' || echo
> '../../../../plugins/experimental/spdy/'`lib/spdy/message.cc
> libtool: compile: clang++ -DHAVE_CONFIG_H -I.
> -I../../../../plugins/experimental/spdy -I../../../lib/ts
> -I../../../../plugins/experimental/spdy/lib -I../../../proxy/api
> -D__STDC_FORMAT_MACROS=1 -D_LARGEFILE64_SOURCE=1 -D_COMPILE64BIT_SOURCE=1
> -D_GNU_SOURCE -D_REENTRANT -Dlinux -DDEBUG -D_DEBUG -std=c++11 -ggdb3 -Werror
> -Qunused-arguments -Wno-invalid-offsetof -MT message.lo -MD -MP -MF
> .deps/message.Tpo -c
> ../../../../plugins/experimental/spdy/lib/spdy/message.cc -fPIC -DPIC -o
> .libs/message.o
> ../../../../plugins/experimental/spdy/lib/spdy/message.cc:72:23: error:
> restrict requires a pointer or reference ('uint8_t' (aka 'unsigned char') is
> invalid)
> extract(const uint8_t __restrict * &ptr) {
> ~~^~
> ../../../../plugins/experimental/spdy/lib/spdy/message.cc:80:32: error:
> restrict requires a pointer or reference ('uint8_t' (aka 'unsigned char') is
> invalid)
> extract(const uint8_t __restrict * &ptr) {
> ~~^~
> ../../../../plugins/experimental/spdy/lib/spdy/message.cc:85:30: error:
> restrict requires a pointer or reference ('uint8_t' (aka 'unsigned char') is
> invalid)
> insert(const T& val, uint8_t __restrict * &ptr) {
> ^~
> ../../../../plugins/experimental/spdy/lib/spdy/message.cc:91:33: error:
> restrict requires a pointer or reference ('uint8_t' (aka 'unsigned char') is
> invalid)
> extract_stream_id(const uint8_t __restrict * &ptr)
> ~~^~
> ../../../../plugins/experimental/spdy/lib/spdy/message.cc:97:46: error:
> restrict requires a pointer or reference ('uint8_t' (aka 'unsigned char') is
> invalid)
> insert_stream_id(uint32_t stream_id, uint8_t __restrict * &ptr)
> ^~
> ../../../../plugins/experimental/spdy/lib/spdy/message.cc:104:23: error:
> restrict requires a pointer or reference ('uint8_t' (aka 'unsigned char') is
> invalid)
> const uint8_t __restrict * ptr, size_t len)
> ~~^~
> ../../../../plugins/experimental/spdy/lib/spdy/message.cc:133:44: error:
> restrict requires a pointer or reference ('uint8_t' (aka 'unsigned char') is
> invalid)
> const message_header& msg, uint8_t __restrict * ptr, size_t len)
>^~
> ../../../../plugins/experimental/spdy/lib/spdy/message.cc:153:23: error:
> restrict requires a pointer or reference ('uint8_t' (aka 'unsigned char') is
> invalid)
> const uint8_t __restrict * ptr, size_t len)
> ~~^~
> ../../../../plugins/experimental/spdy/lib/spdy/message.cc:170:23: error:
> restrict requires a pointer or reference ('uint8_t' (aka 'unsigned char') is
> invalid)
> const uint8_t __restrict * ptr, size_t len)
> ~~^~
> ../../../../plugins/experimental/spdy/lib/spdy/message.cc:185:23: error:
> restrict requires a pointer or reference ('uint8_t' (aka 'unsigned char') is
> invalid)
> const uint8_t __restrict * ptr, size_t len)
> ~~^~
> ../../../../plugins/experimental/spdy/lib/spdy/message.cc:200:48: error:
> restrict requires a pointer or reference ('uint8_t' (aka 'unsigned char') is
> invalid)
> const rst_stream_message& msg, uint8_t __restrict * ptr, size_t len)
>
[jira] [Updated] (TS-1586) spdy plugin doesn't build under latest trunk
[
https://issues.apache.org/jira/browse/TS-1586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1586:
--
Component/s: Plugins
Build
> spdy plugin doesn't build under latest trunk
>
>
> Key: TS-1586
> URL: https://issues.apache.org/jira/browse/TS-1586
> Project: Traffic Server
> Issue Type: Bug
> Components: Build, Plugins
>Affects Versions: 3.3.1
> Environment: llvm/clang from trunk (on Linux, haven't tested on other
> platforms yet)
>Reporter: Igor Galić
>Assignee: Igor Galić
> Fix For: 3.3.2
>
> Attachments: restrict.patch
>
>
> {noformat}
> Making all in spdy
> gmake[3]: Entering directory
> `/home/igalic/src/asf/trafficserver/CLANG/plugins/experimental/spdy'
> /bin/sh ../../../libtool --tag=CXX --mode=compile clang++ -DHAVE_CONFIG_H
> -I. -I../../../../plugins/experimental/spdy -I../../../lib/ts
> -I../../../../plugins/experimental/spdy/lib -I../../../proxy/api
> -D__STDC_FORMAT_MACROS=1 -D_LARGEFILE64_SOURCE=1 -D_COMPILE64BIT_SOURCE=1
> -D_GNU_SOURCE -D_REENTRANT -Dlinux -DDEBUG -D_DEBUG -std=c++11 -ggdb3
> -Werror -Qunused-arguments -Wno-invalid-offsetof -MT message.lo -MD -MP -MF
> .deps/message.Tpo -c -o message.lo `test -f 'lib/spdy/message.cc' || echo
> '../../../../plugins/experimental/spdy/'`lib/spdy/message.cc
> libtool: compile: clang++ -DHAVE_CONFIG_H -I.
> -I../../../../plugins/experimental/spdy -I../../../lib/ts
> -I../../../../plugins/experimental/spdy/lib -I../../../proxy/api
> -D__STDC_FORMAT_MACROS=1 -D_LARGEFILE64_SOURCE=1 -D_COMPILE64BIT_SOURCE=1
> -D_GNU_SOURCE -D_REENTRANT -Dlinux -DDEBUG -D_DEBUG -std=c++11 -ggdb3 -Werror
> -Qunused-arguments -Wno-invalid-offsetof -MT message.lo -MD -MP -MF
> .deps/message.Tpo -c
> ../../../../plugins/experimental/spdy/lib/spdy/message.cc -fPIC -DPIC -o
> .libs/message.o
> ../../../../plugins/experimental/spdy/lib/spdy/message.cc:72:23: error:
> restrict requires a pointer or reference ('uint8_t' (aka 'unsigned char') is
> invalid)
> extract(const uint8_t __restrict * &ptr) {
> ~~^~
> ../../../../plugins/experimental/spdy/lib/spdy/message.cc:80:32: error:
> restrict requires a pointer or reference ('uint8_t' (aka 'unsigned char') is
> invalid)
> extract(const uint8_t __restrict * &ptr) {
> ~~^~
> ../../../../plugins/experimental/spdy/lib/spdy/message.cc:85:30: error:
> restrict requires a pointer or reference ('uint8_t' (aka 'unsigned char') is
> invalid)
> insert(const T& val, uint8_t __restrict * &ptr) {
> ^~
> ../../../../plugins/experimental/spdy/lib/spdy/message.cc:91:33: error:
> restrict requires a pointer or reference ('uint8_t' (aka 'unsigned char') is
> invalid)
> extract_stream_id(const uint8_t __restrict * &ptr)
> ~~^~
> ../../../../plugins/experimental/spdy/lib/spdy/message.cc:97:46: error:
> restrict requires a pointer or reference ('uint8_t' (aka 'unsigned char') is
> invalid)
> insert_stream_id(uint32_t stream_id, uint8_t __restrict * &ptr)
> ^~
> ../../../../plugins/experimental/spdy/lib/spdy/message.cc:104:23: error:
> restrict requires a pointer or reference ('uint8_t' (aka 'unsigned char') is
> invalid)
> const uint8_t __restrict * ptr, size_t len)
> ~~^~
> ../../../../plugins/experimental/spdy/lib/spdy/message.cc:133:44: error:
> restrict requires a pointer or reference ('uint8_t' (aka 'unsigned char') is
> invalid)
> const message_header& msg, uint8_t __restrict * ptr, size_t len)
>^~
> ../../../../plugins/experimental/spdy/lib/spdy/message.cc:153:23: error:
> restrict requires a pointer or reference ('uint8_t' (aka 'unsigned char') is
> invalid)
> const uint8_t __restrict * ptr, size_t len)
> ~~^~
> ../../../../plugins/experimental/spdy/lib/spdy/message.cc:170:23: error:
> restrict requires a pointer or reference ('uint8_t' (aka 'unsigned char') is
> invalid)
> const uint8_t __restrict * ptr, size_t len)
> ~~^~
> ../../../../plugins/experimental/spdy/lib/spdy/message.cc:185:23: error:
> restrict requires a pointer or reference ('uint8_t' (aka 'unsigned char') is
> invalid)
> const uint8_t __restrict * ptr, size_t len)
> ~~^~
> ../../../../plugins/experimental/spdy/lib/spdy/message.cc:200:48: error:
> restrict requires a pointer or reference ('uint8_t' (aka 'unsigned char') is
> invalid)
> const rst_stream_message& msg, uint8_t __restrict * ptr, size_t len)
>^~
[jira] [Commented] (TS-1754) Warnings from stats evaluation
[
https://issues.apache.org/jira/browse/TS-1754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13613182#comment-13613182
]
ASF subversion and git services commented on TS-1754:
-
Commit da8ca56ec9cf4e368c2ca4291bfb859bc9e736ff in branch refs/heads/master
from [~zwoop]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=da8ca56 ]
Added TS-1754
> Warnings from stats evaluation
> --
>
> Key: TS-1754
> URL: https://issues.apache.org/jira/browse/TS-1754
> Project: Traffic Server
> Issue Type: Bug
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 3.3.2
>
> Attachments: 0001-TS-1754-Remove-warning-info-in-StatBinaryEval.patch
>
>
> After 5bcc19e6, I'm seeing these warnings:
> {code}
> [Mar 18 12:52:05.669] Manager {0x77b70840} WARNING: Both two token type
> are RECD_NULL.
> [Mar 18 12:52:05.669] Manager {0x77b70840} WARNING: Both two token type
> are RECD_NULL.
> [Mar 18 12:52:05.669] Manager {0x77b70840} WARNING: Both two token type
> are RECD_NULL.
> [Mar 18 12:52:05.669] Manager {0x77b70840} WARNING: Both two token type
> are RECD_NULL.
> [Mar 18 12:52:05.669] Manager {0x77b70840} WARNING: Both two token type
> are RECD_NULL.
> ...
> {code}
> There are quite a few of them.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1754) Warnings from stats evaluation
[
https://issues.apache.org/jira/browse/TS-1754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1754:
--
Component/s: Stats
> Warnings from stats evaluation
> --
>
> Key: TS-1754
> URL: https://issues.apache.org/jira/browse/TS-1754
> Project: Traffic Server
> Issue Type: Bug
> Components: Stats
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 3.3.2
>
> Attachments: 0001-TS-1754-Remove-warning-info-in-StatBinaryEval.patch
>
>
> After 5bcc19e6, I'm seeing these warnings:
> {code}
> [Mar 18 12:52:05.669] Manager {0x77b70840} WARNING: Both two token type
> are RECD_NULL.
> [Mar 18 12:52:05.669] Manager {0x77b70840} WARNING: Both two token type
> are RECD_NULL.
> [Mar 18 12:52:05.669] Manager {0x77b70840} WARNING: Both two token type
> are RECD_NULL.
> [Mar 18 12:52:05.669] Manager {0x77b70840} WARNING: Both two token type
> are RECD_NULL.
> [Mar 18 12:52:05.669] Manager {0x77b70840} WARNING: Both two token type
> are RECD_NULL.
> ...
> {code}
> There are quite a few of them.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1754) Warnings from stats evaluation
[
https://issues.apache.org/jira/browse/TS-1754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13613183#comment-13613183
]
ASF subversion and git services commented on TS-1754:
-
Commit 0e599c331b7d7b6e302f0ef1482530f2d3a479bc in branch refs/heads/master
from [~yunkai]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=0e599c3 ]
TS-1754 Warnings from stats evaluation.
> Warnings from stats evaluation
> --
>
> Key: TS-1754
> URL: https://issues.apache.org/jira/browse/TS-1754
> Project: Traffic Server
> Issue Type: Bug
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 3.3.2
>
> Attachments: 0001-TS-1754-Remove-warning-info-in-StatBinaryEval.patch
>
>
> After 5bcc19e6, I'm seeing these warnings:
> {code}
> [Mar 18 12:52:05.669] Manager {0x77b70840} WARNING: Both two token type
> are RECD_NULL.
> [Mar 18 12:52:05.669] Manager {0x77b70840} WARNING: Both two token type
> are RECD_NULL.
> [Mar 18 12:52:05.669] Manager {0x77b70840} WARNING: Both two token type
> are RECD_NULL.
> [Mar 18 12:52:05.669] Manager {0x77b70840} WARNING: Both two token type
> are RECD_NULL.
> [Mar 18 12:52:05.669] Manager {0x77b70840} WARNING: Both two token type
> are RECD_NULL.
> ...
> {code}
> There are quite a few of them.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-1754) Warnings from stats evaluation
[
https://issues.apache.org/jira/browse/TS-1754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom reassigned TS-1754:
-
Assignee: Leif Hedstrom
> Warnings from stats evaluation
> --
>
> Key: TS-1754
> URL: https://issues.apache.org/jira/browse/TS-1754
> Project: Traffic Server
> Issue Type: Bug
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 3.3.2
>
> Attachments: 0001-TS-1754-Remove-warning-info-in-StatBinaryEval.patch
>
>
> After 5bcc19e6, I'm seeing these warnings:
> {code}
> [Mar 18 12:52:05.669] Manager {0x77b70840} WARNING: Both two token type
> are RECD_NULL.
> [Mar 18 12:52:05.669] Manager {0x77b70840} WARNING: Both two token type
> are RECD_NULL.
> [Mar 18 12:52:05.669] Manager {0x77b70840} WARNING: Both two token type
> are RECD_NULL.
> [Mar 18 12:52:05.669] Manager {0x77b70840} WARNING: Both two token type
> are RECD_NULL.
> [Mar 18 12:52:05.669] Manager {0x77b70840} WARNING: Both two token type
> are RECD_NULL.
> ...
> {code}
> There are quite a few of them.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1773) Consistently use ink_atoi() (or one of the equivalent functions we provide)
[ https://issues.apache.org/jira/browse/TS-1773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1773: -- Fix Version/s: 3.3.3 > Consistently use ink_atoi() (or one of the equivalent functions we provide) > --- > > Key: TS-1773 > URL: https://issues.apache.org/jira/browse/TS-1773 > Project: Traffic Server > Issue Type: Bug > Components: Core >Reporter: Leif Hedstrom > Fix For: 3.3.3 > > > Most of the code uses ink_atoi(), we should make sure we do so consistently. > In addition, perhaps we want to expose our internal version to plugin APIs, > since it does have additional features compared to atoi() / strtol(). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1773) Consistently use ink_atoi() (or one of the equivalent functions we provide)
Leif Hedstrom created TS-1773: - Summary: Consistently use ink_atoi() (or one of the equivalent functions we provide) Key: TS-1773 URL: https://issues.apache.org/jira/browse/TS-1773 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Leif Hedstrom Most of the code uses ink_atoi(), we should make sure we do so consistently. In addition, perhaps we want to expose our internal version to plugin APIs, since it does have additional features compared to atoi() / strtol(). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1570) remap doesn't reject request whose Host has extra characters after port (like "test.com:80xxx")
[ https://issues.apache.org/jira/browse/TS-1570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1570: -- Fix Version/s: (was: 3.3.4) sometime This is probably an artifact of using ink_atoi(). Moving out for now. > remap doesn't reject request whose Host has extra characters after port (like > "test.com:80xxx") > --- > > Key: TS-1570 > URL: https://issues.apache.org/jira/browse/TS-1570 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Affects Versions: 3.3.0 >Reporter: Conan Wang >Priority: Minor > Fix For: sometime > > > remap.config:map http://test.com http://1.1.1.1 > The request with Host: 'test.com:80xxx' or 'test.com:xxx' will get passed. > Such host is not filtered strictly. > Just report, didn't have big problem for me though. > curl http://127.0.0.1:8080/ -H "Host: test.com:80xxx" > or curl -x 127.0.0.1:8080 http://test.com:80xxx/ -v -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1570) remap doesn't reject request whose Host has extra characters after port (like "test.com:80xxx")
[ https://issues.apache.org/jira/browse/TS-1570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1570: -- Component/s: HTTP > remap doesn't reject request whose Host has extra characters after port (like > "test.com:80xxx") > --- > > Key: TS-1570 > URL: https://issues.apache.org/jira/browse/TS-1570 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Affects Versions: 3.3.0 >Reporter: Conan Wang >Priority: Minor > Fix For: 3.3.4 > > > remap.config:map http://test.com http://1.1.1.1 > The request with Host: 'test.com:80xxx' or 'test.com:xxx' will get passed. > Such host is not filtered strictly. > Just report, didn't have big problem for me though. > curl http://127.0.0.1:8080/ -H "Host: test.com:80xxx" > or curl -x 127.0.0.1:8080 http://test.com:80xxx/ -v -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1448) ATS fails to set user id on (k)FreeBSD
[
https://issues.apache.org/jira/browse/TS-1448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1448:
--
Component/s: Configuration
> ATS fails to set user id on (k)FreeBSD
> --
>
> Key: TS-1448
> URL: https://issues.apache.org/jira/browse/TS-1448
> Project: Traffic Server
> Issue Type: Bug
> Components: Configuration
>Affects Versions: 3.2.0, 3.0.5
>Reporter: Arno Toell
> Fix For: 3.3.4
>
>
> I've tried to start TrafficServer on my ATS kFreeBSD port (which is a FreeBSD
> kernel, just for the records). There, I can't start the traffic_cop because
> of the user it runs at (which is "trafficserver" - working fine on Linux with
> that):
> {code}
> [Sep 9 13:06:09.511] Manager {1024} NOTE: [Alarms::signalAlarm] Server
> Process born
> FATAL: Can't find entry in password file for user: traffics
> /usr/bin/traffic_server - STACK TRACE:
> /usr/lib/trafficserver/libtsutil.so.3(ink_fatal_die+0x94)[0x800b30bd4]
> /usr/bin/traffic_server(_Z14change_uid_gidPKc+0x1bf)[0x4c51cf]
> /usr/bin/traffic_server(main+0x129b)[0x48bd8b]
> /lib/x86_64-kfreebsd-gnu/libc.so.0.1(__libc_start_main+0xa9)[0x802f4e349]
> /usr/bin/traffic_server[0x48fe60]
> {code}
> The code is in proxy/Main.cc, function _change_uid_gid(const char *user)_.
> Chances are, the *user buffer is already cropped I weren't sure how to find
> that out without recompiling the whole thing. Moreover, please note, this
> code in said function looks suspicious as well:
> {code}
> #if defined(freebsd) // TODO: investigate sysconf(_SC_GETPW_R_SIZE_MAX))
> failure
> long buflen = 1024; // or 4096?
> #else
> long buflen = sysconf(_SC_GETPW_R_SIZE_MAX);
> #endif
> if (buflen < 0) {
> ink_fatal_die("sysconf() failed for _SC_GETPW_R_SIZE_MAX");
> }
> {code}
> On FreeBSD, you should use the the UT_NAMESIZE symbol defined in utmp.h.
> P.S. You might want to mark 3.0.5 as released in JIRA ;)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1448) ATS fails to set user id on (k)FreeBSD
[
https://issues.apache.org/jira/browse/TS-1448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13613170#comment-13613170
]
Leif Hedstrom commented on TS-1448:
---
Arno, can you provide a patch for this?
> ATS fails to set user id on (k)FreeBSD
> --
>
> Key: TS-1448
> URL: https://issues.apache.org/jira/browse/TS-1448
> Project: Traffic Server
> Issue Type: Bug
>Affects Versions: 3.2.0, 3.0.5
>Reporter: Arno Toell
> Fix For: 3.3.4
>
>
> I've tried to start TrafficServer on my ATS kFreeBSD port (which is a FreeBSD
> kernel, just for the records). There, I can't start the traffic_cop because
> of the user it runs at (which is "trafficserver" - working fine on Linux with
> that):
> {code}
> [Sep 9 13:06:09.511] Manager {1024} NOTE: [Alarms::signalAlarm] Server
> Process born
> FATAL: Can't find entry in password file for user: traffics
> /usr/bin/traffic_server - STACK TRACE:
> /usr/lib/trafficserver/libtsutil.so.3(ink_fatal_die+0x94)[0x800b30bd4]
> /usr/bin/traffic_server(_Z14change_uid_gidPKc+0x1bf)[0x4c51cf]
> /usr/bin/traffic_server(main+0x129b)[0x48bd8b]
> /lib/x86_64-kfreebsd-gnu/libc.so.0.1(__libc_start_main+0xa9)[0x802f4e349]
> /usr/bin/traffic_server[0x48fe60]
> {code}
> The code is in proxy/Main.cc, function _change_uid_gid(const char *user)_.
> Chances are, the *user buffer is already cropped I weren't sure how to find
> that out without recompiling the whole thing. Moreover, please note, this
> code in said function looks suspicious as well:
> {code}
> #if defined(freebsd) // TODO: investigate sysconf(_SC_GETPW_R_SIZE_MAX))
> failure
> long buflen = 1024; // or 4096?
> #else
> long buflen = sysconf(_SC_GETPW_R_SIZE_MAX);
> #endif
> if (buflen < 0) {
> ink_fatal_die("sysconf() failed for _SC_GETPW_R_SIZE_MAX");
> }
> {code}
> On FreeBSD, you should use the the UT_NAMESIZE symbol defined in utmp.h.
> P.S. You might want to mark 3.0.5 as released in JIRA ;)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1448) ATS fails to set user id on (k)FreeBSD
[
https://issues.apache.org/jira/browse/TS-1448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1448:
--
Fix Version/s: (was: 3.3.4)
3.3.2
> ATS fails to set user id on (k)FreeBSD
> --
>
> Key: TS-1448
> URL: https://issues.apache.org/jira/browse/TS-1448
> Project: Traffic Server
> Issue Type: Bug
> Components: Configuration
>Affects Versions: 3.2.0, 3.0.5
>Reporter: Arno Toell
> Fix For: 3.3.2
>
>
> I've tried to start TrafficServer on my ATS kFreeBSD port (which is a FreeBSD
> kernel, just for the records). There, I can't start the traffic_cop because
> of the user it runs at (which is "trafficserver" - working fine on Linux with
> that):
> {code}
> [Sep 9 13:06:09.511] Manager {1024} NOTE: [Alarms::signalAlarm] Server
> Process born
> FATAL: Can't find entry in password file for user: traffics
> /usr/bin/traffic_server - STACK TRACE:
> /usr/lib/trafficserver/libtsutil.so.3(ink_fatal_die+0x94)[0x800b30bd4]
> /usr/bin/traffic_server(_Z14change_uid_gidPKc+0x1bf)[0x4c51cf]
> /usr/bin/traffic_server(main+0x129b)[0x48bd8b]
> /lib/x86_64-kfreebsd-gnu/libc.so.0.1(__libc_start_main+0xa9)[0x802f4e349]
> /usr/bin/traffic_server[0x48fe60]
> {code}
> The code is in proxy/Main.cc, function _change_uid_gid(const char *user)_.
> Chances are, the *user buffer is already cropped I weren't sure how to find
> that out without recompiling the whole thing. Moreover, please note, this
> code in said function looks suspicious as well:
> {code}
> #if defined(freebsd) // TODO: investigate sysconf(_SC_GETPW_R_SIZE_MAX))
> failure
> long buflen = 1024; // or 4096?
> #else
> long buflen = sysconf(_SC_GETPW_R_SIZE_MAX);
> #endif
> if (buflen < 0) {
> ink_fatal_die("sysconf() failed for _SC_GETPW_R_SIZE_MAX");
> }
> {code}
> On FreeBSD, you should use the the UT_NAMESIZE symbol defined in utmp.h.
> P.S. You might want to mark 3.0.5 as released in JIRA ;)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-658) HTTP SM holds the cache write lock for too long
[ https://issues.apache.org/jira/browse/TS-658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-658: - Component/s: HTTP Fix Version/s: (was: 3.3.4) 3.5.0 > HTTP SM holds the cache write lock for too long > --- > > Key: TS-658 > URL: https://issues.apache.org/jira/browse/TS-658 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: Leif Hedstrom > Fix For: 3.5.0 > > > It seems we open the cache for write very early on in the HTTP SM, which can > have very bad effect on performance if the object is not cacheable. It's not > totally clear as to why this is done this way, but we should examine this for > v3.1, and try to minimize how long we hold the lock. It's possible this is > related to read_while_writer, but then it should be modified IMO. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1447) Add USDT probe capability
[ https://issues.apache.org/jira/browse/TS-1447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1447: -- Component/s: Core Fix Version/s: (was: 3.3.4) sometime > Add USDT probe capability > - > > Key: TS-1447 > URL: https://issues.apache.org/jira/browse/TS-1447 > Project: Traffic Server > Issue Type: Bug > Components: Core >Reporter: Phil Sorber >Assignee: Phil Sorber > Fix For: sometime > > > http://www.solarisinternals.com/wiki/index.php/DTrace_Topics_USDT#USDT -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1567) Don't write warning about setuid() when user who starts is the user in records.config
[
https://issues.apache.org/jira/browse/TS-1567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1567:
--
Component/s: Configuration
> Don't write warning about setuid() when user who starts is the user in
> records.config
> -
>
> Key: TS-1567
> URL: https://issues.apache.org/jira/browse/TS-1567
> Project: Traffic Server
> Issue Type: Improvement
> Components: Configuration
>Reporter: Igor Galić
> Fix For: 3.3.4
>
>
> {noformat}
> Can't change user to 'igalic' because running with effective uid=1000
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1463) rfc5861 plugin does not return stale data upon subsequent requests
[ https://issues.apache.org/jira/browse/TS-1463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1463: -- Component/s: Plugins > rfc5861 plugin does not return stale data upon subsequent requests > -- > > Key: TS-1463 > URL: https://issues.apache.org/jira/browse/TS-1463 > Project: Traffic Server > Issue Type: Bug > Components: Plugins >Reporter: Phil Sorber >Assignee: Phil Sorber > Fix For: 3.3.4 > > > Upon subsequent requests the cache returns MISS instead of STALE so the > plugin isn't able to return the stale response properly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1463) rfc5861 plugin does not return stale data upon subsequent requests
[ https://issues.apache.org/jira/browse/TS-1463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1463: -- Component/s: HTTP Cache > rfc5861 plugin does not return stale data upon subsequent requests > -- > > Key: TS-1463 > URL: https://issues.apache.org/jira/browse/TS-1463 > Project: Traffic Server > Issue Type: Bug > Components: Cache, HTTP, Plugins >Reporter: Phil Sorber >Assignee: Phil Sorber > Fix For: 3.3.4 > > > Upon subsequent requests the cache returns MISS instead of STALE so the > plugin isn't able to return the stale response properly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1541) forward proxy should be able to be configured to prefer IPv6 over IPv4 for outbond connections
[ https://issues.apache.org/jira/browse/TS-1541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1541: -- Component/s: HTTP > forward proxy should be able to be configured to prefer IPv6 over IPv4 for > outbond connections > -- > > Key: TS-1541 > URL: https://issues.apache.org/jira/browse/TS-1541 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Affects Versions: 3.2.0 > Environment: Debian Sid amd64, with ATS/3.2.0 >Reporter: Aron Xu >Assignee: Alan M. Carroll > Fix For: 3.3.4 > > > When the forward proxy cache server is connected to a dual stack network > which both IPv4 and IPv6 are available, it should be able to be configured to > prefer IPv6 over IPv4 for outbond connections, as it's now a common behavior > of various software including all mainstream web browsers. > I didn't check the code but now there seems to be no such a switch to tweak > the preferred protocol, and it seems it prefers IPv4 over IPv6 (or maybe it's > because DNS resolving is faster for IPv4?). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1468) vary and accept* are ignored in cache for non-200 responses from the origin - webdav
[ https://issues.apache.org/jira/browse/TS-1468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1468: -- Component/s: HTTP > vary and accept* are ignored in cache for non-200 responses from the origin - > webdav > > > Key: TS-1468 > URL: https://issues.apache.org/jira/browse/TS-1468 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Affects Versions: 3.3.0, 3.2.0 >Reporter: Bryan Call >Assignee: Bryan Call > Fix For: 3.3.4 > > > ATS doesn't look at the Accept* and vary headers when trying to find an > alternate in cache for non-200 responses from the origin. > Webdav is effected because of 207 response from the origin and ATS doesn't > check the Accept* and vary headers. If there is gzipped data in cache and a > non-gzipped request comes in, the gzipped version will be handed back to the > client. > There is an option for YTS to always look at the Accept* and vary headers, > but it is not in ATS. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1326) way to control the ram spaces usage
[ https://issues.apache.org/jira/browse/TS-1326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1326: -- Component/s: Cache Fix Version/s: (was: 3.3.3) sometime > way to control the ram spaces usage > --- > > Key: TS-1326 > URL: https://issues.apache.org/jira/browse/TS-1326 > Project: Traffic Server > Issue Type: Improvement > Components: Cache >Reporter: Zhao Yongming >Priority: Minor > Fix For: sometime > > > we have the ram cache binding to volume and the space is used for all > contents in the volume, with lru. > in some situation, you'd need to give one site for more or less ram cache > because you know they demand it. > we should take the ram space as a control resource, and control it -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1219) Crash report: ink_freelist_new causing core dumps
[
https://issues.apache.org/jira/browse/TS-1219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1219:
--
Component/s: Core
> Crash report: ink_freelist_new causing core dumps
> -
>
> Key: TS-1219
> URL: https://issues.apache.org/jira/browse/TS-1219
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.0.4, 3.0.2
>Reporter: Manjesh Nilange
> Fix For: 3.3.3
>
>
> Our TS based production boxes are seeing a couple of crashes per day with
> stack traces ending in
> #3 0x004c85ea in signal_handler (sig=11) at signals.cc:225
> #4
> #5 0x003312414160 in ink_freelist_new (f=0x3312629ce0) at
> ink_queue.cc:326
> #6 0x00331240d47a in alloc_void (this=0x7fff80173cd8, size=511,
> alignment=1) at Allocator.h:208
> #7 blk_alloc (this=0x7fff80173cd8, size=511, alignment=1) at Arena.cc:45
> #8 Arena::alloc (this=0x7fff80173cd8, size=511, alignment=1) at Arena.cc:118
> #9 0x00569b93 in str_alloc (arena=,
> url=0x31be6a8 "*"...,
> len_in=, len_out=0x7fff80173d20) at
> ../../lib/ts/Arena.h:123
> #10 LogUtils::escapify_url (arena=,
> url=0x31be6a8 "*"...,
> len_in=, len_out=0x7fff80173d20) at LogUtils.cc:392
> #11 0x005482e9 in LogAccessHttp::init (this=0x7fff80173cc0) at
> LogAccessHttp.cc:98
> #12 0x0054b436 in Log::access (lad=0x7fff80173cc0) at Log.cc:1055
> #13 0x004f3085 in HttpSM::update_stats (this=0x2ae5480651e0) at
> HttpSM.cc:6044
> #14 0x004f8918 in HttpSM::kill_this (this=0x2ae5480651e0) at
> HttpSM.cc:6005
> #15 0x004f8c08 in HttpSM::main_handler (this=0x2ae5480651e0,
> event=2301, data=0x2ae548066ec8)
> at HttpSM.cc:2452
> The URL was valid, I just "anonymized" it. This is our environment
> $ uname -a
> Linux xxx.prod 2.6.32-131.4.1.el6.x86_64 #1 SMP Fri Jun 10 10:54:26 EDT 2011
> x86_64 x86_64 x86_64 GNU/Linux
> $ file /usr/bin/traffic_server
> /usr/bin/traffic_server: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
> dynamically linked (uses shared libs), for GNU/Linux 2.6.18, stripped
> There doesn't seem to be more useful information in the frame:
> (gdb) f 5
> #5 0x003312414160 in ink_freelist_new (f=0x3312629ce0) at
> ink_queue.cc:326
> 326 FREELIST_VERSION(item) + 1);
> (gdb) list
> 321 fastalloc_mem_in_use += f->chunk_size * f->type_size;
> 322 #endif
> 323
> 324 } else {
> 325 SET_FREELIST_POINTER_VERSION(next,
> *ADDRESS_OF_NEXT(TO_PTR(FREELIST_POINTER(item)), f->offset),
> 326 FREELIST_VERSION(item) + 1);
> 327 #if !defined(INK_USE_MUTEX_FOR_FREELISTS)
> 328 result = ink_atomic_cas64((int64_t *) & f->head.data, item.data,
> next.data);
> 329 #else
> 330 f->head.data = next.data;
> (gdb) p next
> $2 =
> (gdb) p f
> $3 = (InkFreeList *) 0x3312629ce0
> (gdb) p *f
> $4 = {head = {data = -8941773651046140890}, name = 0x331241e92f "ArenaBlock",
> type_size = 1024, chunk_size = 128,
> count = 519, allocated = 1536, offset = 0, alignment = 8, allocated_base =
> 0, count_base = 0}
> (gdb) p item
> $5 = {data = -8953314125091277786}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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.3.3)
3.3.2
Assignee: Leif Hedstrom
Yeah, I'm pretty sure you are right, this assert is bogus if someone has used
the TSCacheUrlSet API.
> 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
>Assignee: Leif Hedstrom
> Fix For: 3.3.2
>
>
> {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
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:
--
Component/s: HTTP
> 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
> Components: HTTP
>Affects Versions: 3.1.3, 3.0.4
> Environment: configure --enable-debug
>Reporter: Conan Wang
>Assignee: Leif Hedstrom
> Fix For: 3.3.2
>
>
> {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
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-1329) Segfault: WARNING: connect by disallowed client
[
https://issues.apache.org/jira/browse/TS-1329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom resolved TS-1329.
---
Resolution: Duplicate
Fix Version/s: (was: 3.3.3)
Going to mark this as Duplicate of TS-1235. Please reopen if you disagree.
> Segfault: WARNING: connect by disallowed client
> ---
>
> Key: TS-1329
> URL: https://issues.apache.org/jira/browse/TS-1329
> Project: Traffic Server
> Issue Type: Bug
>Affects Versions: 3.2.0
> Environment: ATS 3.2.0 on RHEL 6.2 64-bit
>Reporter: David Carlin
>
> I've seen the following ATS 3.2.0 crash on a couple of boxes. From
> traffic.out:
>
> [Jun 20 00:24:25.702] Server {0x2aaafb0c0700} WARNING: connect by disallowed
> client 66.87.131.100, closing
> [Jun 20 00:24:25.702] Server {0x2aaaf941a860} WARNING: connect by disallowed
> client 184.21.69.44, closing
> [Jun 20 00:24:25.703] Server {0x2aaafa6b6700} WARNING: connect by disallowed
> client 184.21.69.44, closing
> NOTE: Traffic Server received Sig 11: Segmentation fault
> /home/y/bin/traffic_server - STACK TRACE:
> /lib64/libpthread.so.0[0x384720f4a0]
> /home/y/bin/traffic_server(_ZN10HttpAccept9mainEventEiPv+0x232)[0x5071a2]
> /home/y/bin/traffic_server(_ZN18UnixNetVConnection11acceptEventEiP5Event+0x3d6)[0x6770e6]
> /home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0xb4)[0x696b14]
> /home/y/bin/traffic_server(_ZN7EThread7executeEv+0x5ab)[0x69758b]
> /home/y/bin/traffic_server[0x695ae2]
> /lib64/libpthread.so.0[0x38472077f1]
> /lib64/libc.so.6(clone+0x6d)[0x3846ee5ccd]
> This appeared in /var/log/messages:
> Jun 20 00:24:25 l4 kernel: [ET_NET 7][946] general protection
> ip:5071a2sp:2aaafacbbc20 error:0 in traffic_server[40+34]
> Bryan Call pointed out that according to the source code, this error message
> is from someone trying to connect to the management port that is not from
> 127.0.0.1.
> Whats strange is that this port (8084 per records.config) is blocked via ACLs.
> One time that this crash occurred, the resolvable IPs in the logs are ALL DNS
> servers at various ISPs. During subsequent crashes I've not seen this
> phenomenon.
> Any ideas what caused this? Below are the full traffic.out logs.
> [Jun 20 00:24:25.493] Server {0x2aaaf941a860} WARNING: connect by disallowed
> client 2602:306:cd65:4870:219:e3ff:fee1:46a8, closing
> [Jun 20 00:24:25.493] Server {0x2aaafaaba700} WARNING: connect by disallowed
> client 64.60.77.50, closing
> [Jun 20 00:24:25.493] Server {0x2aaafaaba700} WARNING: connect by disallowed
> client 64.60.77.50, closing
> [Jun 20 00:24:25.493] Server {0x2aaafaaba700} WARNING: connect by disallowed
> client 123.17.186.238, closing
> [Jun 20 00:24:25.495] Server {0x2aaafa6b6700} WARNING: connect by disallowed
> client 69.228.39.246, closing
> [Jun 20 00:24:25.496] Server {0x2aaafa7b7700} WARNING: connect by disallowed
> client 68.104.203.189, closing
> [Jun 20 00:24:25.497] Server {0x2aaafa8b8700} WARNING: connect by disallowed
> client 64.128.13.116, closing
> [Jun 20 00:24:25.499] Server {0x2aaafa9b9700} WARNING: connect by disallowed
> client 99.110.163.228, closing
> [Jun 20 00:24:25.500] Server {0x2aaafaaba700} WARNING: connect by disallowed
> client 108.65.184.157, closing
> [Jun 20 00:24:25.500] Server {0x2aaafabbb700} WARNING: connect by disallowed
> client 75.171.73.65, closing
> [Jun 20 00:24:25.500] Server {0x2aaafacbc700} WARNING: connect by disallowed
> client 65.244.245.5, closing
> [Jun 20 00:24:25.501] Server {0x2aaafadbd700} WARNING: connect by disallowed
> client 184.189.226.136, closing
> [Jun 20 00:24:25.502] Server {0x2aaafaebe700} WARNING: connect by disallowed
> client 76.208.160.176, closing
> [Jun 20 00:24:25.502] Server {0x2aaafafbf700} WARNING: connect by disallowed
> client 108.196.82.213, closing
> [Jun 20 00:24:25.503] Server {0x2aaafb0c0700} WARNING: connect by disallowed
> client 108.226.35.156, closing
> [Jun 20 00:24:25.504] Server {0x2aaaf941a860} WARNING: connect by disallowed
> client 66.214.61.250, closing
> [Jun 20 00:24:25.507] Server {0x2aaafa6b6700} WARNING: connect by disallowed
> client 72.44.192.76, closing
> [Jun 20 00:24:25.507] Server {0x2aaafa7b7700} WARNING: connect by disallowed
> client 70.164.151.252, closing
> [Jun 20 00:24:25.508] Server {0x2aaafa8b8700} WARNING: connect by disallowed
> client 68.228.199.25, closing
> [Jun 20 00:24:25.508] Server {0x2aaafa9b9700} WARNING: connect by disallowed
> client 99.76.185.7, closing
> [Jun 20 00:24:25.508] Server {0x2aaafaaba700} WARNING: connect by disallowed
> client 99.76.185.7, closing
> [Jun 20 00:24:25.508] Server {0x2aaafabbb700} WARNING: connect by disallowed
> client 99.7.125.142, closing
> [Jun 20 00:24:25.510] Server {0x2aaafacbc700} WARNING: connect by disallowed
> client 108.224.81.64, closing
>
[jira] [Updated] (TS-1366) cquc does not work as documented: Logging the remapped URL
[
https://issues.apache.org/jira/browse/TS-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1366:
--
Component/s: Logging
> cquc does not work as documented: Logging the remapped URL
> --
>
> Key: TS-1366
> URL: https://issues.apache.org/jira/browse/TS-1366
> Project: Traffic Server
> Issue Type: Bug
> Components: Logging
>Reporter: Igor Galić
> Fix For: 3.3.3
>
>
> From the documentation
> (http://trafficserver.apache.org/docs/trunk/admin/working-log-files/log-formats#SquidFormat)
> :
> cquc
> The client request canonical URL; blanks and other characters that might
> not be parsed by log analysis tools are replaced by escape sequences. The
> escape sequence is a percentage sign followed by the ASCII code number of the
> replaced character in hex.
> But in fact it logs the remapped URL.
> This may or may not be related to the {{records.config}} setting:
> {noformat}
> CONFIG proxy.config.url_remap.pristine_host_hdr INT 1
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1344) url.cc doesn't terminate path correctly for malformed query strings
[ https://issues.apache.org/jira/browse/TS-1344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13613131#comment-13613131 ] Leif Hedstrom commented on TS-1344: --- Where's the patch? :) > url.cc doesn't terminate path correctly for malformed query strings > --- > > Key: TS-1344 > URL: https://issues.apache.org/jira/browse/TS-1344 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Affects Versions: 3.2.0, 3.0.5 >Reporter: Brian Geffon >Assignee: Brian Geffon > Fix For: 3.3.3 > > > Malformed query strings can cause ATS to incorrectly take the query string as > the path. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1344) url.cc doesn't terminate path correctly for malformed query strings
[ https://issues.apache.org/jira/browse/TS-1344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1344: -- Fix Version/s: (was: 3.3.3) 3.3.2 > url.cc doesn't terminate path correctly for malformed query strings > --- > > Key: TS-1344 > URL: https://issues.apache.org/jira/browse/TS-1344 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Affects Versions: 3.2.0, 3.0.5 >Reporter: Brian Geffon >Assignee: Brian Geffon > Fix For: 3.3.2 > > > Malformed query strings can cause ATS to incorrectly take the query string as > the path. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1244) Crash report: cores in Arena::reset
[
https://issues.apache.org/jira/browse/TS-1244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1244:
--
Component/s: Core
> Crash report: cores in Arena::reset
>
>
> Key: TS-1244
> URL: https://issues.apache.org/jira/browse/TS-1244
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.0.4
>Reporter: Manjesh Nilange
> Fix For: 3.3.3
>
>
> I have two slightly different stack traces, but both involving Arena::reset
> #0 0x003736032a45 in raise () from /lib64/libc.so.6
> #1 0x003736034225 in abort () from /lib64/libc.so.6
> #2 0x00373606fdfb in __libc_message () from /lib64/libc.so.6
> #3 0x003736075716 in malloc_printerr () from /lib64/libc.so.6
> #4 0x003724e0d38d in xfree (this=0x2b8c2c1b6bb8) at ink_resource.h:89
> #5 blk_free (this=0x2b8c2c1b6bb8) at Arena.cc:69
> #6 Arena::reset (this=0x2b8c2c1b6bb8) at Arena.cc:156
> #7 0x0050e3e3 in destroy (this=0x2b8c2c1b6b40) at HttpTransact.h:1235
> #8 HttpSM::cleanup (this=0x2b8c2c1b6b40) at HttpSM.cc:346
> #9 0x0050e719 in HttpSM::destroy (this=0x2b8c2c1b6b40) at
> HttpSM.cc:368
> #10 0x00515a56 in HttpSM::kill_this (this=0x2b8c2c1b6b40) at
> HttpSM.cc:6023
> #11 0x00515e08 in HttpSM::main_handler (this=0x2b8c2c1b6b40,
> event=2301, data=0x2b8c2c1b8828)
> at HttpSM.cc:2452
> ...
> (gdb) f 4
> #4 0x003724e0d38d in xfree (this=0x2b8c2c1b6bb8) at ink_resource.h:89
> 89ink_free(mem);
> (gdb) p mem
> $1 =
> (gdb) f 5
> #5 blk_free (this=0x2b8c2c1b6bb8) at Arena.cc:69
> 69xfree(blk);
> (gdb) p blk
> $2 =
> (gdb) f 6
> #6 Arena::reset (this=0x2b8c2c1b6bb8) at Arena.cc:156
> 156 blk_free(m_blocks);
> (gdb) p m_blocks
> $3 = (ArenaBlock *) 0x2b8b9822b870
> (gdb) p *m_blocks
> $4 = {next = 0x3b323531322e3630, m_heap_end = 0x2554454e2e303225 0x2554454e2e303225 out of bounds>,
> m_water_level = 0x303225524c433032 bounds>, data = "3.5.3072"}
> (gdb) p *m_blocks->next
> Cannot access memory at address 0x3b323531322e3630
> It looks m_blocks is corrupted.
> and the other stack trace
> #3 0x004d03aa in signal_handler (sig=11) at signals.cc:225
> #4
> #5 blk_free (this=0x2afc58072f88) at Arena.cc:65
> #6 Arena::reset (this=0x2afc58072f88) at Arena.cc:156
> #7 0x0050e3e3 in destroy (this=0x2afc58072f10) at HttpTransact.h:1235
> #8 HttpSM::cleanup (this=0x2afc58072f10) at HttpSM.cc:346
> #9 0x0050e719 in HttpSM::destroy (this=0x2afc58072f10) at
> HttpSM.cc:368
> #10 0x00515a56 in HttpSM::kill_this (this=0x2afc58072f10) at
> HttpSM.cc:6023
> #11 0x00515e08 in HttpSM::main_handler (this=0x2afc58072f10,
> event=2301, data=0x2afc58074bf8)
> at HttpSM.cc:2452
> ...
> (gdb) f 5
> #5 blk_free (this=0x2afc58072f88) at Arena.cc:65
> 65 size = blk->m_heap_end - &blk->data[0];
> (gdb) p blk
> $1 =
> (gdb) f 6
> #6 Arena::reset (this=0x2afc58072f88) at Arena.cc:156
> 156 blk_free(m_blocks);
> (gdb) p m_blocks
> $2 = (ArenaBlock *) 0x373439333634
> (gdb) p *m_blocks
> Cannot access memory at address 0x373439333634
> Our environment:
> $ uname -a
> Linux xxx.prod 2.6.32-131.4.1.el6.x86_64 #1 SMP Fri Jun 10 10:54:26 EDT 2011
> x86_64 x86_64 x86_64 GNU/Linux
> $ file /usr/bin/traffic_server
> /usr/bin/traffic_server: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
> dynamically linked (uses shared libs), for GNU/Linux 2.6.18, stripped
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1375) too many connections, throttling
[
https://issues.apache.org/jira/browse/TS-1375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1375:
--
Component/s: Network
> too many connections, throttling
>
>
> Key: TS-1375
> URL: https://issues.apache.org/jira/browse/TS-1375
> Project: Traffic Server
> Issue Type: Bug
> Components: Network
> Environment: centos 6.2 x86_64 ats from git(3.3.0)
>Reporter: bettydramit
>Assignee: Bin Chen
> Fix For: 3.3.3
>
>
> [Jul 20 09:09:19.787] Server {0x2ad5ddd00060} WARNING: too many open file
> descriptors, emergency throttling
> [Jul 20 09:09:19.788] Server {0x2ad5ded28700} WARNING: too many connections,
> throttling
> [Jul 20 09:19:19.823] Server {0x2ad5eb6d2700} WARNING: too many connections,
> throttling
> [Jul 20 09:19:22.634] Manager {0x7f10bc4327e0} NOTE: [Alarms::signalAlarm]
> Skipping Alarm: 'too many connections, throttling'
> [TrafficManager] ==> Cleaning up and reissuing signal #15
> [Jul 20 09:21:50.819] Manager {0x7f10bc4327e0} ERROR: [TrafficManager] ==>
> Cleaning up and reissuing signal #15
> [Jul 20 09:21:50.819] Manager {0x7f10bc4327e0} ERROR: (last system error 2:
> No such file or directory)
> NOTE: Traffic Server received Sig 15: Terminated
> [TrafficManager] ==> signal #15
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1344) url.cc doesn't terminate path correctly for malformed query strings
[ https://issues.apache.org/jira/browse/TS-1344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1344: -- Component/s: HTTP > url.cc doesn't terminate path correctly for malformed query strings > --- > > Key: TS-1344 > URL: https://issues.apache.org/jira/browse/TS-1344 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Affects Versions: 3.2.0, 3.0.5 >Reporter: Brian Geffon >Assignee: Brian Geffon > Fix For: 3.3.3 > > > Malformed query strings can cause ATS to incorrectly take the query string as > the path. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-1528) ats_memalign: couldn't allocate -548249600 bytes in Vol::init()
[
https://issues.apache.org/jira/browse/TS-1528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach resolved TS-1528.
-
Resolution: Not A Problem
Yeh, let's close.
> ats_memalign: couldn't allocate -548249600 bytes in Vol::init()
> ---
>
> Key: TS-1528
> URL: https://issues.apache.org/jira/browse/TS-1528
> Project: Traffic Server
> Issue Type: Bug
>Affects Versions: 3.2.0
> Environment: Debian testing (wheezy) on i686
>Reporter: Jack Bates
>Assignee: James Peach
> Fix For: 3.3.2
>
>
> I consistently get the following error whenever I try to start Traffic Server
> (release 3.2.0). Yesterday I built Traffic Server from Git HEAD (34a2ba) to
> check if it behaves any differently, but I consistently reproduce this same
> error whenever I try to start it, too
> Here's my configuration, which is pretty minimal:
> http://nottheoilrig.com/trafficserver/201210120/
> What details can I provide to help debug this? James Peach suggested
> attaching some kind of dump of the volume header:
> http://mail-archives.apache.org/mod_mbox/trafficserver-users/201210.mbox/%3C9ED91AE2-2F52-4BDB-9088-E14D40642C34%40apache.org%3E
> {code}
> administrator@debian$ TS_ROOT=/home/administrator/trafficserver
> trafficserver/traffic_server
> [TrafficServer] using root directory '/home/administrator/trafficserver'
> FATAL: ats_memalign: couldn't allocate -548249600 bytes at alignment 4096 -
> insufficient memory
> trafficserver/traffic_server - STACK TRACE:
> trafficserver/libtsutil.so.3(+0x1075b)[0xb76d075b]
> trafficserver/libtsutil.so.3(ats_memalign+0xa1)[0xb76d34c1]
> trafficserver/traffic_server(_ZN3Vol4initEPcxxb+0x282)[0x827bd52]
> trafficserver/traffic_server(_ZN5Cache4openEbb+0x5d8)[0x827dc48]
> trafficserver/traffic_server(_ZN14CacheProcessor15diskInitializedEv+0x323)[0x827e0d3]
> trafficserver/traffic_server(_ZN9CacheDisk9openStartEiPv+0x483)[0x828c9c3]
> trafficserver/traffic_server(_ZN19AIOCallbackInternal11io_completeEiPv+0x25)[0x8280a75]
> trafficserver/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8b)[0x830343b]
> trafficserver/traffic_server(_ZN7EThread7executeEv+0x723)[0x8304003]
> trafficserver/traffic_server(main+0x178d)[0x80c572d]
> /lib/i386-linux-gnu/i686/cmov/libc.so.6(__libc_start_main+0xe6)[0xb7039e46]
> trafficserver/traffic_server[0x80cabdd]
> administrator@debian:~$
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1635) url parse BUGS IN Apache Traffic Sever 3.3.1
[ https://issues.apache.org/jira/browse/TS-1635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13613086#comment-13613086 ] Leif Hedstrom commented on TS-1635: --- Alan: Does this bug duplicate TS-1623 ? I.e. can we close one of them? > url parse BUGS IN Apache Traffic Sever 3.3.1 > - > > Key: TS-1635 > URL: https://issues.apache.org/jira/browse/TS-1635 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: evilbandon >Assignee: weijin > Fix For: 3.3.3 > > Attachments: ts-1635.diff > > > url parse BUGS IN Apache Traffic Sever 3.3.1 > the request URL is http://a.b.com/xx.jpg?newpath=http://b.c.com > but the Apache Traffic Sever 3.3.1 parse this url as http://b.c.com -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-1635) url parse BUGS IN Apache Traffic Sever 3.3.1
[ https://issues.apache.org/jira/browse/TS-1635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-1635: - Assignee: Alan M. Carroll (was: weijin) > url parse BUGS IN Apache Traffic Sever 3.3.1 > - > > Key: TS-1635 > URL: https://issues.apache.org/jira/browse/TS-1635 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: evilbandon >Assignee: Alan M. Carroll > Fix For: 3.3.3 > > Attachments: ts-1635.diff > > > url parse BUGS IN Apache Traffic Sever 3.3.1 > the request URL is http://a.b.com/xx.jpg?newpath=http://b.c.com > but the Apache Traffic Sever 3.3.1 parse this url as http://b.c.com -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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.3.3) sometime > 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: sometime > > > 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 For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1059) prefetch segment fault
[ https://issues.apache.org/jira/browse/TS-1059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13613046#comment-13613046 ] Leif Hedstrom commented on TS-1059: --- Is this still an issue ? > prefetch segment fault > -- > > Key: TS-1059 > URL: https://issues.apache.org/jira/browse/TS-1059 > Project: Traffic Server > Issue Type: Sub-task > Components: HTTP >Affects Versions: 3.0.2 > Environment: linux(ubuntu) >Reporter: yunfei chen > Labels: crash > Fix For: 3.3.3 > > > I encountered a segment faut when I was testing Prefetch module。 > ab -n 1 -c 1 -X 192.168.16.198:8080 -d > http://club.baobao.sohu.com/r-mmbb-3954004-0-29-900.html > configuration in records.config > CONFIG proxy.config.prefetch.prefetch_enabled INT 1 > configuration in prefetch.config > prefetch_children 192.168.16.198 > html_tag img src > #0 0x08124f17 in VIO::reenable (this=0x0) at > ../iocore/eventsystem/P_VIO.h:123 > #1 0x08147fe3 in KeepAliveConn::append (this=0xab9aef20, rdr=0x9c91b794) at > Prefetch.cc:1984 > #2 0x08145fd7 in KeepAliveConnTable::append (this=0xb2393608, ip=16777343, > buf=0x9c91b780, reader=0x9c91b794) at Prefetch.cc:2039 > #3 0x0814679b in KeepAliveLockHandler::handleEvent (this=0xb23e0b30, > event=2, data=0x8ab2f60) at Prefetch.cc:2168 > #4 0x08104ba5 in Continuation::handleEvent (this=0xb23e0b30, event=2, > data=0x8ab2f60) > at ../iocore/eventsystem/I_Continuation.h:146 > #5 0x0830a9f5 in EThread::process_event (this=0xb7396008, e=0x8ab2f60, > calling_code=2) at UnixEThread.cc:140 > #6 0x0830add5 in EThread::execute (this=0xb7396008) at UnixEThread.cc:217 > #7 0x0830900e in spawn_thread_internal (a=0x895eed8) at Thread.cc:88 > #8 0x00165cc9 in start_thread (arg=0xb6f91b70) at pthread_create.c:304 > #9 0x0066f69e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130 > #0 0x08124f17 in VIO::reenable (this=0x0) at > ../iocore/eventsystem/P_VIO.h:123 > #1 0x08147fe3 in KeepAliveConn::append (this=0xa5736888, rdr=0x8d0b2f4) at > Prefetch.cc:1984 > #2 0x08145fd7 in KeepAliveConnTable::append (this=0xb2393608, ip=16777343, > buf=0x8d0b2e0, reader=0x8d0b2f4) at Prefetch.cc:2039 > #3 0x08141db3 in PrefetchUrlBlaster::udpUrlBlaster (this=0x8abd3e0, > event=3300, data=0x0) at Prefetch.cc:885 > #4 0x0813e4ea in PrefetchUrlBlaster::init (this=0x8abd3e0, > list_head=0xabc59ac0, u_proto=TCP_BLAST) at Prefetch.h:280 > #5 0x08147806 in BlasterUrlList::invokeUrlBlaster (this=0xa7c22260) at > Prefetch.h:287 > #6 0x08141ac8 in BlasterUrlList::handleEvent (this=0xa7c22260, event=3302, > data=0xabc59ac0) at Prefetch.cc:803 > #7 0x08143c89 in PrefetchBlaster::handleEvent (this=0xa5739920, event=2, > data=0x0) at Prefetch.cc:1420 > #8 0x08144f42 in PrefetchBlaster::invokeBlaster (this=0xa5739920) at > Prefetch.cc:1769 > #9 0x08143e22 in PrefetchBlaster::handleEvent (this=0xa5739920, event=1102, > data=0xb23cdca0) at Prefetch.cc:1448 > #10 0x08104ba5 in Continuation::handleEvent (this=0xa5739920, event=1102, > data=0xb23cdca0) > at ../iocore/eventsystem/I_Continuation.h:146 > #11 0x082c1abf in CacheVC::callcont (this=0xb23cdca0, event=1102) at > P_CacheInternal.h:629 > #12 0x082c1487 in CacheVC::openReadStartHead (this=0xb23cdca0, event=3900, > e=0x0) at CacheRead.cc:1115 > #13 0x08104ba5 in Continuation::handleEvent (this=0xb23cdca0, event=3900, > data=0x0) at ../iocore/eventsystem/I_Continuation.h:146 > #14 0x082c1431 in CacheVC::openReadStartHead (this=0xb23cdca0, event=2, > e=0x8ab48a0) at CacheRead.cc:1112 > #15 0x08104ba5 in Continuation::handleEvent (this=0xb23cdca0, event=2, > data=0x8ab48a0) > at ../iocore/eventsystem/I_Continuation.h:146 > #16 0x0830a9f5 in EThread::process_event (this=0xb7295008, e=0x8ab48a0, > calling_code=2) at UnixEThread.cc:140 > #17 0x0830add5 in EThread::execute (this=0xb7295008) at UnixEThread.cc:217 > #18 0x0830900e in spawn_thread_internal (a=0x895dd00) at Thread.cc:88 > #19 0x00165cc9 in start_thread (arg=0xb6e90b70) at pthread_create.c:304 > #20 0x0066f69e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1429) Log collation of custom xml logs failing
[
https://issues.apache.org/jira/browse/TS-1429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1429:
--
Fix Version/s: (was: 3.3.3)
sometime
> Log collation of custom xml logs failing
>
>
> Key: TS-1429
> URL: https://issues.apache.org/jira/browse/TS-1429
> Project: Traffic Server
> Issue Type: Bug
> Components: Logging
>Affects Versions: 3.2.0
> Environment: Linux
>Reporter: Dan Morgan
> Fix For: sometime
>
>
> When configuring logs_xml.config to send to a collation host with the
> entry, we start to get these errors in traffic.out:
> NOTE: [log-coll] send-queue full; orphaning logs [192.168.57.248:8085]
> NOTE: [log-coll] send-queue clear; resuming collation [192.168.57.248:8085]
> thousands of them.
> It looks like there used to be a config value called:
> collation_max_send_buffers that has been removed, but there's still code in
> LogCollationClientSM.cc that references that value (which appears to now be
> zero). Line 185 looks like:
> if (m_buffer_send_list->get_size() >=
> Log::config->collation_max_send_buffers) {
> Debug("log-coll", "[%d]client::send - m_flow = DENY", m_id);
> Note("[log-coll] send-queue full; orphaning logs "
> "[%s:%u]", m_log_host->ip_addr().toString(ipb, sizeof(ipb)),
> m_log_host->port());
> m_flow = LOG_COLL_FLOW_DENY;
> }
> but since collation_max_send_buffers is zero, it always goes into that if
> block.
> Just as a note as well, issue TS-1299
> (https://issues.apache.org/jira/browse/TS-1299) which has a patch for 3.1.4,
> never made it into 3.2 (looks like it was done on the same day as 3.2 was
> released).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1429) Log collation of custom xml logs failing
[
https://issues.apache.org/jira/browse/TS-1429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13613081#comment-13613081
]
Leif Hedstrom commented on TS-1429:
---
I believe TS-1299 is now also backported to 3.2.x
> Log collation of custom xml logs failing
>
>
> Key: TS-1429
> URL: https://issues.apache.org/jira/browse/TS-1429
> Project: Traffic Server
> Issue Type: Bug
> Components: Logging
>Affects Versions: 3.2.0
> Environment: Linux
>Reporter: Dan Morgan
> Fix For: 3.3.3
>
>
> When configuring logs_xml.config to send to a collation host with the
> entry, we start to get these errors in traffic.out:
> NOTE: [log-coll] send-queue full; orphaning logs [192.168.57.248:8085]
> NOTE: [log-coll] send-queue clear; resuming collation [192.168.57.248:8085]
> thousands of them.
> It looks like there used to be a config value called:
> collation_max_send_buffers that has been removed, but there's still code in
> LogCollationClientSM.cc that references that value (which appears to now be
> zero). Line 185 looks like:
> if (m_buffer_send_list->get_size() >=
> Log::config->collation_max_send_buffers) {
> Debug("log-coll", "[%d]client::send - m_flow = DENY", m_id);
> Note("[log-coll] send-queue full; orphaning logs "
> "[%s:%u]", m_log_host->ip_addr().toString(ipb, sizeof(ipb)),
> m_log_host->port());
> m_flow = LOG_COLL_FLOW_DENY;
> }
> but since collation_max_send_buffers is zero, it always goes into that if
> block.
> Just as a note as well, issue TS-1299
> (https://issues.apache.org/jira/browse/TS-1299) which has a patch for 3.1.4,
> never made it into 3.2 (looks like it was done on the same day as 3.2 was
> released).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1429) Log collation of custom xml logs failing
[
https://issues.apache.org/jira/browse/TS-1429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13613080#comment-13613080
]
Leif Hedstrom commented on TS-1429:
---
Dan, you have a patch for this? :)
> Log collation of custom xml logs failing
>
>
> Key: TS-1429
> URL: https://issues.apache.org/jira/browse/TS-1429
> Project: Traffic Server
> Issue Type: Bug
> Components: Logging
>Affects Versions: 3.2.0
> Environment: Linux
>Reporter: Dan Morgan
> Fix For: 3.3.3
>
>
> When configuring logs_xml.config to send to a collation host with the
> entry, we start to get these errors in traffic.out:
> NOTE: [log-coll] send-queue full; orphaning logs [192.168.57.248:8085]
> NOTE: [log-coll] send-queue clear; resuming collation [192.168.57.248:8085]
> thousands of them.
> It looks like there used to be a config value called:
> collation_max_send_buffers that has been removed, but there's still code in
> LogCollationClientSM.cc that references that value (which appears to now be
> zero). Line 185 looks like:
> if (m_buffer_send_list->get_size() >=
> Log::config->collation_max_send_buffers) {
> Debug("log-coll", "[%d]client::send - m_flow = DENY", m_id);
> Note("[log-coll] send-queue full; orphaning logs "
> "[%s:%u]", m_log_host->ip_addr().toString(ipb, sizeof(ipb)),
> m_log_host->port());
> m_flow = LOG_COLL_FLOW_DENY;
> }
> but since collation_max_send_buffers is zero, it always goes into that if
> block.
> Just as a note as well, issue TS-1299
> (https://issues.apache.org/jira/browse/TS-1299) which has a patch for 3.1.4,
> never made it into 3.2 (looks like it was done on the same day as 3.2 was
> released).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1772) remove Inline.cc files
[ https://issues.apache.org/jira/browse/TS-1772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-1772: Fix Version/s: 3.3.2 > remove Inline.cc files > -- > > Key: TS-1772 > URL: https://issues.apache.org/jira/browse/TS-1772 > Project: Traffic Server > Issue Type: Improvement > Components: Build >Reporter: James Peach >Assignee: James Peach > Fix For: 3.3.2 > > > The use of Inline.cc files was probably related to old compilers not inlining > things correctly, or possibly some code bloat issues. Right now they are just > confusing and cluttering up the build system; let's remove them. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1772) remove Inline.cc files
[ https://issues.apache.org/jira/browse/TS-1772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13613078#comment-13613078 ] James Peach commented on TS-1772: - I have a patch for this. > remove Inline.cc files > -- > > Key: TS-1772 > URL: https://issues.apache.org/jira/browse/TS-1772 > Project: Traffic Server > Issue Type: Improvement > Components: Build >Reporter: James Peach >Assignee: James Peach > Fix For: 3.3.2 > > > The use of Inline.cc files was probably related to old compilers not inlining > things correctly, or possibly some code bloat issues. Right now they are just > confusing and cluttering up the build system; let's remove them. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1403) f_inbound_transparency is not handled by all accept cases
[ https://issues.apache.org/jira/browse/TS-1403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1403: -- Fix Version/s: (was: 3.3.3) sometime > f_inbound_transparency is not handled by all accept cases > - > > Key: TS-1403 > URL: https://issues.apache.org/jira/browse/TS-1403 > Project: Traffic Server > Issue Type: Bug > Components: Network >Affects Versions: 3.2.0 >Reporter: Yossi Gottlieb >Priority: Minor > Fix For: sometime > > Attachments: transparency.diff > > > The inbound transparency flag does not always take affect, depending on the > accept configuration. This is not currently an issue because TSAPI doesn't > provide a standard transparent accept API, but it will become an issue once > the interface is created. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1772) remove Inline.cc files
James Peach created TS-1772: --- Summary: remove Inline.cc files Key: TS-1772 URL: https://issues.apache.org/jira/browse/TS-1772 Project: Traffic Server Issue Type: Improvement Components: Build Reporter: James Peach The use of Inline.cc files was probably related to old compilers not inlining things correctly, or possibly some code bloat issues. Right now they are just confusing and cluttering up the build system; let's remove them. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-1772) remove Inline.cc files
[ https://issues.apache.org/jira/browse/TS-1772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach reassigned TS-1772: --- Assignee: James Peach > remove Inline.cc files > -- > > Key: TS-1772 > URL: https://issues.apache.org/jira/browse/TS-1772 > Project: Traffic Server > Issue Type: Improvement > Components: Build >Reporter: James Peach >Assignee: James Peach > > The use of Inline.cc files was probably related to old compilers not inlining > things correctly, or possibly some code bloat issues. Right now they are just > confusing and cluttering up the build system; let's remove them. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1403) f_inbound_transparency is not handled by all accept cases
[ https://issues.apache.org/jira/browse/TS-1403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13613074#comment-13613074 ] Leif Hedstrom commented on TS-1403: --- Is there a Jira ticket for any API changes that this relates to btw? > f_inbound_transparency is not handled by all accept cases > - > > Key: TS-1403 > URL: https://issues.apache.org/jira/browse/TS-1403 > Project: Traffic Server > Issue Type: Bug > Components: Network >Affects Versions: 3.2.0 >Reporter: Yossi Gottlieb >Priority: Minor > Fix For: 3.3.3 > > Attachments: transparency.diff > > > The inbound transparency flag does not always take affect, depending on the > accept configuration. This is not currently an issue because TSAPI doesn't > provide a standard transparent accept API, but it will become an issue once > the interface is created. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1715) Possibly range related crashing since upgrading to 3.2.4
[
https://issues.apache.org/jira/browse/TS-1715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1715:
--
Fix Version/s: 3.3.2
Any updates on this? Does this still happen with current master as well ?
> Possibly range related crashing since upgrading to 3.2.4
>
>
> Key: TS-1715
> URL: https://issues.apache.org/jira/browse/TS-1715
> Project: Traffic Server
> Issue Type: Bug
> Components: Cache, Core
>Affects Versions: 3.2.4
>Reporter: David Carlin
>Assignee: Alan M. Carroll
> Fix For: 3.3.2
>
>
> This might be related to TS-1574
> I upgraded one box to 3.2.4, and and I am experiencing the following crash
> approximately twice a day:
> Backtraces - the first happens more frequently:
> {noformat}
> #0 RangeTransform::transform_to_range (this=0x2b40e40973d0) at
> Transform.cc:843
> #1 0x004e52e8 in RangeTransform::handle_event (this=0x2b40e40973d0,
> event=, edata=) at Transform.cc:816
> #2 0x006970f4 in handleEvent (this=0x2b40b9762010, e=0x2b40dc47f9e0,
> calling_code=1) at I_Continuation.h:146
> #3 EThread::process_event (this=0x2b40b9762010, e=0x2b40dc47f9e0,
> calling_code=1) at UnixEThread.cc:142
> #4 0x00697b6b in EThread::execute (this=0x2b40b9762010) at
> UnixEThread.cc:191
> #5 0x006960c2 in spawn_thread_internal (a=0x15e04a0) at Thread.cc:88
> #6 0x0031f8c07851 in start_thread () from /lib64/libpthread.so.0
> #7 0x0031f88e76dd in clone () from /lib64/libc.so.6
> #0 RangeTransform::transform_to_range (this=0x2b11441773f0) at
> Transform.cc:843
> #1 0x004e52e8 in RangeTransform::handle_event (this=0x2b11441773f0,
> event=, edata=) at Transform.cc:816
> #2 0x006970f4 in handleEvent (this=0x2b109f266010, e=0x2b110006f360,
> calling_code=1) at I_Continuation.h:146
> #3 EThread::process_event (this=0x2b109f266010, e=0x2b110006f360,
> calling_code=1) at UnixEThread.cc:142
> #4 0x00697b6b in EThread::execute (this=0x2b109f266010) at
> UnixEThread.cc:191
> #5 0x004c28c9 in main (argc=, argv= optimized out>) at Main.cc:1822
> {noformat}
> From /var/log/messages:
> {noformat}
> Feb 16 11:43:26 l4 kernel: [ET_NET 18][16876]: segfault at 155 ip
> 00567571 sp 2b04d1412b40 error 4 in
> traffic_server[40+341000]
> {noformat}
> From traffic.out:
> {noformat}
> /home/y/bin/traffic_server - STACK TRACE:
> /lib64/libpthread.so.0[0x31f8c0f500]
> /home/y/bin/traffic_server(_ZN14RangeTransform18transform_to_rangeEv+0x83)[0x4e4b63]
> /home/y/bin/traffic_server(_ZN14RangeTransform12handle_eventEiPv+0x158)[0x4e52e8]
> /home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0xb4)[0x6970f4]
> /home/y/bin/traffic_server(_ZN7EThread7executeEv+0x5ab)[0x697b6b]
> /home/y/bin/traffic_server[0x6960c2]
> /lib64/libpthread.so.0[0x31f8c07851]
> /lib64/libc.so.6(clone+0x6d)[0x31f88e76dd]
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1336) High CPU Usage at idle
[
https://issues.apache.org/jira/browse/TS-1336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13613067#comment-13613067
]
Leif Hedstrom commented on TS-1336:
---
There was a suggestion that we have a too short rescheduling / timeout setting.
Who wants to look at this? :)
> High CPU Usage at idle
> --
>
> Key: TS-1336
> URL: https://issues.apache.org/jira/browse/TS-1336
> Project: Traffic Server
> Issue Type: Bug
> Components: Performance
>Affects Versions: 3.0.5, 3.0.2
> Environment: Ubuntu 12.04 server, amd64, Xenon E5520 (4-core, 16
> cores with HT)
>Reporter: Greg Smolyn
> Fix For: 3.3.3
>
>
> On this unloaded system, a very basic traffic server instance is using 180%
> CPU, with 3 threads ET_TASK 0, ET_TASK 1, and LOGGING taking up about 60%
> each.
> top -H output:
> PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
>
>
> 10723 traffics 20 0 1960m 113m 4168 R 61 0.4 9:11.27 [ET_TASK 1]
>
>
> 10722 traffics 20 0 1960m 113m 4168 R 60 0.4 8:41.61 [ET_TASK 0]
>
>
> 10720 traffics 20 0 1960m 113m 4168 S 59 0.4 8:49.19 [LOGGING]
>
>
>19 root 20 0 000 R 15 0.0 898:45.74 ksoftirqd/3
>
>
>10 root 20 0 000 S 15 0.0 930:16.92 ksoftirqd/1
>
>
>27 root 20 0 000 S 14 0.0 893:18.41 ksoftirqd/5
>
>
>35 root 20 0 000 S 14 0.0 888:54.41 ksoftirqd/7
>
>
> 3 root 20 0 000 S8 0.0 942:48.39 ksoftirqd/0
>
>
>15 root 20 0 000 S7 0.0 906:40.98 ksoftirqd/2
>
>
>23 root 20 0 000 S7 0.0 907:30.33 ksoftirqd/4
>
>
>31 root 20 0 000 S7 0.0 898:13.05 ksoftirqd/6
>
>
> 13530 root 20 0 98.2m 3244 2572 S1 0.0 29:28.86 flip_server
>
>
> 9425 root 20 0 17568 1592 1060 R0 0.0 0:04.16 top
>
>
> 10689 traffics 20 0 1960m 113m 4168 S0 0.4 0:00.54 [ET_NET 5]
>
>
> 10693 traffics 20 0 1960m 113m 4168 S0 0.4 0:00.51 [ET_NET 9]
>
>
> 10701 traffics 20 0 1960m 113m 4168 S0 0.4 0:00.56 [ET_NET 17]
>
>
> 10702 traffics 20 0 1960m 113m 4168 S0 0.4 0:00.53 [ET_NET 18]
>
>
> 10705 traffics 20 0 1960m 113m 4168 S0 0.4 0:00.54 [ET_NET 21]
>
>
> 1 root 20 0 24328 2256 1344 S0 0.0 0:02.53 init
>
>
> 2 root 20 0 000 S0 0.0 0:00.05 kthreadd
> stracing the ET_TASK threads showed a repeating set of calls to futex:
> futex(0x946ca4, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 255405471,
> {134
[jira] [Commented] (TS-1403) f_inbound_transparency is not handled by all accept cases
[ https://issues.apache.org/jira/browse/TS-1403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13613069#comment-13613069 ] Leif Hedstrom commented on TS-1403: --- Uri: Is this something you'd like to take ? If so, please assign it, and perhaps move to an appropriate fix version. > f_inbound_transparency is not handled by all accept cases > - > > Key: TS-1403 > URL: https://issues.apache.org/jira/browse/TS-1403 > Project: Traffic Server > Issue Type: Bug > Components: Network >Affects Versions: 3.2.0 >Reporter: Yossi Gottlieb >Priority: Minor > Fix For: 3.3.3 > > Attachments: transparency.diff > > > The inbound transparency flag does not always take affect, depending on the > accept configuration. This is not currently an issue because TSAPI doesn't > provide a standard transparent accept API, but it will become an issue once > the interface is created. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-1641) traffic server 3.2.0 crash log
[ https://issues.apache.org/jira/browse/TS-1641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-1641. --- Resolution: Cannot Reproduce Fix Version/s: (was: sometime) Closing since there's no details or response. > traffic server 3.2.0 crash log > -- > > Key: TS-1641 > URL: https://issues.apache.org/jira/browse/TS-1641 > Project: Traffic Server > Issue Type: Bug > Components: Cache >Reporter: lingjie.zhou > Labels: crash > > my traffic server 3.2.0 crash log is > NOTE: Traffic Server received Sig 11: Segmentation fault > /usr/local/ats/bin/traffic_server - STACK TRACE: > /lib64/libpthread.so.0[0x3a2fc0f500] > /usr/local/ats/bin/traffic_server(_ZN11MIMEHdrImpl9unmarshalEl+0x4e)[0x5c053e] > /usr/local/ats/bin/traffic_server(_ZN7HdrHeap9unmarshalEiiPP14HdrHeapObjImplP11RefCountObj+0x159)[0x5b3749] > /usr/local/ats/bin/traffic_server(_ZN8HTTPInfo9unmarshalEPciP11RefCountObj+0xed)[0x5b754d] > /usr/local/ats/bin/traffic_server(_ZN7CacheVC14handleReadDoneEiP5Event+0x753)[0x625ea3] > /usr/local/ats/bin/traffic_server(_ZN19AIOCallbackInternal11io_completeEiPv+0x35)[0x629665] > /usr/local/ats/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0xb4)[0x696a34] > /usr/local/ats/bin/traffic_server(_ZN7EThread7executeEv+0x5ab)[0x6974ab] > /usr/local/ats/bin/traffic_server[0x695a02] > /lib64/libpthread.so.0[0x3a2fc07851] > /lib64/libc.so.6(clone+0x6d)[0x3a2f4e767d] > after server auto restart , has new error log > WARNING: Unmarshal failed due to unknow obj type 139 after 776 bytes > Dumping header heap @ 0x2b119fa02110 - len 1230 -- > 0x2b119fa02110: 0xdcbafeed 0x3010010 0x9fa02498 0x2b11 > 0x2b119fa02120: 0x9fa02198 0x2b11 0x388 0x211200 > 0x2b119fa02130: 0x0 0x0 0x0 0x91815223 > 0x2b119fa02140: 0x0 0x0 0x407be50 0x2b11 > 0x2b119fa02150: 0x9fa02498 0x2b11 0x146 0x0 > 0x2b119fa02160: 0x0 0x205 0x0 0x0 > 0x2b119fa02170: 0x113600c4 0x2030100 0x5040404 0x50502 > 0x2b119fa02180: 0x0 0x0 0x4003103 0x22054112 > 0x2b119fa02190: 0x0 0x32148171 0x3003 0x1 > 0x2b119fa021a0: 0x10001 0x2e 0x9fa02418 0x2b11 > 0x2b119fa021b0: 0x9fa02498 0x2b11 0x6e0003 0x0 > 0x2b119fa021c0: 0x9fa021c8 0x2b11 0x25004 0x2b11 > 0x2b119fa021d0: 0x100040d 0x80800 0x7fff24f0 0xfffe > 0x2b119fa021e0: 0x 0xfff3 0x0 0x0 > 0x2b119fa021f0: 0x0 0x0 0x0 0x0 > 0x2b119fa02200: 0xfeb2bc23 0x8e02 0x58b9 0x0 > 0x2b119fa02210: 0x338df7d2 0x8a5ba0fd 0xd137ebf7 0xfa011339 > 0x2b119fa02220: 0x95669c3c 0x5bb57152 0xfcba3129 0x1218887c > 0x2b119fa02230: 0x9f0 0x1 0x0 0x2 > 0x2b119fa02240: 0x0 0xa0b0c0d0 0xdcbadeed 0x0 > 0x2b119fa02250: 0x 0x 0x 0x95669c3c > 0x2b119fa02260: 0x5bb57152 0xfcba3129 0x1218887c 0x58b9 > 0x2b119fa02270: 0x0 0x0 0xc8 0x0 > 0x2b119fa02280: 0xee1dc0c8 0x2b10 0xee1dc098 0x2b10 > 0x2b119fa02290: 0x0 0x0 0x0 0x0 > 0x2b119fa022a0: 0x0 0x0 0x0 0x0 > 0x2b119fa022b0: 0x0 0x0 0x5c0 0x0 > 0x2b119fa022c0: 0xa542b8c8 0x2b11 0xa542b898 0x2b11 > 0x2b119fa022d0: 0x0 0x0 0x0 0x0 > 0x2b119fa022e0: 0x0 0x0 0x0 0x0 > 0x2b119fa022f0: 0x0 0x0 0x50e114f3 0x0 > 0x2b119fa02300: 0x50e114f6 0x0 0x0 0x0 > 0x2b119fa02310: 0xdcbafeed 0x0 0x0 0x0 > 0x2b119fa02320: 0x88 0x0 0x388 0x0 > 0x2b119fa02330: 0x0 0x0 0x0 0x0 > 0x2b119fa02340: 0x0 0x0 0x0 0x0 > 0x2b119fa02350: 0x388 0x0 0x16e 0x0 > 0x2b119fa02360: 0x0 0x0 0x0 0x0 > 0x2b119fa02370: 0x0 0x0 0x0 0x0 > 0x2b119fa02380: 0x0 0x0 0x0 0x0 > 0x2b119fa02390: 0x0 0x0 0x3003 0x1 > 0x2b119fa023a0: 0x10001 0x0 0x308 0x0 > 0x2b119fa023b0: 0x388 0x0 0x6e0003 0x0 > 0x2b119fa023c0: 0xb8 0x0 0x25004 0x0 > 0x2b119fa023d0: 0x100040d 0x80800 0x7fff24f0 0xfffe > 0x2b119fa023e0: 0x 0xfff3 0x0 0x0 > 0x2b119fa023f0: 0x0 0x0 0x0 0x0 > 0x2b119fa02400: 0xf8 0x0 0x21005 0x9 > 0x2b119fa02410: 0x0 0x0 0x38b 0x0 > 0x2b119fa02420: 0x391 0x0 0x0 0x0 > 0x2b119fa02430: 0x60004 0x6832 0x3c3 0x0 > 0x2b119fa02440: 0x3ca 0x0 0x0 0x0 > 0x2b119fa02450: 0x70036 0x6825 0x3ef 0x0 > 0x2b119fa02460: 0x3fe 0x0 0x0 0x0 > 0x2b119fa02470: 0xf0002 0x6805 0x403 0x0 > 0x2b119fa02480: 0x40d 0x0 0x0 0x0 > 0x2b119fa02490: 0xa0040 0x6846 0x453 0x0 > 0x2b119fa024a0: 0x462 0x0 0x0 0x0 > 0x2b119fa024b0: 0xf0001 0x6804 0x466 0x0 > 0x2b119fa024c0: 0x46a 0x0 0x0 0x0 > 0x2b119fa024d0: 0x4001e 0x6816 0x9196c154 0x2b11 > 0x2b119fa024e0: 0x9196c160 0x2b11 0x0 0x0 > 0x2b119fa024f0: 0xa000c 0x790a 0x480 0x0 > 0x2b119fa02500: 0x489 0x0 0x0 0x0 > 0x2b119fa02510: 0x9000b 0x600e 0x497 0x0 > 0x2b119fa02520: 0x4a6 0x0 0x0 0x0 > 0x2b119fa02530: 0xf0078 0x600e 0x9d79e135 0x2b11 > 0x2b119fa02540: 0x9d79e147 0x2b11 0x0 0x0 > 0x2b119fa02550: 0x1e 0x6904 0xee189830 0x2b10 > 0x2b119fa02560: 0xee189833 0x2b10 0x0 0x0 > 0x2b119fa02570: 0x30005 0x6001 0xee189834 0x2b10 > 0x2b119fa02580:
[jira] [Assigned] (TS-1298) http_parser_parse_req appears inconsistent
[ https://issues.apache.org/jira/browse/TS-1298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-1298: - Assignee: Alan M. Carroll Alan, I'm assigning this to you. If you don't think this will be worked on for v3.3/v3.4, please move this out to v3.5 or "sometimes". > http_parser_parse_req appears inconsistent > -- > > Key: TS-1298 > URL: https://issues.apache.org/jira/browse/TS-1298 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Affects Versions: 3.0.2 >Reporter: Aidan McGurn >Assignee: Alan M. Carroll > Fix For: 3.3.3 > > > when using IPT setup i test as follows: > 1. telnet 80 from client machine //this will be routed via ATS as > IPT env > 2. write "test" in telnet window and hit return > 3. i *correctly* get a PARSE ERROR inside HTTP.cc/http_parser_parse_req > 1051if (!method_start || !method_end) > (gdb) > 1052 return PARSE_ERROR; > (gdb) p method_end > $4 = 0x0 > (gdb) p method_start > $5 = 0x12741000 "test\r\n" > However of i repeat step 2, with "test 2" method_end gets set and i end up > with a PARSE_DONE and it thinks *INCORRECTLY* therefore this is a HTTP > request. > Assume this is a bug and we are missing validation here or is this making > assumption the request is correct HTTP header format? > thanks for any assistance, > /aidan -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1298) http_parser_parse_req appears inconsistent
[ https://issues.apache.org/jira/browse/TS-1298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1298: -- Component/s: HTTP > http_parser_parse_req appears inconsistent > -- > > Key: TS-1298 > URL: https://issues.apache.org/jira/browse/TS-1298 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Affects Versions: 3.0.2 >Reporter: Aidan McGurn > Fix For: 3.3.3 > > > when using IPT setup i test as follows: > 1. telnet 80 from client machine //this will be routed via ATS as > IPT env > 2. write "test" in telnet window and hit return > 3. i *correctly* get a PARSE ERROR inside HTTP.cc/http_parser_parse_req > 1051if (!method_start || !method_end) > (gdb) > 1052 return PARSE_ERROR; > (gdb) p method_end > $4 = 0x0 > (gdb) p method_start > $5 = 0x12741000 "test\r\n" > However of i repeat step 2, with "test 2" method_end gets set and i end up > with a PARSE_DONE and it thinks *INCORRECTLY* therefore this is a HTTP > request. > Assume this is a bug and we are missing validation here or is this making > assumption the request is correct HTTP header format? > thanks for any assistance, > /aidan -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1063) prefetch resource leak
[
https://issues.apache.org/jira/browse/TS-1063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13613047#comment-13613047
]
Leif Hedstrom commented on TS-1063:
---
Is this still an issue ?
> prefetch resource leak
> ---
>
> Key: TS-1063
> URL: https://issues.apache.org/jira/browse/TS-1063
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
>Affects Versions: 3.0.2
> Environment: linux（ubuntu）
>Reporter: yunfei chen
> Fix For: 3.3.3
>
>
> configuration：
> records.config
>CONFIG proxy.config.prefetch.prefetch_enabled INT 1
>CONFIG proxy.config.prefetch.default_url_proto STRING udp
>CONFIG proxy.config.prefetch.default_data_proto STRING udp
> prefetch.config
>prefetch child
> [Dec 26 10:07:44.129] Server {2964810608} WARNING: too many connections,
> throttling
> [Dec 26 10:17:44.176] Server {2964810608} WARNING: too many connections,
> throttling
> FATAL: ink_memalign: couldn't allocate 524288 bytes at alignment 4096 -
> insufficient memory
> /usr/local/bin/traffic_server - STACK TRACE:
> FATAL: ink_memalign: couldn't allocate 524288 bytes at alignment 4096 -
> insufficient memory
> FATAL: ink_memalign: couldn't allocate 524288 bytes at alignment 4096 -
> insufficient memory
> /usr/local/bin/traffic_server - STACK TRACE:
> /usr/local/bin/traffic_server - STACK TRACE:
> FATAL: ink_memalign: couldn't allocate 524288 bytes at alignment 4096 -
> insufficient memory
> /usr/local/bin/traffic_server - STACK TRACE:
> FATAL: ink_memalign: couldn't allocate 524288 bytes at alignment 4096 -
> insufficient memory
> /usr/local/bin/traffic_server - STACK TRACE:
> terminate called after throwing an instance of 'std::bad_alloc'
> what(): std::bad_alloc
>
>
>
> #0 0x0012e416 in __kernel_vsyscall ()
> #1 0x005c9941 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
> #2 0x005cce42 in abort () at abort.c:92
> #3 0x00520055 in __gnu_cxx::__verbose_terminate_handler() () from
> /usr/lib/libstdc++.so.6
> #4 0x0051df35 in ?? () from /usr/lib/libstdc++.so.6
> #5 0x0051df72 in std::terminate() () from /usr/lib/libstdc++.so.6
> #6 0x0051e0e1 in __cxa_throw () from /usr/lib/libstdc++.so.6
> #7 0x0051e677 in operator new(unsigned int) () from /usr/lib/libstdc++.so.6
> #8 0x0051e74d in operator new[](unsigned int) () from /usr/lib/libstdc++.so.6
> #9 0x081488fd in DynArray::resize (this=0x748ff4c, new_size=64) at
> ../lib/ts/DynArray.h:174
> #10 0x0815d5da in DynArray::operator() (this=0x748ff4c, idx=0) at
> ../lib/ts/DynArray.h:122
> #11 0x0815a9bb in HtmlParser::ScanHtmlForURL (this=0x748ff3c, r=0xbabb3ac0,
> url=0xb70921ec, url_end=0xb70921e8) at Update.cc:1874
> #12 0x0815a86a in HtmlParser::ParseHtml (this=0x748ff3c, r=0xbabb3ac0,
> url=0xb70921ec, url_end=0xb70921e8) at Update.cc:1820
> #13 0x08140816 in PrefetchTransform::parse_data (this=0x748fe88,
> reader=0xbabb3ac0) at Prefetch.cc:543
> #14 0x0813ffe8 in PrefetchTransform::handle_event (this=0x748fe88, event=1,
> edata=0x5991b530) at Prefetch.cc:435
> #15 0x08104ba5 in Continuation::handleEvent (this=0x748fe88, event=1,
> data=0x5991b530)
> at ../iocore/eventsystem/I_Continuation.h:146
> #16 0x0830a9f5 in EThread::process_event (this=0xb7497008, e=0x5991b530,
> calling_code=1) at UnixEThread.cc:140
> #17 0x0830ac38 in EThread::execute (this=0xb7497008) at UnixEThread.cc:189
> #18 0x0830900e in spawn_thread_internal (a=0x895df28) at Thread.cc:88
> #19 0x00165cc9 in start_thread (arg=0xb7092b70) at pthread_create.c:304
> #20 0x0066f69e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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
]
Leif Hedstrom updated TS-1201:
--
Fix Version/s: (was: 3.3.3)
3.3.2
> Crash report: hostdb multicache, double free
>
>
> Key: TS-1201
> URL: https://issues.apache.org/jira/browse/TS-1201
> Project: Traffic Server
> Issue Type: Bug
> Components: DNS
>Reporter: Zhao Yongming
> Fix For: 3.3.2
>
>
> {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
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1201) Crash report: hostdb multicache, double free
[
https://issues.apache.org/jira/browse/TS-1201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13613049#comment-13613049
]
Leif Hedstrom commented on TS-1201:
---
It this still an issue ?
> Crash report: hostdb multicache, double free
>
>
> Key: TS-1201
> URL: https://issues.apache.org/jira/browse/TS-1201
> Project: Traffic Server
> Issue Type: Bug
> Components: DNS
>Reporter: Zhao Yongming
> Fix For: 3.3.3
>
>
> {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
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1290) the init script patch in RPM
[ https://issues.apache.org/jira/browse/TS-1290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13613054#comment-13613054 ] Leif Hedstrom commented on TS-1290: --- Yeah, lets get this in there. Worst case, I'll just take the .spec file from Fedora Core and put in here, unless someone else has a better "patch". > the init script patch in RPM > > > Key: TS-1290 > URL: https://issues.apache.org/jira/browse/TS-1290 > Project: Traffic Server > Issue Type: Improvement > Components: Portability >Affects Versions: 3.3.0 >Reporter: Zhao Yongming >Assignee: Zhao Yongming >Priority: Minor > Fix For: 3.3.2 > > > we have a patch in the RPM, should we put it in the git master? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1231) update.config Semicolon separated list of headers is not yet implemented
[
https://issues.apache.org/jira/browse/TS-1231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1231:
--
Fix Version/s: (was: 3.3.3)
3.5.0
> update.config Semicolon separated list of headers is not yet implemented
>
>
> Key: TS-1231
> URL: https://issues.apache.org/jira/browse/TS-1231
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
>Affects Versions: 3.1.3
>Reporter: Zhao Yongming
> Fix For: 3.5.0
>
>
> in update.config:
> {code}
> #
> ###
> # Content Management -- Scheduled Object Update
> ###
> #
> # Entry line syntax:
> # \
> #
> #1) URL
> # Syntax validated.
> #
> #2) Request Headers
> # Passed in each "GET" request.
> # Semicolon separated list of headers.
> {code}
> the request headers does not support multiple headers yet
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1290) the init script patch in RPM
[ https://issues.apache.org/jira/browse/TS-1290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1290: -- Fix Version/s: (was: 3.3.3) 3.3.2 > the init script patch in RPM > > > Key: TS-1290 > URL: https://issues.apache.org/jira/browse/TS-1290 > Project: Traffic Server > Issue Type: Improvement > Components: Portability >Affects Versions: 3.3.0 >Reporter: Zhao Yongming >Assignee: Zhao Yongming >Priority: Minor > Fix For: 3.3.2 > > > we have a patch in the RPM, should we put it in the git master? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1311) Range hit in cluster will crash server
[
https://issues.apache.org/jira/browse/TS-1311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13613062#comment-13613062
]
Leif Hedstrom commented on TS-1311:
---
Is this still an issue? Does it relate to the other Range: requests bugs that
we have either fixed, or working on ?
> Range hit in cluster will crash server
> --
>
> Key: TS-1311
> URL: https://issues.apache.org/jira/browse/TS-1311
> Project: Traffic Server
> Issue Type: Bug
> Components: Clustering, HTTP, Network
>Affects Versions: 3.3.0, 3.2.0
> Environment: cluster type 1, and range request hit, where the content
> is on the other hosts.
>Reporter: Zhao Yongming
> Fix For: 3.3.3
>
>
> with the changes in TS-475, the single ranged request will be handled by
> tunnel and pread. while this will crash in cluster env:
> {code}
> NOTE: Traffic Server received Sig 11: Segmentation fault
> /usr/bin/traffic_server - STACK TRACE:
> /lib64/libpthread.so.0[0x309f00f4a0]
> /usr/bin/traffic_server(HttpTunnel::consumer_handler(int,
> HttpTunnelConsumer*)+0x188)[0x555668]
> /usr/bin/traffic_server(HttpTunnel::main_handler(int, void*)+0x11d)[0x5554cd]
> /usr/bin/traffic_server[0x63fdab]
> /usr/bin/traffic_server(write_to_net_io(NetHandler*, UnixNetVConnection*,
> EThread*)+0x353)[0x643a13]
> /usr/bin/traffic_server(NetHandler::mainNetEvent(int, Event*)+0x2fe)[0x63befe]
> /usr/bin/traffic_server(EThread::process_event(Event*, int)+0xb4)[0x660a74]
> /usr/bin/traffic_server(EThread::execute()+0x4c3)[0x661403]
> /usr/bin/traffic_server[0x65fd82]
> /lib64/libpthread.so.0[0x309f0077f1]
> /lib64/libc.so.6(clone+0x6d)[0x309ece570d]
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-1290) the init script patch in RPM
[ https://issues.apache.org/jira/browse/TS-1290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-1290: - Assignee: Leif Hedstrom (was: Zhao Yongming) > the init script patch in RPM > > > Key: TS-1290 > URL: https://issues.apache.org/jira/browse/TS-1290 > Project: Traffic Server > Issue Type: Improvement > Components: Portability >Affects Versions: 3.3.0 >Reporter: Zhao Yongming >Assignee: Leif Hedstrom >Priority: Minor > Fix For: 3.3.2 > > > we have a patch in the RPM, should we put it in the git master? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (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 reassigned TS-1053:
-
Assignee: Leif Hedstrom
> 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
>Assignee: Leif Hedstrom
> Fix For: 3.3.2
>
> Attachments: combo_handler.diff, fetcher.diff, Makefile
>
>
> 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
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1308) dynamic reloading of ip_allow.config
[ https://issues.apache.org/jira/browse/TS-1308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1308: -- Fix Version/s: (was: 3.3.3) 3.5.0 > dynamic reloading of ip_allow.config > > > Key: TS-1308 > URL: https://issues.apache.org/jira/browse/TS-1308 > Project: Traffic Server > Issue Type: New Feature > Components: Configuration, Management >Affects Versions: 3.3.0 >Reporter: Zhao Yongming > Fix For: 3.5.0 > > > ip_allow.config is set to be a replacement for quick_filter, and then we can > move the method filter in remap.config into ip_allow.config, we should make > the config dynamic loadable. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1219) Crash report: ink_freelist_new causing core dumps
[
https://issues.apache.org/jira/browse/TS-1219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13613051#comment-13613051
]
Leif Hedstrom commented on TS-1219:
---
Manjesh and Brian G.: Is this still an issue with the changes done to the
current master for freelist?
> Crash report: ink_freelist_new causing core dumps
> -
>
> Key: TS-1219
> URL: https://issues.apache.org/jira/browse/TS-1219
> Project: Traffic Server
> Issue Type: Bug
>Affects Versions: 3.0.4, 3.0.2
>Reporter: Manjesh Nilange
> Fix For: 3.3.3
>
>
> Our TS based production boxes are seeing a couple of crashes per day with
> stack traces ending in
> #3 0x004c85ea in signal_handler (sig=11) at signals.cc:225
> #4
> #5 0x003312414160 in ink_freelist_new (f=0x3312629ce0) at
> ink_queue.cc:326
> #6 0x00331240d47a in alloc_void (this=0x7fff80173cd8, size=511,
> alignment=1) at Allocator.h:208
> #7 blk_alloc (this=0x7fff80173cd8, size=511, alignment=1) at Arena.cc:45
> #8 Arena::alloc (this=0x7fff80173cd8, size=511, alignment=1) at Arena.cc:118
> #9 0x00569b93 in str_alloc (arena=,
> url=0x31be6a8 "*"...,
> len_in=, len_out=0x7fff80173d20) at
> ../../lib/ts/Arena.h:123
> #10 LogUtils::escapify_url (arena=,
> url=0x31be6a8 "*"...,
> len_in=, len_out=0x7fff80173d20) at LogUtils.cc:392
> #11 0x005482e9 in LogAccessHttp::init (this=0x7fff80173cc0) at
> LogAccessHttp.cc:98
> #12 0x0054b436 in Log::access (lad=0x7fff80173cc0) at Log.cc:1055
> #13 0x004f3085 in HttpSM::update_stats (this=0x2ae5480651e0) at
> HttpSM.cc:6044
> #14 0x004f8918 in HttpSM::kill_this (this=0x2ae5480651e0) at
> HttpSM.cc:6005
> #15 0x004f8c08 in HttpSM::main_handler (this=0x2ae5480651e0,
> event=2301, data=0x2ae548066ec8)
> at HttpSM.cc:2452
> The URL was valid, I just "anonymized" it. This is our environment
> $ uname -a
> Linux xxx.prod 2.6.32-131.4.1.el6.x86_64 #1 SMP Fri Jun 10 10:54:26 EDT 2011
> x86_64 x86_64 x86_64 GNU/Linux
> $ file /usr/bin/traffic_server
> /usr/bin/traffic_server: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
> dynamically linked (uses shared libs), for GNU/Linux 2.6.18, stripped
> There doesn't seem to be more useful information in the frame:
> (gdb) f 5
> #5 0x003312414160 in ink_freelist_new (f=0x3312629ce0) at
> ink_queue.cc:326
> 326 FREELIST_VERSION(item) + 1);
> (gdb) list
> 321 fastalloc_mem_in_use += f->chunk_size * f->type_size;
> 322 #endif
> 323
> 324 } else {
> 325 SET_FREELIST_POINTER_VERSION(next,
> *ADDRESS_OF_NEXT(TO_PTR(FREELIST_POINTER(item)), f->offset),
> 326 FREELIST_VERSION(item) + 1);
> 327 #if !defined(INK_USE_MUTEX_FOR_FREELISTS)
> 328 result = ink_atomic_cas64((int64_t *) & f->head.data, item.data,
> next.data);
> 329 #else
> 330 f->head.data = next.data;
> (gdb) p next
> $2 =
> (gdb) p f
> $3 = (InkFreeList *) 0x3312629ce0
> (gdb) p *f
> $4 = {head = {data = -8941773651046140890}, name = 0x331241e92f "ArenaBlock",
> type_size = 1024, chunk_size = 128,
> count = 519, allocated = 1536, offset = 0, alignment = 8, allocated_base =
> 0, count_base = 0}
> (gdb) p item
> $5 = {data = -8953314125091277786}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1053) get combo_handler compiled
[
https://issues.apache.org/jira/browse/TS-1053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13613043#comment-13613043
]
Leif Hedstrom commented on TS-1053:
---
What's the status on this? Is this still relevant? Conan, if so, would you mind
making a new patchset for current master, and I can review / commit that.
Thanks!
-- Leif
> 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.3
>
> Attachments: combo_handler.diff, fetcher.diff, Makefile
>
>
> 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
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.3.3)
3.3.2
> 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.2
>
> Attachments: combo_handler.diff, fetcher.diff, Makefile
>
>
> 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
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-986) ts/experimental has a dependency on netinet/net.h (for struct in_addr)
[ https://issues.apache.org/jira/browse/TS-986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-986: - Fix Version/s: (was: 3.3.3) 3.3.2 Assignee: Leif Hedstrom I think as we start using ts/experimental.h for API additions, it's important that things compiles nicely. Even if it means including netinet/net.h (although, how do we do that cross platform safe?). Or, do the forward declarations like amc proposed. > ts/experimental has a dependency on netinet/net.h (for struct in_addr) > -- > > Key: TS-986 > URL: https://issues.apache.org/jira/browse/TS-986 > Project: Traffic Server > Issue Type: Improvement > Components: TS API >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom > Fix For: 3.3.2 > > > Alan seems to indicate this is wrong anyways, but just adding this bug so we > remember it's probably a bad idea. The offending API is > tsapi int TSNodeHandleToIPAddr(TSNodeHandle_t *h, struct in_addr *in); -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-898) fix potential problems from coverity scan
[ https://issues.apache.org/jira/browse/TS-898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-898: - Component/s: Core > fix potential problems from coverity scan > - > > Key: TS-898 > URL: https://issues.apache.org/jira/browse/TS-898 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Affects Versions: 3.0.0 > Environment: RHEL5 >Reporter: Bryan Call >Assignee: Bryan Call > Fix For: 3.5.0 > > > Ran Coverity over the code and it reported 856 potential problems with the > code. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-983) prefetch: the documents
[ https://issues.apache.org/jira/browse/TS-983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-983: - Component/s: HTTP Fix Version/s: (was: 3.3.3) sometime Not sure what this is about, moving out. > prefetch: the documents > --- > > Key: TS-983 > URL: https://issues.apache.org/jira/browse/TS-983 > Project: Traffic Server > Issue Type: Sub-task > Components: HTTP >Reporter: Zhao Yongming >Assignee: Zhao Yongming > Fix For: sometime > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1742) Freelists to use 64bit version w/ Double Word Compare and Swap
[
https://issues.apache.org/jira/browse/TS-1742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13613017#comment-13613017
]
ASF subversion and git services commented on TS-1742:
-
Commit 18aadb0c7b1a7f74935107764696bba702608635 in branch refs/heads/master
from James Peach
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=18aadb0 ]
TS-1742: use __sync_val_compare_and_swap for atomic 16 byte reads
clang correctly emits cmpxchg16b for __sync_val_compare_and_swap(),
so let's use that instead of __sync_fetch_and_add().
> Freelists to use 64bit version w/ Double Word Compare and Swap
> --
>
> Key: TS-1742
> URL: https://issues.apache.org/jira/browse/TS-1742
> Project: Traffic Server
> Issue Type: Improvement
>Reporter: Brian Geffon
>Assignee: Brian Geffon
> Fix For: 3.3.2
>
> Attachments: 128bit_cas.patch, 128bit_cas.patch.2
>
>
> So to those of you familiar with the freelists you know that it works this
> way the head pointer uses the upper 16 bits for a version to prevent the ABA
> problem. The big drawback to this is that it requires the following macros to
> get at the pointer or the version:
> {code}
> #define FREELIST_POINTER(_x) ((void*)(intptr_t)(_x).data)<<16)>>16) | \
> (((~intptr_t)(_x).data)<<16>>63)-1))>>48)<<48))) // sign extend
> #define FREELIST_VERSION(_x) (((intptr_t)(_x).data)>>48)
> #define SET_FREELIST_POINTER_VERSION(_x,_p,_v) \
> (_x).data = intptr_t)(_p))&0xULL) | (((_v)&0xULL)
> << 48))
> {code}
> Additionally, since this only leaves 16 bits it limits the number of versions
> you can have, well more and more x86_64 processors support DCAS (double word
> compare and swap / 128bit CAS). This means that we can use 64bits for a
> version which basically makes the versions unlimited but more importantly it
> takes those macros above and simplifies them to:
> {code}
> #define FREELIST_POINTER(_x) (_x).s.pointer
> #define FREELIST_VERSION(_x) (_x).s.version
> #define SET_FREELIST_POINTER_VERSION(_x,_p,_v) \
> (_x).s.pointer = _p; (_x).s.version = _v
> {code}
> As you can imagine this will have a performance improvement, in my simple
> tests I measured a performance improvement of around 6%. Unfortunately, I'm
> not an expert with this stuff and I would really appreciate more community
> feedback before I commit this patch.
> Note: this only applies if you're not using a reclaimable freelist.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1742) Freelists to use 64bit version w/ Double Word Compare and Swap
[
https://issues.apache.org/jira/browse/TS-1742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13613016#comment-13613016
]
ASF subversion and git services commented on TS-1742:
-
Commit 70e10888506cdd41fa8eae86a2878cfb8a71f0fa in branch refs/heads/master
from James Peach
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=70e1088 ]
TS-1742: Re-enable 16 byte compare and swap by default
> Freelists to use 64bit version w/ Double Word Compare and Swap
> --
>
> Key: TS-1742
> URL: https://issues.apache.org/jira/browse/TS-1742
> Project: Traffic Server
> Issue Type: Improvement
>Reporter: Brian Geffon
>Assignee: Brian Geffon
> Fix For: 3.3.2
>
> Attachments: 128bit_cas.patch, 128bit_cas.patch.2
>
>
> So to those of you familiar with the freelists you know that it works this
> way the head pointer uses the upper 16 bits for a version to prevent the ABA
> problem. The big drawback to this is that it requires the following macros to
> get at the pointer or the version:
> {code}
> #define FREELIST_POINTER(_x) ((void*)(intptr_t)(_x).data)<<16)>>16) | \
> (((~intptr_t)(_x).data)<<16>>63)-1))>>48)<<48))) // sign extend
> #define FREELIST_VERSION(_x) (((intptr_t)(_x).data)>>48)
> #define SET_FREELIST_POINTER_VERSION(_x,_p,_v) \
> (_x).data = intptr_t)(_p))&0xULL) | (((_v)&0xULL)
> << 48))
> {code}
> Additionally, since this only leaves 16 bits it limits the number of versions
> you can have, well more and more x86_64 processors support DCAS (double word
> compare and swap / 128bit CAS). This means that we can use 64bits for a
> version which basically makes the versions unlimited but more importantly it
> takes those macros above and simplifies them to:
> {code}
> #define FREELIST_POINTER(_x) (_x).s.pointer
> #define FREELIST_VERSION(_x) (_x).s.version
> #define SET_FREELIST_POINTER_VERSION(_x,_p,_v) \
> (_x).s.pointer = _p; (_x).s.version = _v
> {code}
> As you can imagine this will have a performance improvement, in my simple
> tests I measured a performance improvement of around 6%. Unfortunately, I'm
> not an expert with this stuff and I would really appreciate more community
> feedback before I commit this patch.
> Note: this only applies if you're not using a reclaimable freelist.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-898) fix potential problems from coverity scan
[ https://issues.apache.org/jira/browse/TS-898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-898: - Fix Version/s: (was: 3.3.3) 3.5.0 Bryan, I'm moving this out to v3.5.0 for now. You have any more info on this? Anything serious that we ought to look into for the v3.3/v3.4 release schedules? > fix potential problems from coverity scan > - > > Key: TS-898 > URL: https://issues.apache.org/jira/browse/TS-898 > Project: Traffic Server > Issue Type: Improvement >Affects Versions: 3.0.0 > Environment: RHEL5 >Reporter: Bryan Call >Assignee: Bryan Call > Fix For: 3.5.0 > > > Ran Coverity over the code and it reported 856 potential problems with the > code. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-794) ssl session reuse can not pass sslswamp testing
[
https://issues.apache.org/jira/browse/TS-794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13612972#comment-13612972
]
Leif Hedstrom commented on TS-794:
--
Ming, is this still an issue / problem? If not, please close, otherwise, help
suggest a fix version for this (3.5.0 if it won't go into 3.4.0).
> ssl session reuse can not pass sslswamp testing
> ---
>
> Key: TS-794
> URL: https://issues.apache.org/jira/browse/TS-794
> Project: Traffic Server
> Issue Type: Bug
> Components: SSL
>Affects Versions: 2.1.8
> Environment: sslv3 tlsv1
>Reporter: Zhao Yongming
> Fix For: 3.3.3
>
>
> When I testing from the patches from qianshi, for TS-718, the ssl session
> resumption looks perfect, but still can not pass the sslswamp testing, it
> looks like the second and later request will not be handled from the https
> connection. it may be a issue for https handler, here is some information
> testing from sslswamp:
> {code}
> [root@unknown-10-62-163-x ~]# sslswamp -connect IP:10.32.21.75:443 -num 1
> -count 4 -session srrr -update 10 -request "GET
> https://img02.taobaocdn.com/tps/i2/T1.SVEXcXJ-770-300.jpg
> HTTP/1.0\r\n\r\n" -session_ids -nologo -expect 64000 -sslmeth tlsv1
> No 'cacert' supplied, trying defaults ... '/usr/share/swamp/CA.pem' found.
> no client cert provided, continuing anyway.
> Certificate verification failed, probably a self-signed server cert *or*
> the signing CA cert is not trusted by us (hint: use '-CAfile').
> This message will only be printed once
> session-id[conn:0]:04E7E83CD58E8D566673EDB244146C808ECF7AF517CF39282017E053C7A7D0CC
> session-id[conn:0]:04E7E83CD58E8D566673EDB244146C808ECF7AF517CF39282017E053C7A7D0CC
> 120 seconds since starting, 1 successful, 0 failed, resumes(+1,-0) 0.01
> ops/sec
> 120 seconds since starting, 1 successful, 1 failed, resumes(+1,-0) 0.00
> ops/sec
> 120 seconds since starting, 1 successful, 1 failed, resumes(+1,-0) 0.00
> ops/sec
> session-id[conn:0]:04E7E83CD58E8D566673EDB244146C808ECF7AF517CF39282017E053C7A7D0CC
> 120 seconds since starting, 1 successful, 1 failed, resumes(+2,-0) 0.00
> ops/sec
> 240 seconds since starting, 1 successful, 1 failed, resumes(+2,-0) 0.00
> ops/sec
> 240 seconds since starting, 1 successful, 2 failed, resumes(+2,-0) 0.00
> ops/sec
> 240 seconds since starting, 1 successful, 2 failed, resumes(+2,-0) 0.00
> ops/sec
> session-id[conn:0]:04E7E83CD58E8D566673EDB244146C808ECF7AF517CF39282017E053C7A7D0CC
> 240 seconds since starting, 1 successful, 2 failed, resumes(+3,-0) 0.00
> ops/sec
> 361 seconds since starting, 1 successful, 2 failed, resumes(+3,-0) 0.00
> ops/sec
> 361 seconds since starting, 1 successful, 3 failed, resumes(+3,-0) 0.00
> ops/sec
> {code}
> the log from traffic.out:
> {code}
> [May 20 18:30:59.544] Manager {140339380279072} NOTE:
> [LocalManager::pollMgmtProcessServer] New process connecting fd '10'
> [May 20 18:30:59.544] Manager {140339380279072} NOTE: [Alarms::signalAlarm]
> Server Process born
> [May 20 18:31:00.564] {47816222021376} STATUS: opened
> /var/log/trafficserver/diags.log
> [May 20 18:31:00.613] {47816222021376} NOTE: updated diags config
> [May 20 18:31:00.648] Server {47816222021376} NOTE: cache clustering disabled
> [May 20 18:31:00.784] Server {47816222021376} NOTE: cache clustering disabled
> [May 20 18:31:01.237] Server {47816222021376} DEBUG: (ssl)
> [SSLNetProcessor::initSSLServerCTX] set the callback for external session
> caching.
> [May 20 18:31:01.412] Server {47816222021376} NOTE: logging initialized[7],
> logging_mode = 3
> [May 20 18:31:01.669] Server {47816222021376} NOTE: traffic server running
> [May 20 18:31:01.793] Server {47816237516544} NOTE: cache enabled
> [May 20 18:31:57.001] Server {47816310503168} DEBUG: (ssl)
> [ssl_callback_NewSessionCacheEntry] store id
> [D91C5F59EB43C5E8864303B449B9B1673D3218300EE03FDC4790125A7BCB521D]'s session
> into cache.
> [May 20 18:31:57.001] Server {47816310503168} DEBUG: (ssl)
> SSLNetVConnection::sslServerHandShakeEvent, handshake completed successfully
> [May 20 18:31:57.004] Server {47816310503168} DEBUG: (ssl)
> [SSL_NetVConnection::ssl_read_from_net] b->write_avail()=4096
> [May 20 18:31:57.004] Server {47816310503168} DEBUG: (ssl)
> [SSL_NetVConnection::ssl_read_from_net] rres=82
> SSL Read
> GET https://img02.taobaocdn.com/tps/i2/T1.SVEXcXJ-770-300.jpg HTTP/1.0
> [May 20 18:31:57.004] Server {47816310503168} DEBUG: (ssl)
> [SSL_NetVConnection::ssl_read_from_net] rres=-1
> [May 20 18:31:57.004] Server {47816310503168} DEBUG: (ssl)
> [SSL_NetVConnection::ssl_read_from_net] SSL_ERROR_WOULD_BLOCK
> [May 20 18:31:57.004] Server {47816310503168} DEBUG: (ssl)
> [SSL_NetVConnection::ssl_read_from_net] bytes_read=82
> [May 20 18:31:57.004] Server {4781631050
[jira] [Updated] (TS-855) TsConfig should be exposed as an API for plugins.
[ https://issues.apache.org/jira/browse/TS-855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-855: - Fix Version/s: (was: 3.3.3) sometime > TsConfig should be exposed as an API for plugins. > - > > Key: TS-855 > URL: https://issues.apache.org/jira/browse/TS-855 > Project: Traffic Server > Issue Type: Improvement > Components: Plugins >Affects Versions: 3.0.0 >Reporter: Alan M. Carroll >Assignee: Alan M. Carroll >Priority: Minor > Labels: api, plugin, tsconfig > Fix For: sometime > > > As more plugins are developed they will need configuration files. To promote > a more powerful style and consistency, TsConfig should be made easily > available for plugin development. In particular building a plugin with > TsConfig should not require building the ATS source. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-777) Increasing logbuffer size makes us "drop" log entries
[ https://issues.apache.org/jira/browse/TS-777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-777: - Fix Version/s: (was: 3.3.3) 3.5.0 Assignee: Leif Hedstrom Moving out to 3.5.0 since there's an easy workaround (simply don't touch this setting for now). It'd be a nice optimization though on busy systems to be able to jack this up. > Increasing logbuffer size makes us "drop" log entries > - > > Key: TS-777 > URL: https://issues.apache.org/jira/browse/TS-777 > Project: Traffic Server > Issue Type: Bug > Components: Logging >Affects Versions: 2.1.8 >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom > Fix For: 3.5.0 > > > Setting proxy.config.log.log_buffer_size higher than somewhere around 24KB > makes us start losing log entries. This is bad, since increasing this setting > could be a way to increase performance for busy systems. I've for now set the > defaults to 16KB, which seems to be stable. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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.3.3) 3.5.0 Moving to 3.5.0, please move back to 3.3.2/3/4 if anyone is going to work on this. > 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.5.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 For more information on JIRA, see: http://www.atlassian.com/software/jira
