[jira] [Commented] (TS-1006) memory management, cut down memory waste ?
[
https://issues.apache.org/jira/browse/TS-1006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13614983#comment-13614983
]
jaekyung oh commented on TS-1006:
-
yes. with last final patch i always put --enable-reclaimable-freelist=yes
same error happens on both 3.2.0 and 3.2.4
memory management, cut down memory waste ?
--
Key: TS-1006
URL: https://issues.apache.org/jira/browse/TS-1006
Project: Traffic Server
Issue Type: Improvement
Components: Core
Affects Versions: 3.1.1
Reporter: Zhao Yongming
Assignee: Bin Chen
Fix For: 3.3.3
Attachments:
0001-TS-1006-Add-an-enable-reclaimable-freelist-option.patch,
0002-TS-1006-Add-a-new-wrapper-ink_atomic_decrement.patch,
0003-TS-1006-Introduce-a-reclaimable-InkFreeList.patch,
0004-TS-1006-Make-InkFreeList-memory-pool-configurable.patch,
Memory-Usage-After-Introduced-New-Allocator.png, memusage.ods, memusage.ods
when we review the memory usage in the production, there is something
abnormal, ie, looks like TS take much memory than index data + common system
waste, and here is some memory dump result by set
proxy.config.dump_mem_info_frequency
1, the one on a not so busy forwarding system:
physics memory: 32G
RAM cache: 22G
DISK: 6140 GB
average_object_size 64000
{code}
allocated |in-use | type size | free list name
|||--
671088640 | 37748736 |2097152 |
memory/ioBufAllocator[14]
2248146944 | 2135949312 |1048576 |
memory/ioBufAllocator[13]
1711276032 | 1705508864 | 524288 |
memory/ioBufAllocator[12]
1669332992 | 1667760128 | 262144 |
memory/ioBufAllocator[11]
2214592512 | 221184 | 131072 |
memory/ioBufAllocator[10]
2325741568 | 2323775488 | 65536 |
memory/ioBufAllocator[9]
2091909120 | 2089123840 | 32768 |
memory/ioBufAllocator[8]
1956642816 | 1956478976 | 16384 |
memory/ioBufAllocator[7]
2094530560 | 2094071808 | 8192 |
memory/ioBufAllocator[6]
356515840 | 355540992 | 4096 |
memory/ioBufAllocator[5]
1048576 | 14336 | 2048 |
memory/ioBufAllocator[4]
131072 | 0 | 1024 |
memory/ioBufAllocator[3]
65536 | 0 |512 |
memory/ioBufAllocator[2]
32768 | 0 |256 |
memory/ioBufAllocator[1]
16384 | 0 |128 |
memory/ioBufAllocator[0]
0 | 0 |576 |
memory/ICPRequestCont_allocator
0 | 0 |112 |
memory/ICPPeerReadContAllocator
0 | 0 |432 |
memory/PeerReadDataAllocator
0 | 0 | 32 |
memory/MIMEFieldSDKHandle
0 | 0 |240 |
memory/INKVConnAllocator
0 | 0 | 96 |
memory/INKContAllocator
4096 | 0 | 32 |
memory/apiHookAllocator
0 | 0 |288 |
memory/FetchSMAllocator
0 | 0 | 80 |
memory/prefetchLockHandlerAllocator
0 | 0 |176 |
memory/PrefetchBlasterAllocator
0 | 0 | 80 |
memory/prefetchUrlBlaster
0 | 0 | 96 | memory/blasterUrlList
0 | 0 | 96 |
memory/prefetchUrlEntryAllocator
0 | 0 |128 |
memory/socksProxyAllocator
0 | 0 |144 |
memory/ObjectReloadCont
3258368 | 576016 |592 |
memory/httpClientSessionAllocator
825344 | 139568 |208 |
memory/httpServerSessionAllocator
22597632 |1284848 | 9808 | memory/httpSMAllocator
0 | 0 | 32 |
memory/CacheLookupHttpConfigAllocator
0 | 0 | 9856 |
memory/httpUpdateSMAllocator
0 | 0 |128 |
memory/RemapPluginsAlloc
0 | 0 | 48 |
memory/CongestRequestParamAllocator
0 | 0 |128 |
memory/CongestionDBContAllocator
5767168 |
[jira] [Commented] (TS-1006) memory management, cut down memory waste ?
[
https://issues.apache.org/jira/browse/TS-1006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13614985#comment-13614985
]
Yunkai Zhang commented on TS-1006:
--
1) The format seems error,
it should be ./configure --enable-reclaimable-freelist, need not =yes.
memory management, cut down memory waste ?
--
Key: TS-1006
URL: https://issues.apache.org/jira/browse/TS-1006
Project: Traffic Server
Issue Type: Improvement
Components: Core
Affects Versions: 3.1.1
Reporter: Zhao Yongming
Assignee: Bin Chen
Fix For: 3.3.3
Attachments:
0001-TS-1006-Add-an-enable-reclaimable-freelist-option.patch,
0002-TS-1006-Add-a-new-wrapper-ink_atomic_decrement.patch,
0003-TS-1006-Introduce-a-reclaimable-InkFreeList.patch,
0004-TS-1006-Make-InkFreeList-memory-pool-configurable.patch,
Memory-Usage-After-Introduced-New-Allocator.png, memusage.ods, memusage.ods
when we review the memory usage in the production, there is something
abnormal, ie, looks like TS take much memory than index data + common system
waste, and here is some memory dump result by set
proxy.config.dump_mem_info_frequency
1, the one on a not so busy forwarding system:
physics memory: 32G
RAM cache: 22G
DISK: 6140 GB
average_object_size 64000
{code}
allocated |in-use | type size | free list name
|||--
671088640 | 37748736 |2097152 |
memory/ioBufAllocator[14]
2248146944 | 2135949312 |1048576 |
memory/ioBufAllocator[13]
1711276032 | 1705508864 | 524288 |
memory/ioBufAllocator[12]
1669332992 | 1667760128 | 262144 |
memory/ioBufAllocator[11]
2214592512 | 221184 | 131072 |
memory/ioBufAllocator[10]
2325741568 | 2323775488 | 65536 |
memory/ioBufAllocator[9]
2091909120 | 2089123840 | 32768 |
memory/ioBufAllocator[8]
1956642816 | 1956478976 | 16384 |
memory/ioBufAllocator[7]
2094530560 | 2094071808 | 8192 |
memory/ioBufAllocator[6]
356515840 | 355540992 | 4096 |
memory/ioBufAllocator[5]
1048576 | 14336 | 2048 |
memory/ioBufAllocator[4]
131072 | 0 | 1024 |
memory/ioBufAllocator[3]
65536 | 0 |512 |
memory/ioBufAllocator[2]
32768 | 0 |256 |
memory/ioBufAllocator[1]
16384 | 0 |128 |
memory/ioBufAllocator[0]
0 | 0 |576 |
memory/ICPRequestCont_allocator
0 | 0 |112 |
memory/ICPPeerReadContAllocator
0 | 0 |432 |
memory/PeerReadDataAllocator
0 | 0 | 32 |
memory/MIMEFieldSDKHandle
0 | 0 |240 |
memory/INKVConnAllocator
0 | 0 | 96 |
memory/INKContAllocator
4096 | 0 | 32 |
memory/apiHookAllocator
0 | 0 |288 |
memory/FetchSMAllocator
0 | 0 | 80 |
memory/prefetchLockHandlerAllocator
0 | 0 |176 |
memory/PrefetchBlasterAllocator
0 | 0 | 80 |
memory/prefetchUrlBlaster
0 | 0 | 96 | memory/blasterUrlList
0 | 0 | 96 |
memory/prefetchUrlEntryAllocator
0 | 0 |128 |
memory/socksProxyAllocator
0 | 0 |144 |
memory/ObjectReloadCont
3258368 | 576016 |592 |
memory/httpClientSessionAllocator
825344 | 139568 |208 |
memory/httpServerSessionAllocator
22597632 |1284848 | 9808 | memory/httpSMAllocator
0 | 0 | 32 |
memory/CacheLookupHttpConfigAllocator
0 | 0 | 9856 |
memory/httpUpdateSMAllocator
0 | 0 |128 |
memory/RemapPluginsAlloc
0 | 0 | 48 |
memory/CongestRequestParamAllocator
0 | 0 |128 |
memory/CongestionDBContAllocator
5767168 | 704512 | 2048
[jira] [Comment Edited] (TS-1006) memory management, cut down memory waste ?
[
https://issues.apache.org/jira/browse/TS-1006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13614985#comment-13614985
]
Yunkai Zhang edited comment on TS-1006 at 3/27/13 7:05 AM:
---
The format seems error,
it should be ./configure --enable-reclaimable-freelist, need not =yes.
was (Author: yunkai):
1) The format seems error,
it should be ./configure --enable-reclaimable-freelist, need not =yes.
memory management, cut down memory waste ?
--
Key: TS-1006
URL: https://issues.apache.org/jira/browse/TS-1006
Project: Traffic Server
Issue Type: Improvement
Components: Core
Affects Versions: 3.1.1
Reporter: Zhao Yongming
Assignee: Bin Chen
Fix For: 3.3.3
Attachments:
0001-TS-1006-Add-an-enable-reclaimable-freelist-option.patch,
0002-TS-1006-Add-a-new-wrapper-ink_atomic_decrement.patch,
0003-TS-1006-Introduce-a-reclaimable-InkFreeList.patch,
0004-TS-1006-Make-InkFreeList-memory-pool-configurable.patch,
Memory-Usage-After-Introduced-New-Allocator.png, memusage.ods, memusage.ods
when we review the memory usage in the production, there is something
abnormal, ie, looks like TS take much memory than index data + common system
waste, and here is some memory dump result by set
proxy.config.dump_mem_info_frequency
1, the one on a not so busy forwarding system:
physics memory: 32G
RAM cache: 22G
DISK: 6140 GB
average_object_size 64000
{code}
allocated |in-use | type size | free list name
|||--
671088640 | 37748736 |2097152 |
memory/ioBufAllocator[14]
2248146944 | 2135949312 |1048576 |
memory/ioBufAllocator[13]
1711276032 | 1705508864 | 524288 |
memory/ioBufAllocator[12]
1669332992 | 1667760128 | 262144 |
memory/ioBufAllocator[11]
2214592512 | 221184 | 131072 |
memory/ioBufAllocator[10]
2325741568 | 2323775488 | 65536 |
memory/ioBufAllocator[9]
2091909120 | 2089123840 | 32768 |
memory/ioBufAllocator[8]
1956642816 | 1956478976 | 16384 |
memory/ioBufAllocator[7]
2094530560 | 2094071808 | 8192 |
memory/ioBufAllocator[6]
356515840 | 355540992 | 4096 |
memory/ioBufAllocator[5]
1048576 | 14336 | 2048 |
memory/ioBufAllocator[4]
131072 | 0 | 1024 |
memory/ioBufAllocator[3]
65536 | 0 |512 |
memory/ioBufAllocator[2]
32768 | 0 |256 |
memory/ioBufAllocator[1]
16384 | 0 |128 |
memory/ioBufAllocator[0]
0 | 0 |576 |
memory/ICPRequestCont_allocator
0 | 0 |112 |
memory/ICPPeerReadContAllocator
0 | 0 |432 |
memory/PeerReadDataAllocator
0 | 0 | 32 |
memory/MIMEFieldSDKHandle
0 | 0 |240 |
memory/INKVConnAllocator
0 | 0 | 96 |
memory/INKContAllocator
4096 | 0 | 32 |
memory/apiHookAllocator
0 | 0 |288 |
memory/FetchSMAllocator
0 | 0 | 80 |
memory/prefetchLockHandlerAllocator
0 | 0 |176 |
memory/PrefetchBlasterAllocator
0 | 0 | 80 |
memory/prefetchUrlBlaster
0 | 0 | 96 | memory/blasterUrlList
0 | 0 | 96 |
memory/prefetchUrlEntryAllocator
0 | 0 |128 |
memory/socksProxyAllocator
0 | 0 |144 |
memory/ObjectReloadCont
3258368 | 576016 |592 |
memory/httpClientSessionAllocator
825344 | 139568 |208 |
memory/httpServerSessionAllocator
22597632 |1284848 | 9808 | memory/httpSMAllocator
0 | 0 | 32 |
memory/CacheLookupHttpConfigAllocator
0 | 0 | 9856 |
memory/httpUpdateSMAllocator
0 | 0 |128 |
memory/RemapPluginsAlloc
0 | 0 |
[jira] [Created] (TS-1783) Eliminate the wpad.dat configuration option (it's unused)
Leif Hedstrom created TS-1783: - Summary: Eliminate the wpad.dat configuration option (it's unused) Key: TS-1783 URL: https://issues.apache.org/jira/browse/TS-1783 Project: Traffic Server Issue Type: Improvement Components: Configuration Reporter: Leif Hedstrom -- 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-1783) Eliminate the wpad.dat configuration option (it's unused)
[ https://issues.apache.org/jira/browse/TS-1783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-1783: - Assignee: Leif Hedstrom Eliminate the wpad.dat configuration option (it's unused) - Key: TS-1783 URL: https://issues.apache.org/jira/browse/TS-1783 Project: Traffic Server Issue Type: Improvement Components: Configuration Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 3.3.2 -- 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-1770) Unable to create remap rule for SSL sites when accessed as a forward proxy
[
https://issues.apache.org/jira/browse/TS-1770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13615653#comment-13615653
]
Leif Hedstrom commented on TS-1770:
---
Mark, let us know (and submit a new patch if appropriate), and I'll commit it :)
Unable to create remap rule for SSL sites when accessed as a forward proxy
--
Key: TS-1770
URL: https://issues.apache.org/jira/browse/TS-1770
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Affects Versions: 3.3.1, 3.2.4
Reporter: Mark Harrison
Assignee: Leif Hedstrom
Priority: Minor
Fix For: 3.3.2
When connecting to https sites using ATS as a forward proxy, the CONNECT
method is used, and the URL doesn't have a scheme (http/https) present. When
using remap.config to limit which sites ATS will proxy for (remap_required
set to 1), there is no rule that can be made to match an a request without a
scheme present, and so no way to allow requests to a https site.
Example:
{code}
# curl -x 127.0.0.1:8080 -o /dev/null -v -s https://example.com/
* About to connect() to proxy 127.0.0.1 port 8080 (#0)
* Trying 127.0.0.1... connected
* Connected to 127.0.0.1 (127.0.0.1) port 8080 (#0)
* Establish HTTP proxy tunnel to example.com:443
CONNECT example.com:443 HTTP/1.1
Host: example.com:443
User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7
NSS/3.13.1.0 zlib/1.2.3 libidn/1.18 libssh2/1.2.2
Proxy-Connection: Keep-Alive
HTTP/1.1 404 Not Found
Date: Fri, 22 Mar 2013 21:41:25 GMT
Connection: close
Server: ATS/3.3.1-dev
Cache-Control: no-store
Content-Type: text/html; charset=utf-8
Content-Language: en
Content-Length: 309
* Received HTTP code 404 from proxy after CONNECT
* Closing connection #0
{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-1782) CENTOS 5.8 x64 autoreconf fail
[
https://issues.apache.org/jira/browse/TS-1782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1782:
--
Fix Version/s: 3.3.2
Assignee: James Peach
CENTOS 5.8 x64 autoreconf fail
---
Key: TS-1782
URL: https://issues.apache.org/jira/browse/TS-1782
Project: Traffic Server
Issue Type: Bug
Components: Build
Reporter: helaku
Assignee: James Peach
Fix For: 3.3.2
[root@nbs35 trafficserver]# autoconf -i
configure.ac:43: error: possibly undefined macro: AM_INIT_AUTOMAKE
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
configure.ac:50: error: possibly undefined macro: AC_DISABLE_STATIC
configure.ac:75: error: possibly undefined macro: dnl
configure.ac:154: error: possibly undefined macro: AC_MSG_RESULT
configure.ac:198: error: possibly undefined macro: AM_CONDITIONAL
configure.ac:516: error: possibly undefined macro: AC_MSG_NOTICE
configure.ac:548: error: possibly undefined macro: AM_PROG_AS
configure.ac:552: error: possibly undefined macro: AC_PROG_LIBTOOL
[root@nbs35 trafficserver]# cat /etc/redhat-release
CentOS release 5.8 (Final)
2.6.18-308.11.1.el5 #1 SMP Tue Jul 10 08:48:43 EDT 2012 x86_64 x86_64 x86_64
GNU/Linux
[root@nbs35 trafficserver]# git show
commit 4e53792f2740de507b6fd51f0d34f6bf4f780852
Author: Igor Gali[7m87 i.ga...@brainsware.org
Date: Wed Mar 27 00:47:21 2013 +0100
TS-1781: Make clang happy and esi compile
diff --git a/plugins/experimental/esi/lib/EsiProcessor.cc
b/plugins/experimental/esi/lib/EsiProcessor.cc
index ed4868b..96a647e 100644
--- a/plugins/experimental/esi/lib/EsiProcessor.cc
+++ b/plugins/experimental/esi/lib/EsiProcessor.cc
@@ -422,7 +422,7 @@ EsiProcessor::flush(string data, int overall_len) {
const Attribute url = (*node_iter).attr_list.front();
string raw_url(url.value, url.value_len);
attemptUrls.push_back(_expression.expand(raw_url));
-if (!_getIncludeStatus(*node_iter) == STATUS_ERROR) {
+if (_getIncludeStatus(*node_iter) != STATUS_DATA_AVAILABLE) {
attempt_succeeded = false;
_errorLog([%s] attempt section errored; due to url [%s],
__FUNCTION__, raw_url.c_str());
break;
--
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-1782) CENTOS 5.8 x64 autoreconf fail
[
https://issues.apache.org/jira/browse/TS-1782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1782:
--
Description:
{code}
[root@nbs35 trafficserver]# autoconf -i
configure.ac:43: error: possibly undefined macro: AM_INIT_AUTOMAKE
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
configure.ac:50: error: possibly undefined macro: AC_DISABLE_STATIC
configure.ac:75: error: possibly undefined macro: dnl
configure.ac:154: error: possibly undefined macro: AC_MSG_RESULT
configure.ac:198: error: possibly undefined macro: AM_CONDITIONAL
configure.ac:516: error: possibly undefined macro: AC_MSG_NOTICE
configure.ac:548: error: possibly undefined macro: AM_PROG_AS
configure.ac:552: error: possibly undefined macro: AC_PROG_LIBTOOL
[root@nbs35 trafficserver]# cat /etc/redhat-release
CentOS release 5.8 (Final)
2.6.18-308.11.1.el5 #1 SMP Tue Jul 10 08:48:43 EDT 2012 x86_64 x86_64 x86_64
GNU/Linux
[root@nbs35 trafficserver]# git show
commit 4e53792f2740de507b6fd51f0d34f6bf4f780852
Author: Igor Gali[7m87 i.ga...@brainsware.org
Date: Wed Mar 27 00:47:21 2013 +0100
TS-1781: Make clang happy and esi compile
diff --git a/plugins/experimental/esi/lib/EsiProcessor.cc
b/plugins/experimental/esi/lib/EsiProcessor.cc
index ed4868b..96a647e 100644
--- a/plugins/experimental/esi/lib/EsiProcessor.cc
+++ b/plugins/experimental/esi/lib/EsiProcessor.cc
@@ -422,7 +422,7 @@ EsiProcessor::flush(string data, int overall_len) {
const Attribute url = (*node_iter).attr_list.front();
string raw_url(url.value, url.value_len);
attemptUrls.push_back(_expression.expand(raw_url));
-if (!_getIncludeStatus(*node_iter) == STATUS_ERROR) {
+if (_getIncludeStatus(*node_iter) != STATUS_DATA_AVAILABLE) {
attempt_succeeded = false;
_errorLog([%s] attempt section errored; due to url [%s],
__FUNCTION__, raw_url.c_str());
break;
{code}
was:
[root@nbs35 trafficserver]# autoconf -i
configure.ac:43: error: possibly undefined macro: AM_INIT_AUTOMAKE
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
configure.ac:50: error: possibly undefined macro: AC_DISABLE_STATIC
configure.ac:75: error: possibly undefined macro: dnl
configure.ac:154: error: possibly undefined macro: AC_MSG_RESULT
configure.ac:198: error: possibly undefined macro: AM_CONDITIONAL
configure.ac:516: error: possibly undefined macro: AC_MSG_NOTICE
configure.ac:548: error: possibly undefined macro: AM_PROG_AS
configure.ac:552: error: possibly undefined macro: AC_PROG_LIBTOOL
[root@nbs35 trafficserver]# cat /etc/redhat-release
CentOS release 5.8 (Final)
2.6.18-308.11.1.el5 #1 SMP Tue Jul 10 08:48:43 EDT 2012 x86_64 x86_64 x86_64
GNU/Linux
[root@nbs35 trafficserver]# git show
commit 4e53792f2740de507b6fd51f0d34f6bf4f780852
Author: Igor Gali[7m87 i.ga...@brainsware.org
Date: Wed Mar 27 00:47:21 2013 +0100
TS-1781: Make clang happy and esi compile
diff --git a/plugins/experimental/esi/lib/EsiProcessor.cc
b/plugins/experimental/esi/lib/EsiProcessor.cc
index ed4868b..96a647e 100644
--- a/plugins/experimental/esi/lib/EsiProcessor.cc
+++ b/plugins/experimental/esi/lib/EsiProcessor.cc
@@ -422,7 +422,7 @@ EsiProcessor::flush(string data, int overall_len) {
const Attribute url = (*node_iter).attr_list.front();
string raw_url(url.value, url.value_len);
attemptUrls.push_back(_expression.expand(raw_url));
-if (!_getIncludeStatus(*node_iter) == STATUS_ERROR) {
+if (_getIncludeStatus(*node_iter) != STATUS_DATA_AVAILABLE) {
attempt_succeeded = false;
_errorLog([%s] attempt section errored; due to url [%s],
__FUNCTION__, raw_url.c_str());
break;
CENTOS 5.8 x64 autoreconf fail
---
Key: TS-1782
URL: https://issues.apache.org/jira/browse/TS-1782
Project: Traffic Server
Issue Type: Bug
Components: Build
Reporter: helaku
Assignee: James Peach
Fix For: 3.3.2
{code}
[root@nbs35 trafficserver]# autoconf -i
configure.ac:43: error: possibly undefined macro: AM_INIT_AUTOMAKE
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
configure.ac:50: error: possibly undefined macro: AC_DISABLE_STATIC
configure.ac:75: error: possibly undefined macro: dnl
configure.ac:154: error: possibly undefined macro: AC_MSG_RESULT
configure.ac:198: error: possibly undefined macro: AM_CONDITIONAL
configure.ac:516: error: possibly undefined macro: AC_MSG_NOTICE
configure.ac:548: error: possibly undefined macro: AM_PROG_AS
configure.ac:552: error: possibly undefined macro: AC_PROG_LIBTOOL
[root@nbs35
[jira] [Commented] (TS-382) socket option cleanup (and bug fixes)
[ https://issues.apache.org/jira/browse/TS-382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13615687#comment-13615687 ] Leif Hedstrom commented on TS-382: -- I prefer #1 (lets stop putting bitmask nonsense which none one can understand :). socket option cleanup (and bug fixes) --- Key: TS-382 URL: https://issues.apache.org/jira/browse/TS-382 Project: Traffic Server Issue Type: Bug Components: Network Reporter: Leif Hedstrom Fix For: 3.5.0 This is a bug moved from Y! Bugzilla, I'm posting the original bug description and a few comments separately. Note that the bug description is fairly limited, but while looking at this code, I noticed a lot of oddities with the socket option support (lots of hardcoded stuff, and most of it is not configurable). Note that the original bug should have been fixed already in Apache TS, but the other comments are still applicable. From Bugzilla (posted by Leif): We have two socket option config options in records.config: proxy.config.net.sock_option_flag_in proxy.config.net.sock_option_flag_out With accept thread enabled, at least the _in option isn't honored. There are possibly other cases in UnixNetAccept.cc that we don't honor these flags either. -- 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-382) socket option cleanup (and bug fixes)
[ https://issues.apache.org/jira/browse/TS-382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13615690#comment-13615690 ] Leif Hedstrom commented on TS-382: -- I do think it's useful to support these (and as many as possible) of these TCP options. socket option cleanup (and bug fixes) --- Key: TS-382 URL: https://issues.apache.org/jira/browse/TS-382 Project: Traffic Server Issue Type: Bug Components: Network Reporter: Leif Hedstrom Fix For: 3.5.0 This is a bug moved from Y! Bugzilla, I'm posting the original bug description and a few comments separately. Note that the bug description is fairly limited, but while looking at this code, I noticed a lot of oddities with the socket option support (lots of hardcoded stuff, and most of it is not configurable). Note that the original bug should have been fixed already in Apache TS, but the other comments are still applicable. From Bugzilla (posted by Leif): We have two socket option config options in records.config: proxy.config.net.sock_option_flag_in proxy.config.net.sock_option_flag_out With accept thread enabled, at least the _in option isn't honored. There are possibly other cases in UnixNetAccept.cc that we don't honor these flags either. -- 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-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:comment-tabpanelfocusedCommentId=13615691#comment-13615691
]
Leif Hedstrom commented on TS-1366:
---
I'd say just commit it :)
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: Documentation
Reporter: Igor Galić
Assignee: Alan M. Carroll
Fix For: Doc 3.4
Attachments: ts-1366.diff
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] [Updated] (TS-1586) spdy plugin doesn't build under clang (from trunk)
[
https://issues.apache.org/jira/browse/TS-1586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Galić updated TS-1586:
---
Environment:
Linux with llvm/clang from trunk + libstc++
(I don't have libc++ on Linux)
was:llvm/clang from trunk (on Linux, haven't tested on other platforms yet)
spdy plugin doesn't build under clang (from 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: Linux with llvm/clang from trunk + libstc++
(I don't have libc++ on Linux)
Reporter: Igor Galić
Assignee: Igor Galić
Fix For: 3.3.2
Attachments: restrict.patch, swap_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)
extractuint8_t(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-1586) spdy plugin doesn't build under clang (from trunk)
[
https://issues.apache.org/jira/browse/TS-1586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13615747#comment-13615747
]
Igor Galić commented on TS-1586:
updated description and environment to reflect this:
Can't use libc++ yet - not without pain: http://libcxx.llvm.org/
spdy plugin doesn't build under clang (from 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: Linux with llvm/clang from trunk + libstc++
(I don't have libc++ on Linux)
Reporter: Igor Galić
Assignee: Igor Galić
Fix For: 3.3.2
Attachments: restrict.patch, swap_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)
extractuint8_t(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 *
[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-tabpanelfocusedCommentId=13616061#comment-13616061
]
Leif Hedstrom commented on TS-1540:
---
Yongming: Any updates on this? Are you running with tracers on ?
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-1290) the init script patch in RPM
[ https://issues.apache.org/jira/browse/TS-1290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13616064#comment-13616064 ] Leif Hedstrom commented on TS-1290: --- So, hmmm, what is this patch about? Is it about including the .spec file in the source ? Something to the init script?? ming_zym? 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] [Commented] (TS-1782) CENTOS 5.8 x64 autoreconf fail
[
https://issues.apache.org/jira/browse/TS-1782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13616067#comment-13616067
]
Leif Hedstrom commented on TS-1782:
---
Have you installed all the prerequisites ?
{code}
sudo yum install make automake libtool pkgconfig gcc-c++ openssl-devel
tcl-devel expat-devel pcre-devel
sudo yum install libcap libcap-devel
{code}
Please update, so we can take action on this bug.
CENTOS 5.8 x64 autoreconf fail
---
Key: TS-1782
URL: https://issues.apache.org/jira/browse/TS-1782
Project: Traffic Server
Issue Type: Bug
Components: Build
Reporter: helaku
Assignee: James Peach
Fix For: 3.3.2
{code}
[root@nbs35 trafficserver]# autoconf -i
configure.ac:43: error: possibly undefined macro: AM_INIT_AUTOMAKE
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
configure.ac:50: error: possibly undefined macro: AC_DISABLE_STATIC
configure.ac:75: error: possibly undefined macro: dnl
configure.ac:154: error: possibly undefined macro: AC_MSG_RESULT
configure.ac:198: error: possibly undefined macro: AM_CONDITIONAL
configure.ac:516: error: possibly undefined macro: AC_MSG_NOTICE
configure.ac:548: error: possibly undefined macro: AM_PROG_AS
configure.ac:552: error: possibly undefined macro: AC_PROG_LIBTOOL
[root@nbs35 trafficserver]# cat /etc/redhat-release
CentOS release 5.8 (Final)
2.6.18-308.11.1.el5 #1 SMP Tue Jul 10 08:48:43 EDT 2012 x86_64 x86_64 x86_64
GNU/Linux
[root@nbs35 trafficserver]# git show
commit 4e53792f2740de507b6fd51f0d34f6bf4f780852
Author: Igor Gali[7m87 i.ga...@brainsware.org
Date: Wed Mar 27 00:47:21 2013 +0100
TS-1781: Make clang happy and esi compile
diff --git a/plugins/experimental/esi/lib/EsiProcessor.cc
b/plugins/experimental/esi/lib/EsiProcessor.cc
index ed4868b..96a647e 100644
--- a/plugins/experimental/esi/lib/EsiProcessor.cc
+++ b/plugins/experimental/esi/lib/EsiProcessor.cc
@@ -422,7 +422,7 @@ EsiProcessor::flush(string data, int overall_len) {
const Attribute url = (*node_iter).attr_list.front();
string raw_url(url.value, url.value_len);
attemptUrls.push_back(_expression.expand(raw_url));
-if (!_getIncludeStatus(*node_iter) == STATUS_ERROR) {
+if (_getIncludeStatus(*node_iter) != STATUS_DATA_AVAILABLE) {
attempt_succeeded = false;
_errorLog([%s] attempt section errored; due to url [%s],
__FUNCTION__, raw_url.c_str());
break;
{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-1782) CENTOS 5.8 x64 autoreconf fail
[
https://issues.apache.org/jira/browse/TS-1782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13616079#comment-13616079
]
helaku commented on TS-1782:
{code}
[root@nbs35 ~]# for i in make automake libtool pkgconfig gcc-c++ openssl-devel
tcl-devel expat-devel pcre-devel libcap libcap-devel; do rpm -q $i; done
make-3.81-3.el5
automake-1.9.6-2.3.el5
libtool-1.5.22-7.el5_4
pkgconfig-0.21-2.el5
gcc-c++-4.1.2-52.el5_8.1
openssl-devel-0.9.8e-22.el5_8.4
openssl-devel-0.9.8e-22.el5_8.4
tcl-devel-8.4.13-4.el5
tcl-devel-8.4.13-4.el5
expat-devel-1.95.8-11.el5_8
expat-devel-1.95.8-11.el5_8
pcre-devel-6.6-6.el5_6.1
pcre-devel-6.6-6.el5_6.1
libcap-1.10-26
libcap-1.10-26
libcap-devel-1.10-26
libcap-devel-1.10-26
{code}
CENTOS 5.8 x64 autoreconf fail
---
Key: TS-1782
URL: https://issues.apache.org/jira/browse/TS-1782
Project: Traffic Server
Issue Type: Bug
Components: Build
Reporter: helaku
Assignee: James Peach
Fix For: 3.3.2
{code}
[root@nbs35 trafficserver]# autoconf -i
configure.ac:43: error: possibly undefined macro: AM_INIT_AUTOMAKE
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
configure.ac:50: error: possibly undefined macro: AC_DISABLE_STATIC
configure.ac:75: error: possibly undefined macro: dnl
configure.ac:154: error: possibly undefined macro: AC_MSG_RESULT
configure.ac:198: error: possibly undefined macro: AM_CONDITIONAL
configure.ac:516: error: possibly undefined macro: AC_MSG_NOTICE
configure.ac:548: error: possibly undefined macro: AM_PROG_AS
configure.ac:552: error: possibly undefined macro: AC_PROG_LIBTOOL
[root@nbs35 trafficserver]# cat /etc/redhat-release
CentOS release 5.8 (Final)
2.6.18-308.11.1.el5 #1 SMP Tue Jul 10 08:48:43 EDT 2012 x86_64 x86_64 x86_64
GNU/Linux
[root@nbs35 trafficserver]# git show
commit 4e53792f2740de507b6fd51f0d34f6bf4f780852
Author: Igor Gali[7m87 i.ga...@brainsware.org
Date: Wed Mar 27 00:47:21 2013 +0100
TS-1781: Make clang happy and esi compile
diff --git a/plugins/experimental/esi/lib/EsiProcessor.cc
b/plugins/experimental/esi/lib/EsiProcessor.cc
index ed4868b..96a647e 100644
--- a/plugins/experimental/esi/lib/EsiProcessor.cc
+++ b/plugins/experimental/esi/lib/EsiProcessor.cc
@@ -422,7 +422,7 @@ EsiProcessor::flush(string data, int overall_len) {
const Attribute url = (*node_iter).attr_list.front();
string raw_url(url.value, url.value_len);
attemptUrls.push_back(_expression.expand(raw_url));
-if (!_getIncludeStatus(*node_iter) == STATUS_ERROR) {
+if (_getIncludeStatus(*node_iter) != STATUS_DATA_AVAILABLE) {
attempt_succeeded = false;
_errorLog([%s] attempt section errored; due to url [%s],
__FUNCTION__, raw_url.c_str());
break;
{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
