[jira] [Commented] (TS-2039) Add Coverity automation (weekly) into our CI
[ https://issues.apache.org/jira/browse/TS-2039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14156606#comment-14156606 ] ASF subversion and git services commented on TS-2039: - Commit 97068fb8490901a154048f7597c918af8eaeafc2 in trafficserver's branch refs/heads/master from [~shinrich] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=97068fb ] TS-2039: Clean up coverity reported leaks in SSL examples and experimental plugin. Tidy up licenses and code standard issues. This closes #129 > Add Coverity automation (weekly) into our CI > > > Key: TS-2039 > URL: https://issues.apache.org/jira/browse/TS-2039 > Project: Traffic Server > Issue Type: New Feature > Components: Quality >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom > Fix For: Infrastructure > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3102) Reuse context memory for SPDY streams within a SPDY connection
[
https://issues.apache.org/jira/browse/TS-3102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14156610#comment-14156610
]
Sudheer Vinukonda commented on TS-3102:
---
Below is the dump for various memory allocators with SPDY on (975 qps, 26759
client conns)
proxy.process.spdy.current_client_sessions 12800
{code}
allocated |in-use | type size | free list name
|||--
67108864 | 0 |2097152 |
memory/ioBufAllocator[14]
134217728 | 68157440 |1048576 |
memory/ioBufAllocator[13]
83886080 | 52428800 | 524288 |
memory/ioBufAllocator[12]
125829120 | 96206848 | 262144 |
memory/ioBufAllocator[11]
155189248 | 123863040 | 131072 |
memory/ioBufAllocator[10]
77594624 | 65798144 | 65536 | memory/ioBufAllocator[9]
4507828224 | 975634432 | 32768 | memory/ioBufAllocator[8]
473432064 | 471482368 | 16384 | memory/ioBufAllocator[7]
1114374144 | 289726464 | 8192 | memory/ioBufAllocator[6]
1307574272 | 410095616 | 4096 | memory/ioBufAllocator[5]
3670016 |3557376 | 2048 | memory/ioBufAllocator[4]
1966080 |1818624 | 1024 | memory/ioBufAllocator[3]
917504 | 872448 |512 | memory/ioBufAllocator[2]
66551808 |2129920 |256 | memory/ioBufAllocator[1]
98304 | 77056 |128 | memory/ioBufAllocator[0]
59375616 |7501824 |512 | memory/FetchSMAllocator
0 | 0 |112 |
memory/ICPPeerReadContAllocator
0 | 0 |432 |
memory/PeerReadDataAllocator
0 | 0 |240 | memory/INKVConnAllocator
1351680 | 639552 | 96 | memory/INKContAllocator
1486848 | 839296 | 32 | memory/apiHookAllocator
0 | 0 | 96 |
memory/prefetchLockHandlerAllocator
0 | 0 |320 |
memory/PrefetchBlasterAllocator
0 | 0 |192 |
memory/prefetchUrlEntryAllocator
0 | 0 |128 |
memory/socksProxyAllocator
29417472 | 16528512 |672 |
memory/httpClientSessionAllocator
91193344 | 50746432 | 7744 | memory/httpSMAllocator
2179072 |1508640 |224 |
memory/httpServerSessionAllocator
0 | 0 | 48 |
memory/CacheLookupHttpConfigAllocator
0 | 0 | 7808 |
memory/httpUpdateSMAllocator
25976832 |3281376 |224 |
memory/spdyRequestAllocator
3887104 |2285504 |208 |
memory/spdyClientSessionAllocator
0 | 0 | 48 |
memory/CongestRequestParamAllocator
0 | 0 |144 |
memory/CongestionDBContAllocator
32768 | 0 |256 |
memory/httpCacheAltAllocator
0 | 0 |112 |
memory/OneWayTunnelAllocator
589824 | 2304 | 2304 |
memory/hostDBContAllocator
270848 | 33856 | 33856 | memory/dnsBufAllocator
163840 | 0 | 1280 | memory/dnsEntryAllocator
0 | 0 | 16 |
memory/DNSRequestDataAllocator
0 | 0 |576 |
memory/cacheContAllocator
0 | 0 |112 |
memory/inControlAllocator
0 | 0 |112 |
memory/outControlAllocator
0 | 0 | 32 | memory/byteBankAllocator
0 | 0 |592 |
memory/clusterVCAllocator
28262400 | 17633088 |736 | memory/sslNetVCAllocator
16732160 | 14234032 |688 | memory/netVCAllocator
0 | 0 |128 |
memory/udpReadContAllocator
0 | 0 |160 |
memory/udpPacketAllocator
0 | 0 |384 | memory/socksAllocator
0 | 0 |128 |
memory/UDPIOEventAllocator
94707712 | 12352704 | 64 | memory/ioBlockAllocator
42289152 | 10490064 | 48 | m
[jira] [Comment Edited] (TS-3102) Reuse context memory for SPDY streams within a SPDY connection
[
https://issues.apache.org/jira/browse/TS-3102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14156610#comment-14156610
]
Sudheer Vinukonda edited comment on TS-3102 at 10/2/14 2:28 PM:
Below is the dump for various memory allocators with SPDY on (975 qps, 26759
client conns)
proxy.process.spdy.current_client_sessions 12800
{code}
allocated |in-use | type size | free list name
|||--
67108864 | 0 |2097152 |
memory/ioBufAllocator[14]
134217728 | 68157440 |1048576 |
memory/ioBufAllocator[13]
83886080 | 52428800 | 524288 |
memory/ioBufAllocator[12]
125829120 | 96206848 | 262144 |
memory/ioBufAllocator[11]
155189248 | 123863040 | 131072 |
memory/ioBufAllocator[10]
77594624 | 65798144 | 65536 | memory/ioBufAllocator[9]
4507828224 | 975634432 | 32768 | memory/ioBufAllocator[8]
473432064 | 471482368 | 16384 | memory/ioBufAllocator[7]
1114374144 | 289726464 | 8192 | memory/ioBufAllocator[6]
1307574272 | 410095616 | 4096 | memory/ioBufAllocator[5]
3670016 |3557376 | 2048 | memory/ioBufAllocator[4]
1966080 |1818624 | 1024 | memory/ioBufAllocator[3]
917504 | 872448 |512 | memory/ioBufAllocator[2]
66551808 |2129920 |256 | memory/ioBufAllocator[1]
98304 | 77056 |128 | memory/ioBufAllocator[0]
59375616 |7501824 |512 | memory/FetchSMAllocator
0 | 0 |112 |
memory/ICPPeerReadContAllocator
0 | 0 |432 |
memory/PeerReadDataAllocator
0 | 0 |240 | memory/INKVConnAllocator
1351680 | 639552 | 96 | memory/INKContAllocator
1486848 | 839296 | 32 | memory/apiHookAllocator
0 | 0 | 96 |
memory/prefetchLockHandlerAllocator
0 | 0 |320 |
memory/PrefetchBlasterAllocator
0 | 0 |192 |
memory/prefetchUrlEntryAllocator
0 | 0 |128 |
memory/socksProxyAllocator
29417472 | 16528512 |672 |
memory/httpClientSessionAllocator
91193344 | 50746432 | 7744 | memory/httpSMAllocator
2179072 |1508640 |224 |
memory/httpServerSessionAllocator
0 | 0 | 48 |
memory/CacheLookupHttpConfigAllocator
0 | 0 | 7808 |
memory/httpUpdateSMAllocator
25976832 |3281376 |224 |
memory/spdyRequestAllocator
3887104 |2285504 |208 |
memory/spdyClientSessionAllocator
0 | 0 | 48 |
memory/CongestRequestParamAllocator
0 | 0 |144 |
memory/CongestionDBContAllocator
32768 | 0 |256 |
memory/httpCacheAltAllocator
0 | 0 |112 |
memory/OneWayTunnelAllocator
589824 | 2304 | 2304 |
memory/hostDBContAllocator
270848 | 33856 | 33856 | memory/dnsBufAllocator
163840 | 0 | 1280 | memory/dnsEntryAllocator
0 | 0 | 16 |
memory/DNSRequestDataAllocator
0 | 0 |576 |
memory/cacheContAllocator
0 | 0 |112 |
memory/inControlAllocator
0 | 0 |112 |
memory/outControlAllocator
0 | 0 | 32 | memory/byteBankAllocator
0 | 0 |592 |
memory/clusterVCAllocator
28262400 | 17633088 |736 | memory/sslNetVCAllocator
16732160 | 14234032 |688 | memory/netVCAllocator
0 | 0 |128 |
memory/udpReadContAllocator
0 | 0 |160 |
memory/udpPacketAllocator
0 | 0 |384 | memory/socksAllocator
0 | 0 |128 |
memory/UDPIOEventAllocator
94707712 | 12352704 | 64 | memory/ioBlockAllocator
[jira] [Commented] (TS-3102) Reuse context memory for SPDY streams within a SPDY connection
[ https://issues.apache.org/jira/browse/TS-3102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14156749#comment-14156749 ] Bryan Call commented on TS-3102: How long was the server running before the first memory dump was done in your comment above? It is using 4.5GB of ioBufAllocator[8] vs 751MB? It seems like the sever has been running for awhile and wouldn't make a good comparison. Do you have a patch you can attach to the bug? > Reuse context memory for SPDY streams within a SPDY connection > -- > > Key: TS-3102 > URL: https://issues.apache.org/jira/browse/TS-3102 > Project: Traffic Server > Issue Type: Improvement > Components: SPDY >Affects Versions: 5.0.1 >Reporter: Sudheer Vinukonda >Assignee: Sudheer Vinukonda > Labels: yahoo > Fix For: 5.2.0 > > > In the present SPDY implementation in ATS, there is no client context reuse. > Though the spdy session is reused, each stream (even the non-concurrent ones) > is allocated a set of new/separate context buffers (including internal > plugin_vc, client_session, SM object, header heap, transaction buffers, > server session objects etc). Some of these objects are allocated from global > pool, while some are from per-thread pool. The context memory is not reused > unlike the non-spdy session, where there can be at most one transaction on a > given connection/session at a time. > Besides being very inefficient (the allocation/deallocation) this also leads > to larger memory foot print over time, due to the relatively poor reuse of > per thread pool objects (especially, when there are a high number of threads > - e.g 100+ like we have). > I am currently testing a patch that does not deallocate the streams when the > transaction completes and reuses those for new/subsequent streams. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3102) Reuse context memory for SPDY streams within a SPDY connection
[ https://issues.apache.org/jira/browse/TS-3102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14156755#comment-14156755 ] Sudheer Vinukonda commented on TS-3102: --- Yes, I agree - the server without the reuse has been running a few hours longer than the one with the reuse. My comparison was not really between 4.5g vs 751mb, but rather the proportion of reuse. With the reuse patch, the reuse is clearly higher than the one without reuse. I will get more numbers once the reuse patch host also runs a few more hours. I am doing some more testing and will attach the patch later today or tomorrow. > Reuse context memory for SPDY streams within a SPDY connection > -- > > Key: TS-3102 > URL: https://issues.apache.org/jira/browse/TS-3102 > Project: Traffic Server > Issue Type: Improvement > Components: SPDY >Affects Versions: 5.0.1 >Reporter: Sudheer Vinukonda >Assignee: Sudheer Vinukonda > Labels: yahoo > Fix For: 5.2.0 > > > In the present SPDY implementation in ATS, there is no client context reuse. > Though the spdy session is reused, each stream (even the non-concurrent ones) > is allocated a set of new/separate context buffers (including internal > plugin_vc, client_session, SM object, header heap, transaction buffers, > server session objects etc). Some of these objects are allocated from global > pool, while some are from per-thread pool. The context memory is not reused > unlike the non-spdy session, where there can be at most one transaction on a > given connection/session at a time. > Besides being very inefficient (the allocation/deallocation) this also leads > to larger memory foot print over time, due to the relatively poor reuse of > per thread pool objects (especially, when there are a high number of threads > - e.g 100+ like we have). > I am currently testing a patch that does not deallocate the streams when the > transaction completes and reuses those for new/subsequent streams. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3106) ATS error responses do not flush request body
[ https://issues.apache.org/jira/browse/TS-3106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-3106: -- Fix Version/s: 5.2.0 > ATS error responses do not flush request body > - > > Key: TS-3106 > URL: https://issues.apache.org/jira/browse/TS-3106 > Project: Traffic Server > Issue Type: Bug >Reporter: Thomas Jackson >Assignee: Brian Geffon > Fix For: 5.2.0 > > > If you send a request to ATS which causes an error page (no remap, blocked > HTTP method, etc.) with a body, the following request will get a 403 > response. This is due to ATS not flushing the request body of the first > (failed) request. If you look in the logs for the second request you will see > the URL as "POSBODY GET /" (or something similar). I can easily reproduce > this on ATS 5. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3107) Remove RHEL5 from supported OS
[ https://issues.apache.org/jira/browse/TS-3107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber updated TS-3107: Priority: Blocker (was: Major) > Remove RHEL5 from supported OS > -- > > Key: TS-3107 > URL: https://issues.apache.org/jira/browse/TS-3107 > Project: Traffic Server > Issue Type: Task >Reporter: Phil Sorber >Priority: Blocker > Fix For: 6.0.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-3107) Remove RHEL5 from supported OS
Phil Sorber created TS-3107: --- Summary: Remove RHEL5 from supported OS Key: TS-3107 URL: https://issues.apache.org/jira/browse/TS-3107 Project: Traffic Server Issue Type: Task Reporter: Phil Sorber -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3107) Remove RHEL5 from supported OS
[ https://issues.apache.org/jira/browse/TS-3107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber updated TS-3107: Fix Version/s: 6.0.0 > Remove RHEL5 from supported OS > -- > > Key: TS-3107 > URL: https://issues.apache.org/jira/browse/TS-3107 > Project: Traffic Server > Issue Type: Task >Reporter: Phil Sorber > Fix For: 6.0.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3107) Remove RHEL5 from supported OS
[ https://issues.apache.org/jira/browse/TS-3107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber updated TS-3107: Description: We want to drop support for RHEL5 (and clones) when we release 6.0. We need more modern supporting libs like Flex and Bison. > Remove RHEL5 from supported OS > -- > > Key: TS-3107 > URL: https://issues.apache.org/jira/browse/TS-3107 > Project: Traffic Server > Issue Type: Task >Reporter: Phil Sorber >Priority: Blocker > Fix For: 6.0.0 > > > We want to drop support for RHEL5 (and clones) when we release 6.0. We need > more modern supporting libs like Flex and Bison. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3068) Remove usage of Boost
[ https://issues.apache.org/jira/browse/TS-3068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber updated TS-3068: Summary: Remove usage of Boost (was: Remove usage of Boost in header_rewrite) > Remove usage of Boost > - > > Key: TS-3068 > URL: https://issues.apache.org/jira/browse/TS-3068 > Project: Traffic Server > Issue Type: Improvement > Components: Plugins >Reporter: Phil Sorber >Assignee: Phil Sorber > Fix For: 5.2.0 > > Attachments: TS-3068.patch > > > Remove usage of Boost in header_rewrite that is not already covered by > TS-2231. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3068) Remove usage of Boost
[ https://issues.apache.org/jira/browse/TS-3068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14157015#comment-14157015 ] Phil Sorber commented on TS-3068: - Updated to remove all usage of boost which only extends to tsconfig at this point. > Remove usage of Boost > - > > Key: TS-3068 > URL: https://issues.apache.org/jira/browse/TS-3068 > Project: Traffic Server > Issue Type: Improvement > Components: Plugins >Reporter: Phil Sorber >Assignee: Phil Sorber > Fix For: 5.2.0 > > Attachments: TS-3068.patch > > > Remove usage of Boost in header_rewrite that is not already covered by > TS-2231. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3068) Remove usage of Boost
[ https://issues.apache.org/jira/browse/TS-3068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14157032#comment-14157032 ] ASF subversion and git services commented on TS-3068: - Commit adae7cd1603e52950832b72aa17d52c8146faead in trafficserver's branch refs/heads/master from [~psudaemon] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=adae7cd ] TS-3068: Remove usage of Boost > Remove usage of Boost > - > > Key: TS-3068 > URL: https://issues.apache.org/jira/browse/TS-3068 > Project: Traffic Server > Issue Type: Improvement > Components: Plugins >Reporter: Phil Sorber >Assignee: Phil Sorber > Fix For: 5.2.0 > > Attachments: TS-3068.patch > > > Remove usage of Boost in header_rewrite that is not already covered by > TS-2231. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (TS-2769) Can we eliminate boost dependency in libtsconfig ?
[ https://issues.apache.org/jira/browse/TS-2769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber closed TS-2769. --- Resolution: Duplicate > Can we eliminate boost dependency in libtsconfig ? > -- > > Key: TS-2769 > URL: https://issues.apache.org/jira/browse/TS-2769 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Reporter: Leif Hedstrom > > Similarly, we plan on eliminating boost from header_rewrite. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2769) Can we eliminate boost dependency in libtsconfig ?
[ https://issues.apache.org/jira/browse/TS-2769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber updated TS-2769: Fix Version/s: (was: sometime) > Can we eliminate boost dependency in libtsconfig ? > -- > > Key: TS-2769 > URL: https://issues.apache.org/jira/browse/TS-2769 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Reporter: Leif Hedstrom > > Similarly, we plan on eliminating boost from header_rewrite. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-3108) Add port matching condition to header_rewrite
Phil Sorber created TS-3108: --- Summary: Add port matching condition to header_rewrite Key: TS-3108 URL: https://issues.apache.org/jira/browse/TS-3108 Project: Traffic Server Issue Type: New Feature Reporter: Phil Sorber -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3108) Add port matching condition to header_rewrite
[ https://issues.apache.org/jira/browse/TS-3108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber updated TS-3108: Fix Version/s: 5.2.0 > Add port matching condition to header_rewrite > - > > Key: TS-3108 > URL: https://issues.apache.org/jira/browse/TS-3108 > Project: Traffic Server > Issue Type: New Feature >Reporter: Phil Sorber > Fix For: 5.2.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3108) Add port matching condition to header_rewrite
[ https://issues.apache.org/jira/browse/TS-3108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14157061#comment-14157061 ] ASF subversion and git services commented on TS-3108: - Commit 5054186f9083640583d366e732f18f846b65a6c2 in trafficserver's branch refs/heads/master from [~psudaemon] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=5054186 ] TS-3108: Add port matching condition to header_rewrite > Add port matching condition to header_rewrite > - > > Key: TS-3108 > URL: https://issues.apache.org/jira/browse/TS-3108 > Project: Traffic Server > Issue Type: New Feature >Reporter: Phil Sorber > Fix For: 5.2.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-3109) Build broken on ubuntu saucy64
Meera Mosale Nataraja created TS-3109: - Summary: Build broken on ubuntu saucy64 Key: TS-3109 URL: https://issues.apache.org/jira/browse/TS-3109 Project: Traffic Server Issue Type: Bug Components: Build Reporter: Meera Mosale Nataraja I am seeing following failure when I try to make with following gcov flags: export LDFLAGS="-lgcov -coverage" export CFLAGS="-fprofile-arcs -ftest-coverage" export CXXFLAGS="-fprofile-arcs -ftest-coverage" Failure: /usr/bin/ld: ../../iocore/eventsystem/libinkevent.a(UnixEventProcessor.o): undefined reference to symbol 'hwloc_get_type_depth' /usr/lib/x86_64-linux-gnu/libhwloc.so.5: error adding symbols: DSO missing from command line More logs: Making all in traffic_layout make[2]: Entering directory `/opt/src/trafficserver.git/cmd/traffic_layout' /bin/bash ../../libtool --tag=CXX --mode=link c++ -Wunused-parameter -fprofile-arcs -ftest-coverage -std=c++11 -g -pipe -Wall -O3 -feliminate-unused-debug-symbols -fno-strict-aliasing -Wno-invalid-offsetof -mcx16 -lgcov -coverage -o traffic_layout traffic_layout.o ../../lib/records/librecords_p.a ../../mgmt/libmgmt_p.la ../../iocore/eventsystem/libinkevent.a ../../proxy/shared/libUglyLogStubs.a ../../lib/ts/libtsutil.la -L/usr/lib/x86_64-linux-gnu -ltcl8.5 -lcap -lpcre -lz -lcrypt -lpthread -ldl -lxml2 libtool: link: c++ -Wunused-parameter -fprofile-arcs -ftest-coverage -std=c++11 -g -pipe -Wall -O3 -feliminate-unused-debug-symbols -fno-strict-aliasing -Wno-invalid-offsetof -mcx16 -coverage -o .libs/traffic_layout traffic_layout.o -lgcov ../../lib/records/librecords_p.a ../../mgmt/.libs/libmgmt_p.a ../../iocore/eventsystem/libinkevent.a ../../proxy/shared/libUglyLogStubs.a ../../lib/ts/.libs/libtsutil.so -L/usr/lib/x86_64-linux-gnu -ltcl8.5 -lcap -lpcre -lz -lcrypt -lpthread -ldl -lxml2 -Wl,-rpath -Wl,/opt/ats-cov/lib /usr/bin/ld: ../../iocore/eventsystem/libinkevent.a(UnixEventProcessor.o): undefined reference to symbol 'hwloc_get_type_depth' /usr/lib/x86_64-linux-gnu/libhwloc.so.5: error adding symbols: DSO missing from command line collect2: error: ld returned 1 exit status make[2]: *** [traffic_layout] Error 1 make[2]: Leaving directory `/opt/src/trafficserver.git/cmd/traffic_layout' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/opt/src/trafficserver.git/cmd' make: *** [all-recursive] Error 1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3109) Build broken on ubuntu saucy64
[ https://issues.apache.org/jira/browse/TS-3109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Meera Mosale Nataraja updated TS-3109: -- Priority: Minor (was: Major) > Build broken on ubuntu saucy64 > -- > > Key: TS-3109 > URL: https://issues.apache.org/jira/browse/TS-3109 > Project: Traffic Server > Issue Type: Bug > Components: Build >Reporter: Meera Mosale Nataraja >Priority: Minor > > I am seeing following failure when I try to make with following gcov flags: > export LDFLAGS="-lgcov -coverage" > export CFLAGS="-fprofile-arcs -ftest-coverage" > export CXXFLAGS="-fprofile-arcs -ftest-coverage" > Failure: > /usr/bin/ld: ../../iocore/eventsystem/libinkevent.a(UnixEventProcessor.o): > undefined reference to symbol 'hwloc_get_type_depth' > /usr/lib/x86_64-linux-gnu/libhwloc.so.5: error adding symbols: DSO missing > from command line > More logs: > Making all in traffic_layout > make[2]: Entering directory `/opt/src/trafficserver.git/cmd/traffic_layout' > /bin/bash ../../libtool --tag=CXX --mode=link c++ -Wunused-parameter > -fprofile-arcs -ftest-coverage -std=c++11 -g -pipe -Wall -O3 > -feliminate-unused-debug-symbols -fno-strict-aliasing -Wno-invalid-offsetof > -mcx16 -lgcov -coverage -o traffic_layout traffic_layout.o > ../../lib/records/librecords_p.a ../../mgmt/libmgmt_p.la > ../../iocore/eventsystem/libinkevent.a ../../proxy/shared/libUglyLogStubs.a > ../../lib/ts/libtsutil.la -L/usr/lib/x86_64-linux-gnu -ltcl8.5 -lcap -lpcre > -lz -lcrypt -lpthread -ldl -lxml2 > libtool: link: c++ -Wunused-parameter -fprofile-arcs -ftest-coverage > -std=c++11 -g -pipe -Wall -O3 -feliminate-unused-debug-symbols > -fno-strict-aliasing -Wno-invalid-offsetof -mcx16 -coverage -o > .libs/traffic_layout traffic_layout.o -lgcov > ../../lib/records/librecords_p.a ../../mgmt/.libs/libmgmt_p.a > ../../iocore/eventsystem/libinkevent.a ../../proxy/shared/libUglyLogStubs.a > ../../lib/ts/.libs/libtsutil.so -L/usr/lib/x86_64-linux-gnu -ltcl8.5 -lcap > -lpcre -lz -lcrypt -lpthread -ldl -lxml2 -Wl,-rpath -Wl,/opt/ats-cov/lib > /usr/bin/ld: ../../iocore/eventsystem/libinkevent.a(UnixEventProcessor.o): > undefined reference to symbol 'hwloc_get_type_depth' > /usr/lib/x86_64-linux-gnu/libhwloc.so.5: error adding symbols: DSO missing > from command line > collect2: error: ld returned 1 exit status > make[2]: *** [traffic_layout] Error 1 > make[2]: Leaving directory `/opt/src/trafficserver.git/cmd/traffic_layout' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/opt/src/trafficserver.git/cmd' > make: *** [all-recursive] Error 1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3044) linux native AIO should use eventfd if available to signal thread
[ https://issues.apache.org/jira/browse/TS-3044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14157141#comment-14157141 ] ASF subversion and git services commented on TS-3044: - Commit 86295176ccb5b7ef5c96686b398733e1edf6f2ee in trafficserver's branch refs/heads/master from [~jplevyak] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=8629517 ] TS-3044: Use eventfd in AIO_MODE_NATIVE if available > linux native AIO should use eventfd if available to signal thread > - > > Key: TS-3044 > URL: https://issues.apache.org/jira/browse/TS-3044 > Project: Traffic Server > Issue Type: Improvement > Components: Cache >Reporter: John Plevyak >Assignee: Phil Sorber > Fix For: 5.2.0 > > Attachments: native-aio-eventfd.patch > > > linux native AIO has the ability to signal the event thread to get off the > poll and service the disk via the io_set_eventfd() call. linux native AIO > scales better than the thread-based IO, but the current implementation can > introduce delays on lightly loaded systems because of the thread is waiting > on epoll(). This can be remedied by using io_set_eventfd -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3102) Reuse context memory for SPDY streams within a SPDY connection
[ https://issues.apache.org/jira/browse/TS-3102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheer Vinukonda updated TS-3102: -- Attachment: TS-3102.diff Note1: This patch allows for reuse of context memory and buffers associated with a spdy session (mainly via reusing FetchSM/PluginVC buffers). However, it seems like a popular idea to completely get rid of FetchSM layer, so, I am actually thinking about a solution to let SpdySession directly interface HttpClientSession via SpdyRequests. Will work on it after this interim fix. Note2: This patch is based off of our internal 5.0.1 branch and may not apply as it is to the master. > Reuse context memory for SPDY streams within a SPDY connection > -- > > Key: TS-3102 > URL: https://issues.apache.org/jira/browse/TS-3102 > Project: Traffic Server > Issue Type: Improvement > Components: SPDY >Affects Versions: 5.0.1 >Reporter: Sudheer Vinukonda >Assignee: Sudheer Vinukonda > Labels: yahoo > Fix For: 5.2.0 > > Attachments: TS-3102.diff > > > In the present SPDY implementation in ATS, there is no client context reuse. > Though the spdy session is reused, each stream (even the non-concurrent ones) > is allocated a set of new/separate context buffers (including internal > plugin_vc, client_session, SM object, header heap, transaction buffers, > server session objects etc). Some of these objects are allocated from global > pool, while some are from per-thread pool. The context memory is not reused > unlike the non-spdy session, where there can be at most one transaction on a > given connection/session at a time. > Besides being very inefficient (the allocation/deallocation) this also leads > to larger memory foot print over time, due to the relatively poor reuse of > per thread pool objects (especially, when there are a high number of threads > - e.g 100+ like we have). > I am currently testing a patch that does not deallocate the streams when the > transaction completes and reuses those for new/subsequent streams. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-3110) Logs aren't rotating as specified
Bryan Call created TS-3110:
--
Summary: Logs aren't rotating as specified
Key: TS-3110
URL: https://issues.apache.org/jira/browse/TS-3110
Project: Traffic Server
Issue Type: Bug
Components: Logging
Reporter: Bryan Call
When setting the logs to rotate at a specified size AND time interval they are
not rotating:
{code}
proxy.config.log.rolling_enabled 4
proxy.config.log.rolling_interval_sec 300
proxy.config.log.rolling_size_mb 10
-rw-r--r-- 1 nobody nobody 15M Oct 2 13:54 squid.blog
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3102) Reuse context memory for SPDY streams within a SPDY connection
[
https://issues.apache.org/jira/browse/TS-3102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14157241#comment-14157241
]
James Peach commented on TS-3102:
-
I need to review this more, and I would also like comments from [~briang]. So
far, I really don't like the additional state flags, and there are far too many
default function parameters that make it hard to figure out what will happen.
Even as an experimental API, {{TSFetchInit}} seems wildly dangerous.
I am having trouble following the performance argument above. Can you please
clarify what the performance issue is, and post some before/after numbers?
> Reuse context memory for SPDY streams within a SPDY connection
> --
>
> Key: TS-3102
> URL: https://issues.apache.org/jira/browse/TS-3102
> Project: Traffic Server
> Issue Type: Improvement
> Components: SPDY
>Affects Versions: 5.0.1
>Reporter: Sudheer Vinukonda
>Assignee: Sudheer Vinukonda
> Labels: yahoo
> Fix For: 5.2.0
>
> Attachments: TS-3102.diff
>
>
> In the present SPDY implementation in ATS, there is no client context reuse.
> Though the spdy session is reused, each stream (even the non-concurrent ones)
> is allocated a set of new/separate context buffers (including internal
> plugin_vc, client_session, SM object, header heap, transaction buffers,
> server session objects etc). Some of these objects are allocated from global
> pool, while some are from per-thread pool. The context memory is not reused
> unlike the non-spdy session, where there can be at most one transaction on a
> given connection/session at a time.
> Besides being very inefficient (the allocation/deallocation) this also leads
> to larger memory foot print over time, due to the relatively poor reuse of
> per thread pool objects (especially, when there are a high number of threads
> - e.g 100+ like we have).
> I am currently testing a patch that does not deallocate the streams when the
> transaction completes and reuses those for new/subsequent streams.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3102) Reuse context memory for SPDY streams within a SPDY connection
[ https://issues.apache.org/jira/browse/TS-3102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14157279#comment-14157279 ] Sudheer Vinukonda commented on TS-3102: --- Sure, thank you - comments are welcome :=) The issue I am trying to address is more memory than performance although performance and even stability suffer as a consequence of poor memory reuse with Spdy. On our proxy hosts with 16g ram and 1g ram cache, we are noticing disk swapping every 1-2 days when spdy is enabled (which only clears after a restart). Needless to say, once swapping starts, things start going bad quickly. Some sample comparison numbers for memory reuse are posted in my earlier comment (also a snippet below). I will run the patch for longer to get a more definite comparison. Without reuse: --- allocated | in-use | type size | free list name ---|--|--|- 4507828224 | 975634432 | 32768 | memory/ioBufAllocator[8] 1307574272 | 410095616 | 4096 | memory/ioBufAllocator[5] - 59375616 | 7501824 | 512 | memory/FetchSMAllocator 29417472 | 16528512 | 672 | memory/httpClientSessionAllocator 91193344 | 50746432 | 7744 | memory/httpSMAllocator 25976832 | 3281376 | 224 | memory/spdyRequestAllocator With reuse: -- allocated | in-use | type size | free list name ---|--|--|- 751828992 | 659357696 | 32768 | memory/ioBufAllocator[8] 531628032 | 501116928 | 4096 | memory/ioBufAllocator[5] 13631488 | 12464128 | 512 | memory/FetchSMAllocator 30535680 | 26612544 | 672 | memory/httpClientSessionAllocator 56500224 | 5064576 | 7744 | memory/httpSMAllocator 5963776 | 5453056 | 224 | memory/spdyRequestAllocator > Reuse context memory for SPDY streams within a SPDY connection > -- > > Key: TS-3102 > URL: https://issues.apache.org/jira/browse/TS-3102 > Project: Traffic Server > Issue Type: Improvement > Components: SPDY >Affects Versions: 5.0.1 >Reporter: Sudheer Vinukonda >Assignee: Sudheer Vinukonda > Labels: yahoo > Fix For: 5.2.0 > > Attachments: TS-3102.diff > > > In the present SPDY implementation in ATS, there is no client context reuse. > Though the spdy session is reused, each stream (even the non-concurrent ones) > is allocated a set of new/separate context buffers (including internal > plugin_vc, client_session, SM object, header heap, transaction buffers, > server session objects etc). Some of these objects are allocated from global > pool, while some are from per-thread pool. The context memory is not reused > unlike the non-spdy session, where there can be at most one transaction on a > given connection/session at a time. > Besides being very inefficient (the allocation/deallocation) this also leads > to larger memory foot print over time, due to the relatively poor reuse of > per thread pool objects (especially, when there are a high number of threads > - e.g 100+ like we have). > I am currently testing a patch that does not deallocate the streams when the > transaction completes and reuses those for new/subsequent streams. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TS-3103) improve privilege elevation
[ https://issues.apache.org/jira/browse/TS-3103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach resolved TS-3103. - Resolution: Fixed > improve privilege elevation > --- > > Key: TS-3103 > URL: https://issues.apache.org/jira/browse/TS-3103 > Project: Traffic Server > Issue Type: Improvement > Components: Core, Security >Reporter: James Peach >Assignee: James Peach > Fix For: 5.2.0 > > > Improve privilege elevation so that we have a single function that alters > process credentials, and does it correctly. > Here is the behavior I plan to implement: >1. traffic_manager runs with real root credentials, but > effective credentials as given by proxy.config.admin.user_id. > It will elevate back to root to perform privileged operations. >2. traffic_server is started with real root credentials, > but attempts to permanently drop to an unprivileged user early > in the startup process. The unprivileged user account for > traffic_server is also given by proxy.config.admin.user_id. > when traffic_server drops privilege, it does so permanently. >3. traffic_server may elevate privilege depending on the > value of proxy.config.ssl.cert.load_elevated and > proxy.config.plugin.load_elevated. This elevation will only > be supported on platforms that have per-thread capabilities. > traffic_server will check at startup whether to retain > sufficient capabilities to allow it to elevate later. This > means that the *.load_elevated configurations will not be > reloadable. >4. After traffic_server drops privilege, we will continue to abort > with a fatal error if the real or effective user ID is root. This > behavior can be avoided by defining BIG_SECURITY_HOLE=1 at build > time. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3103) improve privilege elevation
[ https://issues.apache.org/jira/browse/TS-3103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14157457#comment-14157457 ] ASF subversion and git services commented on TS-3103: - Commit 0f0c1633beeab24cca6a312a44b0aa4e39fb57cd in trafficserver's branch refs/heads/master from [~jpe...@apache.org] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=0f0c163 ] TS-3103: improve privilege debug logging fix better debugging for DebugCapabilities > improve privilege elevation > --- > > Key: TS-3103 > URL: https://issues.apache.org/jira/browse/TS-3103 > Project: Traffic Server > Issue Type: Improvement > Components: Core, Security >Reporter: James Peach >Assignee: James Peach > Fix For: 5.2.0 > > > Improve privilege elevation so that we have a single function that alters > process credentials, and does it correctly. > Here is the behavior I plan to implement: >1. traffic_manager runs with real root credentials, but > effective credentials as given by proxy.config.admin.user_id. > It will elevate back to root to perform privileged operations. >2. traffic_server is started with real root credentials, > but attempts to permanently drop to an unprivileged user early > in the startup process. The unprivileged user account for > traffic_server is also given by proxy.config.admin.user_id. > when traffic_server drops privilege, it does so permanently. >3. traffic_server may elevate privilege depending on the > value of proxy.config.ssl.cert.load_elevated and > proxy.config.plugin.load_elevated. This elevation will only > be supported on platforms that have per-thread capabilities. > traffic_server will check at startup whether to retain > sufficient capabilities to allow it to elevate later. This > means that the *.load_elevated configurations will not be > reloadable. >4. After traffic_server drops privilege, we will continue to abort > with a fatal error if the real or effective user ID is root. This > behavior can be avoided by defining BIG_SECURITY_HOLE=1 at build > time. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3103) improve privilege elevation
[ https://issues.apache.org/jira/browse/TS-3103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14157454#comment-14157454 ] ASF subversion and git services commented on TS-3103: - Commit 549108ea80913975e52e4d5a9b4fc1404fbecf2a in trafficserver's branch refs/heads/master from [~jpe...@apache.org] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=549108e ] TS-3103: use scoped ElevateAccess to elevate privileges Rather than using explicit root privilege escalation, elevate privilege using the scope ElevateAccess wrapper. > improve privilege elevation > --- > > Key: TS-3103 > URL: https://issues.apache.org/jira/browse/TS-3103 > Project: Traffic Server > Issue Type: Improvement > Components: Core, Security >Reporter: James Peach >Assignee: James Peach > Fix For: 5.2.0 > > > Improve privilege elevation so that we have a single function that alters > process credentials, and does it correctly. > Here is the behavior I plan to implement: >1. traffic_manager runs with real root credentials, but > effective credentials as given by proxy.config.admin.user_id. > It will elevate back to root to perform privileged operations. >2. traffic_server is started with real root credentials, > but attempts to permanently drop to an unprivileged user early > in the startup process. The unprivileged user account for > traffic_server is also given by proxy.config.admin.user_id. > when traffic_server drops privilege, it does so permanently. >3. traffic_server may elevate privilege depending on the > value of proxy.config.ssl.cert.load_elevated and > proxy.config.plugin.load_elevated. This elevation will only > be supported on platforms that have per-thread capabilities. > traffic_server will check at startup whether to retain > sufficient capabilities to allow it to elevate later. This > means that the *.load_elevated configurations will not be > reloadable. >4. After traffic_server drops privilege, we will continue to abort > with a fatal error if the real or effective user ID is root. This > behavior can be avoided by defining BIG_SECURITY_HOLE=1 at build > time. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3103) improve privilege elevation
[ https://issues.apache.org/jira/browse/TS-3103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14157456#comment-14157456 ] ASF subversion and git services commented on TS-3103: - Commit c20580866485cd6f61387b20c81361fa8709d89d in trafficserver's branch refs/heads/master from [~jpe...@apache.org] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=c205808 ] TS-3103: hide ElevateAccess implementation details > improve privilege elevation > --- > > Key: TS-3103 > URL: https://issues.apache.org/jira/browse/TS-3103 > Project: Traffic Server > Issue Type: Improvement > Components: Core, Security >Reporter: James Peach >Assignee: James Peach > Fix For: 5.2.0 > > > Improve privilege elevation so that we have a single function that alters > process credentials, and does it correctly. > Here is the behavior I plan to implement: >1. traffic_manager runs with real root credentials, but > effective credentials as given by proxy.config.admin.user_id. > It will elevate back to root to perform privileged operations. >2. traffic_server is started with real root credentials, > but attempts to permanently drop to an unprivileged user early > in the startup process. The unprivileged user account for > traffic_server is also given by proxy.config.admin.user_id. > when traffic_server drops privilege, it does so permanently. >3. traffic_server may elevate privilege depending on the > value of proxy.config.ssl.cert.load_elevated and > proxy.config.plugin.load_elevated. This elevation will only > be supported on platforms that have per-thread capabilities. > traffic_server will check at startup whether to retain > sufficient capabilities to allow it to elevate later. This > means that the *.load_elevated configurations will not be > reloadable. >4. After traffic_server drops privilege, we will continue to abort > with a fatal error if the real or effective user ID is root. This > behavior can be avoided by defining BIG_SECURITY_HOLE=1 at build > time. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3103) improve privilege elevation
[ https://issues.apache.org/jira/browse/TS-3103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14157458#comment-14157458 ] ASF subversion and git services commented on TS-3103: - Commit 33f651c90f1832188408d859ab59c03ad2b3de01 in trafficserver's branch refs/heads/master from [~jpe...@apache.org] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=33f651c ] TS-3103: improve privilege elevation Remove duplicate user credential routines in favor of a single ImpersonateUser function. This correctly dealt with real and effective credentials, supplementary groups and preserving additional process flags. Set and preserve PR_SET_PDEATHSIG on Linux so that killing traffic_cop correctly brings down the rest of the system. Log and ignore proxy.config.ssl.cert.load_elevated and proxy.config.plugin.load_elevated unless POSIX capabilities are enabled. > improve privilege elevation > --- > > Key: TS-3103 > URL: https://issues.apache.org/jira/browse/TS-3103 > Project: Traffic Server > Issue Type: Improvement > Components: Core, Security >Reporter: James Peach >Assignee: James Peach > Fix For: 5.2.0 > > > Improve privilege elevation so that we have a single function that alters > process credentials, and does it correctly. > Here is the behavior I plan to implement: >1. traffic_manager runs with real root credentials, but > effective credentials as given by proxy.config.admin.user_id. > It will elevate back to root to perform privileged operations. >2. traffic_server is started with real root credentials, > but attempts to permanently drop to an unprivileged user early > in the startup process. The unprivileged user account for > traffic_server is also given by proxy.config.admin.user_id. > when traffic_server drops privilege, it does so permanently. >3. traffic_server may elevate privilege depending on the > value of proxy.config.ssl.cert.load_elevated and > proxy.config.plugin.load_elevated. This elevation will only > be supported on platforms that have per-thread capabilities. > traffic_server will check at startup whether to retain > sufficient capabilities to allow it to elevate later. This > means that the *.load_elevated configurations will not be > reloadable. >4. After traffic_server drops privilege, we will continue to abort > with a fatal error if the real or effective user ID is root. This > behavior can be avoided by defining BIG_SECURITY_HOLE=1 at build > time. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3106) ATS error responses do not flush request body
[ https://issues.apache.org/jira/browse/TS-3106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14157575#comment-14157575 ] Thomas Jackson commented on TS-3106: Been digging a little bit to see how other proxies handle this case (redirect or something similar when a body is involved). I dug through the haproxy source and what they do is check if the request can have a body-- and if so they will close the connection, otherwise the connection is kept alive. This should be doable in ATS as it already enforces that certain types of requests cannot have bodies (such as HEAD requests, you get a 403). References: - https://github.com/haproxy/haproxy/blob/master/src/proto_http.c#L3943 - https://github.com/haproxy/haproxy/blob/master/src/proto_http.c#L6042 > ATS error responses do not flush request body > - > > Key: TS-3106 > URL: https://issues.apache.org/jira/browse/TS-3106 > Project: Traffic Server > Issue Type: Bug >Reporter: Thomas Jackson >Assignee: Brian Geffon > Fix For: 5.2.0 > > > If you send a request to ATS which causes an error page (no remap, blocked > HTTP method, etc.) with a body, the following request will get a 403 > response. This is due to ATS not flushing the request body of the first > (failed) request. If you look in the logs for the second request you will see > the URL as "POSBODY GET /" (or something similar). I can easily reproduce > this on ATS 5. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3110) Logs aren't rotating as specified
[
https://issues.apache.org/jira/browse/TS-3110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-3110:
--
Fix Version/s: 5.2.0
> Logs aren't rotating as specified
> -
>
> Key: TS-3110
> URL: https://issues.apache.org/jira/browse/TS-3110
> Project: Traffic Server
> Issue Type: Bug
> Components: Logging
>Reporter: Bryan Call
> Fix For: 5.2.0
>
>
> When setting the logs to rotate at a specified size AND time interval they
> are not rotating:
> {code}
> proxy.config.log.rolling_enabled 4
> proxy.config.log.rolling_interval_sec 300
> proxy.config.log.rolling_size_mb 10
> -rw-r--r-- 1 nobody nobody 15M Oct 2 13:54 squid.blog
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
