[jira] [Updated] (TS-1757) core at LogUtils::escapify_url()
[
https://issues.apache.org/jira/browse/TS-1757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yunkai Zhang updated TS-1757:
-
Description:
{code}
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0[0x39ab20f4a0]
/usr/bin/traffic_server(LogUtils::e虽scapify_url(Arena*, char*, unsigned long,
int*, char*, unsigned long, unsigned char const*)+0x60)[0x5b8550]
/usr/bin/traffic_server(LogAccessHttp::init()+0xbc)[0x59864c]
/usr/bin/traffic_server(Log::access(LogAccess*)+0x11e)[0x59b3ce]
/usr/bin/traffic_server(HttpSM::update_stats()+0x630)[0x52be20]
/usr/bin/traffic_server(HttpSM::kill_this()+0x928)[0x5374d8]
/usr/bin/traffic_server(HttpSM::main_handler(int, void*)+0x198)[0x5377f8]虽
/usr/bin/traffic_server[0x68727b]
/usr/bin/traffic_server(UnixNetVConnection::mainEvent(int,
Event*)+0x5df)[0x68989f]
/usr/bin/traffic_server(InactivityCop::check_inactivity(int,
Event*)+0xa6)[0x6839b6]
/usr/bin/traffic_server(EThread::process_event(Event*, int)+0xb4)[0x6ac714]
/usr/bin/traffic_server(PriorityEventQueue::check_ready(long,
EThread*)+0x17b)[0x6aebab]
/usr/bin/traffic_server(EThread::execute()+0x12c)[0x6acd0c]虽
/usr/bin/traffic_server[0x6ab2b2]
/lib64/libpthread.so.0[0x39ab2077f1]
/lib64/libc.so.6(clone+0x6d)[0x39aaee570d]
{code}
was:
{code}
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0[0x39ab20f4a0]
/usr/bin/traffic_server(LogUtils::escapify_url(Arena*, char*, unsigned long,
int*, char*, unsigned long, unsigned char const*)+0x60)[0x5b8550]
/usr/bin/traffic_server(LogAccessHttp::init()+0xbc)[0x59864c]
/usr/bin/traffic_server(Log::access(LogAccess*)+0x11e)[0x59b3ce]
/usr/bin/traffic_server(HttpSM::update_stats()+0x630)[0x52be20]
/usr/bin/traffic_server(HttpSM::kill_this()+0x928)[0x5374d8]
/usr/bin/traffic_server(HttpSM::main_handler(int, void*)+0x198)[0x5377f8]
/usr/bin/traffic_server[0x68727b]
/usr/bin/traffic_server(UnixNetVConnection::mainEvent(int,
Event*)+0x5df)[0x68989f]
/usr/bin/traffic_server(InactivityCop::check_inactivity(int,
Event*)+0xa6)[0x6839b6]
/usr/bin/traffic_server(EThread::process_event(Event*, int)+0xb4)[0x6ac714]
/usr/bin/traffic_server(PriorityEventQueue::check_ready(long,
EThread*)+0x17b)[0x6aebab]
/usr/bin/traffic_server(EThread::execute()+0x12c)[0x6acd0c]
/usr/bin/traffic_server[0x6ab2b2]
/lib64/libpthread.so.0[0x39ab2077f1]
/lib64/libc.so.6(clone+0x6d)[0x39aaee570d]
{code}
core at LogUtils::escapify_url()
Key: TS-1757
URL: https://issues.apache.org/jira/browse/TS-1757
Project: Traffic Server
Issue Type: Bug
Components: Logging
Reporter: Bin Chen
Assignee: taorui
Labels: crash
Fix For: 3.3.4
{code}
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0[0x39ab20f4a0]
/usr/bin/traffic_server(LogUtils::e虽scapify_url(Arena*, char*, unsigned long,
int*, char*, unsigned long, unsigned char const*)+0x60)[0x5b8550]
/usr/bin/traffic_server(LogAccessHttp::init()+0xbc)[0x59864c]
/usr/bin/traffic_server(Log::access(LogAccess*)+0x11e)[0x59b3ce]
/usr/bin/traffic_server(HttpSM::update_stats()+0x630)[0x52be20]
/usr/bin/traffic_server(HttpSM::kill_this()+0x928)[0x5374d8]
/usr/bin/traffic_server(HttpSM::main_handler(int, void*)+0x198)[0x5377f8]虽
/usr/bin/traffic_server[0x68727b]
/usr/bin/traffic_server(UnixNetVConnection::mainEvent(int,
Event*)+0x5df)[0x68989f]
/usr/bin/traffic_server(InactivityCop::check_inactivity(int,
Event*)+0xa6)[0x6839b6]
/usr/bin/traffic_server(EThread::process_event(Event*, int)+0xb4)[0x6ac714]
/usr/bin/traffic_server(PriorityEventQueue::check_ready(long,
EThread*)+0x17b)[0x6aebab]
/usr/bin/traffic_server(EThread::execute()+0x12c)[0x6acd0c]虽
/usr/bin/traffic_server[0x6ab2b2]
/lib64/libpthread.so.0[0x39ab2077f1]
/lib64/libc.so.6(clone+0x6d)[0x39aaee570d]
{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-1757) core at LogUtils::escapify_url()
[
https://issues.apache.org/jira/browse/TS-1757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bin Chen reassigned TS-1757:
Assignee: Yunkai Zhang (was: taorui)
core at LogUtils::escapify_url()
Key: TS-1757
URL: https://issues.apache.org/jira/browse/TS-1757
Project: Traffic Server
Issue Type: Bug
Components: Logging
Reporter: Bin Chen
Assignee: Yunkai Zhang
Labels: crash
Fix For: 3.3.4
{code}
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0[0x39ab20f4a0]
/usr/bin/traffic_server(LogUtils::e虽scapify_url(Arena*, char*, unsigned long,
int*, char*, unsigned long, unsigned char const*)+0x60)[0x5b8550]
/usr/bin/traffic_server(LogAccessHttp::init()+0xbc)[0x59864c]
/usr/bin/traffic_server(Log::access(LogAccess*)+0x11e)[0x59b3ce]
/usr/bin/traffic_server(HttpSM::update_stats()+0x630)[0x52be20]
/usr/bin/traffic_server(HttpSM::kill_this()+0x928)[0x5374d8]
/usr/bin/traffic_server(HttpSM::main_handler(int, void*)+0x198)[0x5377f8]虽
/usr/bin/traffic_server[0x68727b]
/usr/bin/traffic_server(UnixNetVConnection::mainEvent(int,
Event*)+0x5df)[0x68989f]
/usr/bin/traffic_server(InactivityCop::check_inactivity(int,
Event*)+0xa6)[0x6839b6]
/usr/bin/traffic_server(EThread::process_event(Event*, int)+0xb4)[0x6ac714]
/usr/bin/traffic_server(PriorityEventQueue::check_ready(long,
EThread*)+0x17b)[0x6aebab]
/usr/bin/traffic_server(EThread::execute()+0x12c)[0x6acd0c]虽
/usr/bin/traffic_server[0x6ab2b2]
/lib64/libpthread.so.0[0x39ab2077f1]
/lib64/libc.so.6(clone+0x6d)[0x39aaee570d]
{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-1510) Large files being purged from cache incorrectly
[ https://issues.apache.org/jira/browse/TS-1510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-1510: - Assignee: James Peach Large files being purged from cache incorrectly --- Key: TS-1510 URL: https://issues.apache.org/jira/browse/TS-1510 Project: Traffic Server Issue Type: Bug Components: Cache Affects Versions: 3.3.0 Environment: Ubuntu 10.04 and 12.04 Reporter: Kingsley Foreman Assignee: James Peach Labels: A Fix For: 3.3.4 With an empty cache of 120gb. I've added two files. 1. 2mb file 2. 3gb file. after 30min 2mb file remains in cache rechecks home (304) serves from cache 3gb file not i cache, and does a 200 request from the origin server like it has been cleared from cache. There is plenty of space so it isn't expiring, so really it should do a 304 not a 200 to the origin server. -- 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-1496) Traffic Server with null-transform buffering large responses when client connection slow
[
https://issues.apache.org/jira/browse/TS-1496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach updated TS-1496:
Fix Version/s: (was: 3.3.3)
3.3.4
Sounds like there is more work here. Moving out to 3.3.4.
Traffic Server with null-transform buffering large responses when client
connection slow
Key: TS-1496
URL: https://issues.apache.org/jira/browse/TS-1496
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Affects Versions: 3.2.0
Environment: Red Hat 6.3
Reporter: snf
Assignee: Alan M. Carroll
Fix For: 3.3.4
Attachments: ts-1496.diff, TS-1496.patch, TS-1496.patch
Scenario: Traffic Server started with the null-transform plugin. The link
between the client and Traffic Server is slower than the link between the
Traffic Server and the Origin Server.
Affect: If the client requests a large file from the Origin Server, the
whole file can be transmitted to, and buffered by, Traffic Server before
content is released to the client. This is a bigger issue if a large number
of clients request large files then the Traffic Server could end up buffering
very large amounts of content.
Expected behaviour: The Traffic Server should not download all the content
from the Origin Server. Instead, if the client is slow receiving from
Traffic Server, then Traffic Server should be slow receiving from the Origin
Server. Traffic Server should facilitate end to end flow control between
client and Origin Server.
Tools to replicate problem: Use Traffic Control to set a lower bandwidth on
the client machine.
Possible related area in the Traffic Server code: The following comment
appears in proxy/http/Httptunnel.cc
48 static void
49 chunked_reenable(HttpTunnelProducer * p, HttpTunnel * tunnel)
50 {
51
52 // FIX ME: still need to deal with huge chunk sizes. If a chunk
53 // is 1GB, we will currently buffer the whole thing
--
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-1510) Large files being purged from cache incorrectly
[ https://issues.apache.org/jira/browse/TS-1510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13673267#comment-13673267 ] Leif Hedstrom commented on TS-1510: --- Moving out to v3.3.4 for now, James and I will look into this asap. Large files being purged from cache incorrectly --- Key: TS-1510 URL: https://issues.apache.org/jira/browse/TS-1510 Project: Traffic Server Issue Type: Bug Components: Cache Affects Versions: 3.3.0 Environment: Ubuntu 10.04 and 12.04 Reporter: Kingsley Foreman Labels: A Fix For: 3.3.4 With an empty cache of 120gb. I've added two files. 1. 2mb file 2. 3gb file. after 30min 2mb file remains in cache rechecks home (304) serves from cache 3gb file not i cache, and does a 200 request from the origin server like it has been cleared from cache. There is plenty of space so it isn't expiring, so really it should do a 304 not a 200 to the origin server. -- 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-1820) Cleanup UNUSED / INK_UNUSED / RELEASE_UNUSED
[ https://issues.apache.org/jira/browse/TS-1820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1820: -- Fix Version/s: (was: 3.3.3) 3.3.4 Cleanup UNUSED / INK_UNUSED / RELEASE_UNUSED Key: TS-1820 URL: https://issues.apache.org/jira/browse/TS-1820 Project: Traffic Server Issue Type: Improvement Components: Core Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 3.3.4 We have to many of these defines, and should clean this up and unify it. There are also plugins and core code defining their own versions of this, lets eliminate that as well. -- 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 ] James Peach updated TS-1344: Fix Version/s: (was: 3.3.3) 3.3.4 Moving out to 3.3.4 since there's not enough information to make this actionable. [~briang] if you have a patch, please bring it back to 3.3.3. 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 Labels: A Fix For: 3.3.4 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] [Commented] (TS-1934) Enable geoip_acl plugin for build with experimental enabled
[ https://issues.apache.org/jira/browse/TS-1934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13673301#comment-13673301 ] ASF subversion and git services commented on TS-1934: - Commit 0da9a090f258ec490f7a3cee0d0a1b041249e134 in branch refs/heads/master from [~zwoop] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=0da9a09 ] TS-1934 Update the README since the old build instructions do not work. Enable geoip_acl plugin for build with experimental enabled --- Key: TS-1934 URL: https://issues.apache.org/jira/browse/TS-1934 Project: Traffic Server Issue Type: Bug Components: Plugins Reporter: Leif Hedstrom Fix For: 3.3.4 -- 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-1827) minor improvement of combo_handler plugin
[
https://issues.apache.org/jira/browse/TS-1827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13673305#comment-13673305
]
ASF subversion and git services commented on TS-1827:
-
Commit 3d33a7ee689fb260930756c2466d780285588455 in branch refs/heads/master
from Leif Hedstrom zw...@apache.org
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=3d33a7e ]
TS-1827 Further cleanup of combo_handler. Particularly, it is now
controlled via remap.config.
Review: Leif, I also changed the txn parameter passing to avoid
the malloc.
minor improvement of combo_handler plugin
-
Key: TS-1827
URL: https://issues.apache.org/jira/browse/TS-1827
Project: Traffic Server
Issue Type: Improvement
Components: Plugins
Reporter: Conan Wang
Assignee: Leif Hedstrom
Fix For: 3.3.3
Attachments: TS-1827.diff
Based on TS-1053, I've made some minor improvements. Community can select the
general ones to review.
Changes: (separately pasted on pastebin temporally; may provide with commits
later after TS-1053 is solved on git master):
# use HOST header as default bucket http://pastebin.com/pGHfLaHR
Original code use the first segment of Host as the default bucket and it's
not that expandable (two different combo domain may have same leading
segment). Moreover, the initial default bucket(l) will not be used, because
all requests should have a HOST.
# sub-file's path need to contain querystring, i.e. question mark(?) is
part of the file path, not the delimiter http://pastebin.com/HvMJBQw0
We use querystring to version each single sub-file in the combined url. If we
want to update/purge one of them, it can be simply accomplished by changing
the version of sub-file. (If not, you have to purge both the combined url and
sub-file url which is relatively hard to know the latter one when you are not
very familiar with ATS. Of course you can alter the filename if possible in
your site.)
Then the combo url could be like
http://example.com/combo?file1?v=2012file2?v=2013
# request hangs when combo url has no querystring http://pastebin.com/d34ZJDzQ
# make plugin per-remap enabled/disabled http://pastebin.com/YTaDYvh2
It's implemented by adding some remap code and make global part intercepted
in TS_EVENT_HTTP_OS_DNS instead of TS_EVENT_HTTP_READ_REQUEST_HDR in order to
read the flag set in TSRemapDoRemap.
So remap.config will be: {code}
maphttp://example.com http://os.example.com @plugin=combo_handler.so
maphttp://localhost/example.com http://os.example.com
maphttp://other.com http://os.other.com # combo for this channel is
disabled
{code}
# limit sub-file max count and querystring length for potential problems
http://pastebin.com/cmBCuCNB
# log failed url http://pastebin.com/bNezeaz0
They were tested on 3.0.x.
--
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-1492) if being net_connections_throttled, ts must to be restarted?(because of can't accept health checking request)
[ https://issues.apache.org/jira/browse/TS-1492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13673347#comment-13673347 ] ASF subversion and git services commented on TS-1492: - Commit c0565072e37db84d033ee00c250b397456a87828 in branch refs/heads/master from Leif Hedstrom zw...@apache.org [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=c056507 ] TS-1492 Prevent net-throttling from locking out the health checks from traffic_cop. if being net_connections_throttled, ts must to be restarted?(because of can't accept health checking request) -- Key: TS-1492 URL: https://issues.apache.org/jira/browse/TS-1492 Project: Traffic Server Issue Type: Improvement Components: Core Affects Versions: 3.2.0 Reporter: Bin Chen Assignee: Leif Hedstrom Priority: Critical Labels: A Fix For: 3.3.3 Attachments: backdoor_not_throttling.patch In our env, ts will be throttled because of many request incomming simultaneously(because of frontend haproxy is restarted). But we don't expect ts be restarted because of this case. we can handled this: 1、if throttled, ts's health check request always be handled 2、many many connection request may be handled in long time -- 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-1935) ERR_UNKNOWN/000 showing up 10.4% of the time in production logs
Bryan Call created TS-1935: -- Summary: ERR_UNKNOWN/000 showing up 10.4% of the time in production logs Key: TS-1935 URL: https://issues.apache.org/jira/browse/TS-1935 Project: Traffic Server Issue Type: Bug Reporter: Bryan Call Need to investigate in what conditions this happens. * Keep-alive or not * If any requests have happened on the connection * Is the client or the server closing the connection at the time * Verify no bytes have been sent from the client, looking at the code it looks like it Ideally if the client has not sent any bytes (has not attempted to make a request) then we shouldn't log the error message. If it is possible a state machine should not be created in this scenario. related bug: TS-1056 related checkin: 425e3d7dcb16b40075c7678e71d00b2fcb4b4705 I also see this happening in on my forward proxy using Chrome: [bcall@homer trafficserver]$ traffic_logcat -f squid.blog | grep 000 1370281253.174 0 192.168.1.30 ERR_UNKNOWN/000 0 - / - EMPTY/- - - 1370281253.450 0 192.168.1.30 ERR_UNKNOWN/000 0 - / - EMPTY/- - - 1370281253.891 0 192.168.1.30 ERR_UNKNOWN/000 0 - / - EMPTY/- - - -- 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-1857) On CentOS Lua Plugin will built when --enable-experimental whether Lua is found or not
[
https://issues.apache.org/jira/browse/TS-1857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13673579#comment-13673579
]
James Peach commented on TS-1857:
-
The problem seems to be that autoconf generates the wrong code for AS_IF.
On CentOS Lua Plugin will built when --enable-experimental whether Lua is
found or not
--
Key: TS-1857
URL: https://issues.apache.org/jira/browse/TS-1857
Project: Traffic Server
Issue Type: Bug
Components: Build, Lua, Plugins
Environment: CentOS 5 x86 (but not x64)
Reporter: Igor Galić
Assignee: James Peach
Fix For: 3.3.3
reference: http://ats.boot.org:8080/job/master_centos_5_x86/19/consoleText
{noformat}
checking for readline/history.h... yes
checking whether to enable Linux LuaJIT support... checking for pkg-config...
/usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for luajit... no
checking for pow in -lm... no
checking for sqrt in -lm... no
checking lua.h usability... no
checking lua.h presence... no
checking for lua.h... no
checking for lua.h in /usr/local/include/lua5.1... no
checking for lua.h in /usr/local/include/lua51... no
checking for lua.h in /usr/local/include... no
checking for lua.h in /usr/include/lua5.1... no
checking for lua.h in /usr/include/lua51... no
checking for lua.h in /usr/include... no
configure: WARNING: *** Lua 5.1 library not found.
checking whether to enable Lua support...
checking sys/epoll.h usability... yes
checking sys/epoll.h presence... yes
checking for sys/epoll.h... yes
{noformat}
I really wonder what the result was of whether to enable Lua support
{noformat}
Making all in experimental
make[2]: Entering directory
`/var/jenkins/workspace/master_centos_5_x86/plugins/experimental'
Making all in lua
make[3]: Entering directory
`/var/jenkins/workspace/master_centos_5_x86/plugins/experimental/lua'
if /bin/sh ../../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I.
-I. -I../../../lib/ts -D__STDC_LIMIT_MACROS=1 -D__STDC_FORMAT_MACROS=1
-I../../../proxy/api -I../../../proxy/api -I../../../lib/ts -I../../../lib/ts
-D_LARGEFILE64_SOURCE=1 -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -D_REENTRANT
-Dlinux -Wunused-parameter -march=i586 -g -pipe -Wall -Werror -O3
-feliminate-unused-debug-symbols -fno-strict-aliasing -Wno-invalid-offsetof
-MT lua_la-remap.lo -MD -MP -MF .deps/lua_la-remap.Tpo -c -o
lua_la-remap.lo `test -f 'remap.cc' || echo './'`remap.cc; \
then mv -f .deps/lua_la-remap.Tpo .deps/lua_la-remap.Plo; else rm
-f .deps/lua_la-remap.Tpo; exit 1; fi
if /bin/sh ../../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I.
-I. -I../../../lib/ts -D__STDC_LIMIT_MACROS=1 -D__STDC_FORMAT_MACROS=1
-I../../../proxy/api -I../../../proxy/api -I../../../lib/ts -I../../../lib/ts
-D_LARGEFILE64_SOURCE=1 -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -D_REENTRANT
-Dlinux -Wunused-parameter -march=i586 -g -pipe -Wall -Werror -O3
-feliminate-unused-debug-symbols -fno-strict-aliasing -Wno-invalid-offsetof
-MT lua_la-plugin.lo -MD -MP -MF .deps/lua_la-plugin.Tpo -c -o
lua_la-plugin.lo `test -f 'plugin.cc' || echo './'`plugin.cc; \
then mv -f .deps/lua_la-plugin.Tpo .deps/lua_la-plugin.Plo; else rm
-f .deps/lua_la-plugin.Tpo; exit 1; fi
mkdir .libs
g++ -DHAVE_CONFIG_H -I. -I. -I../../../lib/ts -D__STDC_LIMIT_MACROS=1
-D__STDC_FORMAT_MACROS=1 -I../../../proxy/api -I../../../proxy/api
-I../../../lib/ts -I../../../lib/ts -D_LARGEFILE64_SOURCE=1
-D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -D_REENTRANT -Dlinux -Wunused-parameter
-march=i586 -g -pipe -Wall -Werror -O3 -feliminate-unused-debug-symbols
-fno-strict-aliasing -Wno-invalid-offsetof -MT lua_la-plugin.lo -MD -MP -MF
.deps/lua_la-plugin.Tpo -c plugin.cc -fPIC -DPIC -o .libs/lua_la-plugin.o
g++ -DHAVE_CONFIG_H -I. -I. -I../../../lib/ts -D__STDC_LIMIT_MACROS=1
-D__STDC_FORMAT_MACROS=1 -I../../../proxy/api -I../../../proxy/api
-I../../../lib/ts -I../../../lib/ts -D_LARGEFILE64_SOURCE=1
-D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -D_REENTRANT -Dlinux -Wunused-parameter
-march=i586 -g -pipe -Wall -Werror -O3 -feliminate-unused-debug-symbols
-fno-strict-aliasing -Wno-invalid-offsetof -MT lua_la-remap.lo -MD -MP -MF
.deps/lua_la-remap.Tpo -c remap.cc -fPIC -DPIC -o .libs/lua_la-remap.o
In file included from plugin.cc:20:
lutil.h:22:19: error: lua.hpp: No such file or directory
In file included from remap.cc:23:
lapi.h:22:19: error: lua.hpp: No such file or directory
lapi.h:37: error: expected ';' before '(' token
lapi.h:38: error: expected ';' before '(' token
lapi.h:42: error: 'lua_State' was not declared in this scope
lapi.h:42: error: 'lua' was not declared in this scope
[jira] [Assigned] (TS-1934) Enable geoip_acl plugin for build with experimental enabled
[ https://issues.apache.org/jira/browse/TS-1934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-1934: - Assignee: Leif Hedstrom Enable geoip_acl plugin for build with experimental enabled --- Key: TS-1934 URL: https://issues.apache.org/jira/browse/TS-1934 Project: Traffic Server Issue Type: Bug Components: Plugins Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 3.3.4 -- 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-1857) On CentOS Lua Plugin will built when --enable-experimental whether Lua is found or not
[
https://issues.apache.org/jira/browse/TS-1857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13673637#comment-13673637
]
ASF subversion and git services commented on TS-1857:
-
Commit 2651663d5040f76fe49da5c9ca3ae7884796090c in branch refs/heads/master
from [~jpe...@apache.org]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=2651663 ]
TS-1857: the Lua plugin is built whether Lua is found or not
Autoconf 2.59 seems to have a bug where AS_IF constructs with
multiple conditions are not emitted correctly. It only emits the
first condition and the final else clause. Fortunately we can work
around this by using a switch statement.
On CentOS Lua Plugin will built when --enable-experimental whether Lua is
found or not
--
Key: TS-1857
URL: https://issues.apache.org/jira/browse/TS-1857
Project: Traffic Server
Issue Type: Bug
Components: Build, Lua, Plugins
Environment: CentOS 5 x86 (but not x64)
Reporter: Igor Galić
Assignee: James Peach
Fix For: 3.3.3
reference: http://ats.boot.org:8080/job/master_centos_5_x86/19/consoleText
{noformat}
checking for readline/history.h... yes
checking whether to enable Linux LuaJIT support... checking for pkg-config...
/usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for luajit... no
checking for pow in -lm... no
checking for sqrt in -lm... no
checking lua.h usability... no
checking lua.h presence... no
checking for lua.h... no
checking for lua.h in /usr/local/include/lua5.1... no
checking for lua.h in /usr/local/include/lua51... no
checking for lua.h in /usr/local/include... no
checking for lua.h in /usr/include/lua5.1... no
checking for lua.h in /usr/include/lua51... no
checking for lua.h in /usr/include... no
configure: WARNING: *** Lua 5.1 library not found.
checking whether to enable Lua support...
checking sys/epoll.h usability... yes
checking sys/epoll.h presence... yes
checking for sys/epoll.h... yes
{noformat}
I really wonder what the result was of whether to enable Lua support
{noformat}
Making all in experimental
make[2]: Entering directory
`/var/jenkins/workspace/master_centos_5_x86/plugins/experimental'
Making all in lua
make[3]: Entering directory
`/var/jenkins/workspace/master_centos_5_x86/plugins/experimental/lua'
if /bin/sh ../../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I.
-I. -I../../../lib/ts -D__STDC_LIMIT_MACROS=1 -D__STDC_FORMAT_MACROS=1
-I../../../proxy/api -I../../../proxy/api -I../../../lib/ts -I../../../lib/ts
-D_LARGEFILE64_SOURCE=1 -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -D_REENTRANT
-Dlinux -Wunused-parameter -march=i586 -g -pipe -Wall -Werror -O3
-feliminate-unused-debug-symbols -fno-strict-aliasing -Wno-invalid-offsetof
-MT lua_la-remap.lo -MD -MP -MF .deps/lua_la-remap.Tpo -c -o
lua_la-remap.lo `test -f 'remap.cc' || echo './'`remap.cc; \
then mv -f .deps/lua_la-remap.Tpo .deps/lua_la-remap.Plo; else rm
-f .deps/lua_la-remap.Tpo; exit 1; fi
if /bin/sh ../../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I.
-I. -I../../../lib/ts -D__STDC_LIMIT_MACROS=1 -D__STDC_FORMAT_MACROS=1
-I../../../proxy/api -I../../../proxy/api -I../../../lib/ts -I../../../lib/ts
-D_LARGEFILE64_SOURCE=1 -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -D_REENTRANT
-Dlinux -Wunused-parameter -march=i586 -g -pipe -Wall -Werror -O3
-feliminate-unused-debug-symbols -fno-strict-aliasing -Wno-invalid-offsetof
-MT lua_la-plugin.lo -MD -MP -MF .deps/lua_la-plugin.Tpo -c -o
lua_la-plugin.lo `test -f 'plugin.cc' || echo './'`plugin.cc; \
then mv -f .deps/lua_la-plugin.Tpo .deps/lua_la-plugin.Plo; else rm
-f .deps/lua_la-plugin.Tpo; exit 1; fi
mkdir .libs
g++ -DHAVE_CONFIG_H -I. -I. -I../../../lib/ts -D__STDC_LIMIT_MACROS=1
-D__STDC_FORMAT_MACROS=1 -I../../../proxy/api -I../../../proxy/api
-I../../../lib/ts -I../../../lib/ts -D_LARGEFILE64_SOURCE=1
-D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -D_REENTRANT -Dlinux -Wunused-parameter
-march=i586 -g -pipe -Wall -Werror -O3 -feliminate-unused-debug-symbols
-fno-strict-aliasing -Wno-invalid-offsetof -MT lua_la-plugin.lo -MD -MP -MF
.deps/lua_la-plugin.Tpo -c plugin.cc -fPIC -DPIC -o .libs/lua_la-plugin.o
g++ -DHAVE_CONFIG_H -I. -I. -I../../../lib/ts -D__STDC_LIMIT_MACROS=1
-D__STDC_FORMAT_MACROS=1 -I../../../proxy/api -I../../../proxy/api
-I../../../lib/ts -I../../../lib/ts -D_LARGEFILE64_SOURCE=1
-D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -D_REENTRANT -Dlinux -Wunused-parameter
-march=i586 -g -pipe -Wall -Werror -O3 -feliminate-unused-debug-symbols
-fno-strict-aliasing -Wno-invalid-offsetof -MT lua_la-remap.lo -MD -MP -MF
.deps/lua_la-remap.Tpo -c remap.cc
[jira] [Resolved] (TS-1857) On CentOS Lua Plugin will built when --enable-experimental whether Lua is found or not
[
https://issues.apache.org/jira/browse/TS-1857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach resolved TS-1857.
-
Resolution: Fixed
On CentOS Lua Plugin will built when --enable-experimental whether Lua is
found or not
--
Key: TS-1857
URL: https://issues.apache.org/jira/browse/TS-1857
Project: Traffic Server
Issue Type: Bug
Components: Build, Lua, Plugins
Environment: CentOS 5 x86 (but not x64)
Reporter: Igor Galić
Assignee: James Peach
Fix For: 3.3.3
reference: http://ats.boot.org:8080/job/master_centos_5_x86/19/consoleText
{noformat}
checking for readline/history.h... yes
checking whether to enable Linux LuaJIT support... checking for pkg-config...
/usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for luajit... no
checking for pow in -lm... no
checking for sqrt in -lm... no
checking lua.h usability... no
checking lua.h presence... no
checking for lua.h... no
checking for lua.h in /usr/local/include/lua5.1... no
checking for lua.h in /usr/local/include/lua51... no
checking for lua.h in /usr/local/include... no
checking for lua.h in /usr/include/lua5.1... no
checking for lua.h in /usr/include/lua51... no
checking for lua.h in /usr/include... no
configure: WARNING: *** Lua 5.1 library not found.
checking whether to enable Lua support...
checking sys/epoll.h usability... yes
checking sys/epoll.h presence... yes
checking for sys/epoll.h... yes
{noformat}
I really wonder what the result was of whether to enable Lua support
{noformat}
Making all in experimental
make[2]: Entering directory
`/var/jenkins/workspace/master_centos_5_x86/plugins/experimental'
Making all in lua
make[3]: Entering directory
`/var/jenkins/workspace/master_centos_5_x86/plugins/experimental/lua'
if /bin/sh ../../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I.
-I. -I../../../lib/ts -D__STDC_LIMIT_MACROS=1 -D__STDC_FORMAT_MACROS=1
-I../../../proxy/api -I../../../proxy/api -I../../../lib/ts -I../../../lib/ts
-D_LARGEFILE64_SOURCE=1 -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -D_REENTRANT
-Dlinux -Wunused-parameter -march=i586 -g -pipe -Wall -Werror -O3
-feliminate-unused-debug-symbols -fno-strict-aliasing -Wno-invalid-offsetof
-MT lua_la-remap.lo -MD -MP -MF .deps/lua_la-remap.Tpo -c -o
lua_la-remap.lo `test -f 'remap.cc' || echo './'`remap.cc; \
then mv -f .deps/lua_la-remap.Tpo .deps/lua_la-remap.Plo; else rm
-f .deps/lua_la-remap.Tpo; exit 1; fi
if /bin/sh ../../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I.
-I. -I../../../lib/ts -D__STDC_LIMIT_MACROS=1 -D__STDC_FORMAT_MACROS=1
-I../../../proxy/api -I../../../proxy/api -I../../../lib/ts -I../../../lib/ts
-D_LARGEFILE64_SOURCE=1 -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -D_REENTRANT
-Dlinux -Wunused-parameter -march=i586 -g -pipe -Wall -Werror -O3
-feliminate-unused-debug-symbols -fno-strict-aliasing -Wno-invalid-offsetof
-MT lua_la-plugin.lo -MD -MP -MF .deps/lua_la-plugin.Tpo -c -o
lua_la-plugin.lo `test -f 'plugin.cc' || echo './'`plugin.cc; \
then mv -f .deps/lua_la-plugin.Tpo .deps/lua_la-plugin.Plo; else rm
-f .deps/lua_la-plugin.Tpo; exit 1; fi
mkdir .libs
g++ -DHAVE_CONFIG_H -I. -I. -I../../../lib/ts -D__STDC_LIMIT_MACROS=1
-D__STDC_FORMAT_MACROS=1 -I../../../proxy/api -I../../../proxy/api
-I../../../lib/ts -I../../../lib/ts -D_LARGEFILE64_SOURCE=1
-D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -D_REENTRANT -Dlinux -Wunused-parameter
-march=i586 -g -pipe -Wall -Werror -O3 -feliminate-unused-debug-symbols
-fno-strict-aliasing -Wno-invalid-offsetof -MT lua_la-plugin.lo -MD -MP -MF
.deps/lua_la-plugin.Tpo -c plugin.cc -fPIC -DPIC -o .libs/lua_la-plugin.o
g++ -DHAVE_CONFIG_H -I. -I. -I../../../lib/ts -D__STDC_LIMIT_MACROS=1
-D__STDC_FORMAT_MACROS=1 -I../../../proxy/api -I../../../proxy/api
-I../../../lib/ts -I../../../lib/ts -D_LARGEFILE64_SOURCE=1
-D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -D_REENTRANT -Dlinux -Wunused-parameter
-march=i586 -g -pipe -Wall -Werror -O3 -feliminate-unused-debug-symbols
-fno-strict-aliasing -Wno-invalid-offsetof -MT lua_la-remap.lo -MD -MP -MF
.deps/lua_la-remap.Tpo -c remap.cc -fPIC -DPIC -o .libs/lua_la-remap.o
In file included from plugin.cc:20:
lutil.h:22:19: error: lua.hpp: No such file or directory
In file included from remap.cc:23:
lapi.h:22:19: error: lua.hpp: No such file or directory
lapi.h:37: error: expected ';' before '(' token
lapi.h:38: error: expected ';' before '(' token
lapi.h:42: error: 'lua_State' was not declared in this scope
lapi.h:42: error: 'lua' was not declared in this scope
lapi.h:44: error: 'lua_State' was not declared in this scope
lapi.h:44: error: 'lua' was not declared in this scope
