[jira] [Commented] (TS-2901) 使用esi模块时报 FATAL: FetchSM.cc:160: failed assert `header_done`
[ https://issues.apache.org/jira/browse/TS-2901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14045579#comment-14045579 ] helaku commented on TS-2901: here： https://issues.apache.org/jira/browse/TS-2889 > 使用esi模块时报 FATAL: FetchSM.cc:160: failed assert `header_done` > > > Key: TS-2901 > URL: https://issues.apache.org/jira/browse/TS-2901 > Project: Traffic Server > Issue Type: Bug > Components: Plugins >Affects Versions: 5.0.0 >Reporter: helaku > > 报错如下： > [TrafficServer] using root directory '/usr/local/trafficserver-5.0.0' > FATAL: FetchSM.cc:160: failed assert `header_done` > /usr/local/trafficserver-5.0.0/bin/traffic_server - STACK TRACE: > /usr/local/trafficserver-5.0.0/lib/libtsutil.so.5(+0x1f9b8)[0x2b7ecc7459b8] > /usr/local/trafficserver-5.0.0/lib/libtsutil.so.5(+0x1de7f)[0x2b7ecc743e7f] > /usr/local/trafficserver-5.0.0/bin/traffic_server(FetchSM::check_chunked()+0x3d2)[0x49e552] > /usr/local/trafficserver-5.0.0/bin/traffic_server(FetchSM::get_info_from_buffer(IOBufferReader*)+0xa1)[0x49e731] > /usr/local/trafficserver-5.0.0/bin/traffic_server(FetchSM::process_fetch_read(int)+0x20c)[0x4a019c] > /usr/local/trafficserver-5.0.0/bin/traffic_server(FetchSM::fetch_handler(int, > void*)+0x8b)[0x4a02cb] > /usr/local/trafficserver-5.0.0/bin/traffic_server(PluginVC::process_read_side(bool)+0x4ca)[0x4d839a] > /usr/local/trafficserver-5.0.0/bin/traffic_server(PluginVC::main_handler(int, > void*)+0x33a)[0x4da59a] > /usr/local/trafficserver-5.0.0/bin/traffic_server(EThread::process_event(Event*, > int)+0x8f)[0x72962f] > /usr/local/trafficserver-5.0.0/bin/traffic_server(EThread::execute()+0x57b)[0x729f9b] > /usr/local/trafficserver-5.0.0/bin/traffic_server[0x7289da] > /lib64/libpthread.so.0(+0x3c06a07851)[0x2b7ecc978851] > /lib64/libc.so.6(clone+0x6d)[0x3c066e811d] > 报错的同时页面无法打开，关闭esi模块后一切正常，当然同时esi功能也失效了 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2729) Add HTTP/2 support to ATS
[
https://issues.apache.org/jira/browse/TS-2729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14045537#comment-14045537
]
Masakazu Kitajo commented on TS-2729:
-
I deleted patches I attached because all changes are merged into Ryo's
http2-0004.patch.
I left the latest patch, but Ryo and I agree the way to implement HTTP/2, which
implement it without external dependencies.
We'll be happy to assist creating new implementation.
> Add HTTP/2 support to ATS
> -
>
> Key: TS-2729
> URL: https://issues.apache.org/jira/browse/TS-2729
> Project: Traffic Server
> Issue Type: New Feature
> Components: HTTP/2
>Reporter: Ryo Okubo
> Labels: review
> Fix For: 5.1.0
>
> Attachments: http2-0004.patch
>
>
> h2. Overview
> We, CDN team of Yahoo! JAPAN, have implemented HTTP/2 support in ATS core
> experimentally.
> Now, it supports HTTP/2 draft-12.
> http://tools.ietf.org/html/draft-ietf-httpbis-http2-12
> Our implementation similar to the SPDY implementation in ATS core(TS-2431)
> but we use nghttp2 library instead of spdylay to interpret HTTP/2 frames.
> https://github.com/tatsuhiro-t/nghttp2
> We tested NPN and ALPN negotiation.
> h2. How to test it
> * Install nghttp2 library, here is URL of this library:
> https://github.com/tatsuhiro-t/nghttp2
> * Use '--enable-http2' option to compile ATS:
> {noformat}
> $ ./configure --enable-http2
> $ make all && make install
> {noformat}
> * You can use '--with-openssl=' option.
> * Need not configure anything if you just want to test HTTP/2 without SSL.
> The code can recognize HTTP2, SPDY or HTTP by reading first to 3rd bytes of
> requests.
> * You can use nghttp in nghttp2 library(or other HTTP/2 client) to request,
> for example:
> {noformat}
> # HTTP/2 without SSL
> $ nghttp -v http://localhost/b.txt
> # HTTP/2 + SSL
> $ nghttp -v https://localhost/b.txt
> {noformat}
> h2. TODO
> * -Cleanup codes.-
> * Follow -http2 draft-12- and later.
> * -Support ALPN.-
> * Add settings related to HTTP/2 into records.config.
> ** it'll refer to configuration settings for SPDY on TS-2740
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2729) Add HTTP/2 support to ATS
[
https://issues.apache.org/jira/browse/TS-2729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Masakazu Kitajo updated TS-2729:
Attachment: (was: fix-handling-version-string.patch)
> Add HTTP/2 support to ATS
> -
>
> Key: TS-2729
> URL: https://issues.apache.org/jira/browse/TS-2729
> Project: Traffic Server
> Issue Type: New Feature
> Components: HTTP/2
>Reporter: Ryo Okubo
> Labels: review
> Fix For: 5.1.0
>
> Attachments: http2-0004.patch
>
>
> h2. Overview
> We, CDN team of Yahoo! JAPAN, have implemented HTTP/2 support in ATS core
> experimentally.
> Now, it supports HTTP/2 draft-12.
> http://tools.ietf.org/html/draft-ietf-httpbis-http2-12
> Our implementation similar to the SPDY implementation in ATS core(TS-2431)
> but we use nghttp2 library instead of spdylay to interpret HTTP/2 frames.
> https://github.com/tatsuhiro-t/nghttp2
> We tested NPN and ALPN negotiation.
> h2. How to test it
> * Install nghttp2 library, here is URL of this library:
> https://github.com/tatsuhiro-t/nghttp2
> * Use '--enable-http2' option to compile ATS:
> {noformat}
> $ ./configure --enable-http2
> $ make all && make install
> {noformat}
> * You can use '--with-openssl=' option.
> * Need not configure anything if you just want to test HTTP/2 without SSL.
> The code can recognize HTTP2, SPDY or HTTP by reading first to 3rd bytes of
> requests.
> * You can use nghttp in nghttp2 library(or other HTTP/2 client) to request,
> for example:
> {noformat}
> # HTTP/2 without SSL
> $ nghttp -v http://localhost/b.txt
> # HTTP/2 + SSL
> $ nghttp -v https://localhost/b.txt
> {noformat}
> h2. TODO
> * -Cleanup codes.-
> * Follow -http2 draft-12- and later.
> * -Support ALPN.-
> * Add settings related to HTTP/2 into records.config.
> ** it'll refer to configuration settings for SPDY on TS-2740
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2729) Add HTTP/2 support to ATS
[
https://issues.apache.org/jira/browse/TS-2729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Masakazu Kitajo updated TS-2729:
Attachment: (was: ts2743.patch)
> Add HTTP/2 support to ATS
> -
>
> Key: TS-2729
> URL: https://issues.apache.org/jira/browse/TS-2729
> Project: Traffic Server
> Issue Type: New Feature
> Components: HTTP/2
>Reporter: Ryo Okubo
> Labels: review
> Fix For: 5.1.0
>
> Attachments: http2-0004.patch
>
>
> h2. Overview
> We, CDN team of Yahoo! JAPAN, have implemented HTTP/2 support in ATS core
> experimentally.
> Now, it supports HTTP/2 draft-12.
> http://tools.ietf.org/html/draft-ietf-httpbis-http2-12
> Our implementation similar to the SPDY implementation in ATS core(TS-2431)
> but we use nghttp2 library instead of spdylay to interpret HTTP/2 frames.
> https://github.com/tatsuhiro-t/nghttp2
> We tested NPN and ALPN negotiation.
> h2. How to test it
> * Install nghttp2 library, here is URL of this library:
> https://github.com/tatsuhiro-t/nghttp2
> * Use '--enable-http2' option to compile ATS:
> {noformat}
> $ ./configure --enable-http2
> $ make all && make install
> {noformat}
> * You can use '--with-openssl=' option.
> * Need not configure anything if you just want to test HTTP/2 without SSL.
> The code can recognize HTTP2, SPDY or HTTP by reading first to 3rd bytes of
> requests.
> * You can use nghttp in nghttp2 library(or other HTTP/2 client) to request,
> for example:
> {noformat}
> # HTTP/2 without SSL
> $ nghttp -v http://localhost/b.txt
> # HTTP/2 + SSL
> $ nghttp -v https://localhost/b.txt
> {noformat}
> h2. TODO
> * -Cleanup codes.-
> * Follow -http2 draft-12- and later.
> * -Support ALPN.-
> * Add settings related to HTTP/2 into records.config.
> ** it'll refer to configuration settings for SPDY on TS-2740
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2729) Add HTTP/2 support to ATS
[
https://issues.apache.org/jira/browse/TS-2729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Masakazu Kitajo updated TS-2729:
Attachment: (was: draft11.patch)
> Add HTTP/2 support to ATS
> -
>
> Key: TS-2729
> URL: https://issues.apache.org/jira/browse/TS-2729
> Project: Traffic Server
> Issue Type: New Feature
> Components: HTTP/2
>Reporter: Ryo Okubo
> Labels: review
> Fix For: 5.1.0
>
> Attachments: http2-0004.patch
>
>
> h2. Overview
> We, CDN team of Yahoo! JAPAN, have implemented HTTP/2 support in ATS core
> experimentally.
> Now, it supports HTTP/2 draft-12.
> http://tools.ietf.org/html/draft-ietf-httpbis-http2-12
> Our implementation similar to the SPDY implementation in ATS core(TS-2431)
> but we use nghttp2 library instead of spdylay to interpret HTTP/2 frames.
> https://github.com/tatsuhiro-t/nghttp2
> We tested NPN and ALPN negotiation.
> h2. How to test it
> * Install nghttp2 library, here is URL of this library:
> https://github.com/tatsuhiro-t/nghttp2
> * Use '--enable-http2' option to compile ATS:
> {noformat}
> $ ./configure --enable-http2
> $ make all && make install
> {noformat}
> * You can use '--with-openssl=' option.
> * Need not configure anything if you just want to test HTTP/2 without SSL.
> The code can recognize HTTP2, SPDY or HTTP by reading first to 3rd bytes of
> requests.
> * You can use nghttp in nghttp2 library(or other HTTP/2 client) to request,
> for example:
> {noformat}
> # HTTP/2 without SSL
> $ nghttp -v http://localhost/b.txt
> # HTTP/2 + SSL
> $ nghttp -v https://localhost/b.txt
> {noformat}
> h2. TODO
> * -Cleanup codes.-
> * Follow -http2 draft-12- and later.
> * -Support ALPN.-
> * Add settings related to HTTP/2 into records.config.
> ** it'll refer to configuration settings for SPDY on TS-2740
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2729) Add HTTP/2 support to ATS
[
https://issues.apache.org/jira/browse/TS-2729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Masakazu Kitajo updated TS-2729:
Attachment: (was: http2-0002.patch)
> Add HTTP/2 support to ATS
> -
>
> Key: TS-2729
> URL: https://issues.apache.org/jira/browse/TS-2729
> Project: Traffic Server
> Issue Type: New Feature
> Components: HTTP/2
>Reporter: Ryo Okubo
> Labels: review
> Fix For: 5.1.0
>
> Attachments: http2-0004.patch
>
>
> h2. Overview
> We, CDN team of Yahoo! JAPAN, have implemented HTTP/2 support in ATS core
> experimentally.
> Now, it supports HTTP/2 draft-12.
> http://tools.ietf.org/html/draft-ietf-httpbis-http2-12
> Our implementation similar to the SPDY implementation in ATS core(TS-2431)
> but we use nghttp2 library instead of spdylay to interpret HTTP/2 frames.
> https://github.com/tatsuhiro-t/nghttp2
> We tested NPN and ALPN negotiation.
> h2. How to test it
> * Install nghttp2 library, here is URL of this library:
> https://github.com/tatsuhiro-t/nghttp2
> * Use '--enable-http2' option to compile ATS:
> {noformat}
> $ ./configure --enable-http2
> $ make all && make install
> {noformat}
> * You can use '--with-openssl=' option.
> * Need not configure anything if you just want to test HTTP/2 without SSL.
> The code can recognize HTTP2, SPDY or HTTP by reading first to 3rd bytes of
> requests.
> * You can use nghttp in nghttp2 library(or other HTTP/2 client) to request,
> for example:
> {noformat}
> # HTTP/2 without SSL
> $ nghttp -v http://localhost/b.txt
> # HTTP/2 + SSL
> $ nghttp -v https://localhost/b.txt
> {noformat}
> h2. TODO
> * -Cleanup codes.-
> * Follow -http2 draft-12- and later.
> * -Support ALPN.-
> * Add settings related to HTTP/2 into records.config.
> ** it'll refer to configuration settings for SPDY on TS-2740
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2729) Add HTTP/2 support to ATS
[
https://issues.apache.org/jira/browse/TS-2729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Masakazu Kitajo updated TS-2729:
Attachment: (was: ts2760.patch)
> Add HTTP/2 support to ATS
> -
>
> Key: TS-2729
> URL: https://issues.apache.org/jira/browse/TS-2729
> Project: Traffic Server
> Issue Type: New Feature
> Components: HTTP/2
>Reporter: Ryo Okubo
> Labels: review
> Fix For: 5.1.0
>
> Attachments: http2-0004.patch
>
>
> h2. Overview
> We, CDN team of Yahoo! JAPAN, have implemented HTTP/2 support in ATS core
> experimentally.
> Now, it supports HTTP/2 draft-12.
> http://tools.ietf.org/html/draft-ietf-httpbis-http2-12
> Our implementation similar to the SPDY implementation in ATS core(TS-2431)
> but we use nghttp2 library instead of spdylay to interpret HTTP/2 frames.
> https://github.com/tatsuhiro-t/nghttp2
> We tested NPN and ALPN negotiation.
> h2. How to test it
> * Install nghttp2 library, here is URL of this library:
> https://github.com/tatsuhiro-t/nghttp2
> * Use '--enable-http2' option to compile ATS:
> {noformat}
> $ ./configure --enable-http2
> $ make all && make install
> {noformat}
> * You can use '--with-openssl=' option.
> * Need not configure anything if you just want to test HTTP/2 without SSL.
> The code can recognize HTTP2, SPDY or HTTP by reading first to 3rd bytes of
> requests.
> * You can use nghttp in nghttp2 library(or other HTTP/2 client) to request,
> for example:
> {noformat}
> # HTTP/2 without SSL
> $ nghttp -v http://localhost/b.txt
> # HTTP/2 + SSL
> $ nghttp -v https://localhost/b.txt
> {noformat}
> h2. TODO
> * -Cleanup codes.-
> * Follow -http2 draft-12- and later.
> * -Support ALPN.-
> * Add settings related to HTTP/2 into records.config.
> ** it'll refer to configuration settings for SPDY on TS-2740
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2901) 使用esi模块时报 FATAL: FetchSM.cc:160: failed assert `header_done`
[ https://issues.apache.org/jira/browse/TS-2901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14045484#comment-14045484 ] James Peach commented on TS-2901: - What was the fix? > 使用esi模块时报 FATAL: FetchSM.cc:160: failed assert `header_done` > > > Key: TS-2901 > URL: https://issues.apache.org/jira/browse/TS-2901 > Project: Traffic Server > Issue Type: Bug > Components: Plugins >Affects Versions: 5.0.0 >Reporter: helaku > > 报错如下： > [TrafficServer] using root directory '/usr/local/trafficserver-5.0.0' > FATAL: FetchSM.cc:160: failed assert `header_done` > /usr/local/trafficserver-5.0.0/bin/traffic_server - STACK TRACE: > /usr/local/trafficserver-5.0.0/lib/libtsutil.so.5(+0x1f9b8)[0x2b7ecc7459b8] > /usr/local/trafficserver-5.0.0/lib/libtsutil.so.5(+0x1de7f)[0x2b7ecc743e7f] > /usr/local/trafficserver-5.0.0/bin/traffic_server(FetchSM::check_chunked()+0x3d2)[0x49e552] > /usr/local/trafficserver-5.0.0/bin/traffic_server(FetchSM::get_info_from_buffer(IOBufferReader*)+0xa1)[0x49e731] > /usr/local/trafficserver-5.0.0/bin/traffic_server(FetchSM::process_fetch_read(int)+0x20c)[0x4a019c] > /usr/local/trafficserver-5.0.0/bin/traffic_server(FetchSM::fetch_handler(int, > void*)+0x8b)[0x4a02cb] > /usr/local/trafficserver-5.0.0/bin/traffic_server(PluginVC::process_read_side(bool)+0x4ca)[0x4d839a] > /usr/local/trafficserver-5.0.0/bin/traffic_server(PluginVC::main_handler(int, > void*)+0x33a)[0x4da59a] > /usr/local/trafficserver-5.0.0/bin/traffic_server(EThread::process_event(Event*, > int)+0x8f)[0x72962f] > /usr/local/trafficserver-5.0.0/bin/traffic_server(EThread::execute()+0x57b)[0x729f9b] > /usr/local/trafficserver-5.0.0/bin/traffic_server[0x7289da] > /lib64/libpthread.so.0(+0x3c06a07851)[0x2b7ecc978851] > /lib64/libc.so.6(clone+0x6d)[0x3c066e811d] > 报错的同时页面无法打开，关闭esi模块后一切正常，当然同时esi功能也失效了 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (TS-2901) 使用esi模块时报 FATAL: FetchSM.cc:160: failed assert `header_done`
[ https://issues.apache.org/jira/browse/TS-2901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] helaku closed TS-2901. -- Resolution: Fixed > 使用esi模块时报 FATAL: FetchSM.cc:160: failed assert `header_done` > > > Key: TS-2901 > URL: https://issues.apache.org/jira/browse/TS-2901 > Project: Traffic Server > Issue Type: Bug > Components: Plugins >Affects Versions: 5.0.0 >Reporter: helaku > > 报错如下： > [TrafficServer] using root directory '/usr/local/trafficserver-5.0.0' > FATAL: FetchSM.cc:160: failed assert `header_done` > /usr/local/trafficserver-5.0.0/bin/traffic_server - STACK TRACE: > /usr/local/trafficserver-5.0.0/lib/libtsutil.so.5(+0x1f9b8)[0x2b7ecc7459b8] > /usr/local/trafficserver-5.0.0/lib/libtsutil.so.5(+0x1de7f)[0x2b7ecc743e7f] > /usr/local/trafficserver-5.0.0/bin/traffic_server(FetchSM::check_chunked()+0x3d2)[0x49e552] > /usr/local/trafficserver-5.0.0/bin/traffic_server(FetchSM::get_info_from_buffer(IOBufferReader*)+0xa1)[0x49e731] > /usr/local/trafficserver-5.0.0/bin/traffic_server(FetchSM::process_fetch_read(int)+0x20c)[0x4a019c] > /usr/local/trafficserver-5.0.0/bin/traffic_server(FetchSM::fetch_handler(int, > void*)+0x8b)[0x4a02cb] > /usr/local/trafficserver-5.0.0/bin/traffic_server(PluginVC::process_read_side(bool)+0x4ca)[0x4d839a] > /usr/local/trafficserver-5.0.0/bin/traffic_server(PluginVC::main_handler(int, > void*)+0x33a)[0x4da59a] > /usr/local/trafficserver-5.0.0/bin/traffic_server(EThread::process_event(Event*, > int)+0x8f)[0x72962f] > /usr/local/trafficserver-5.0.0/bin/traffic_server(EThread::execute()+0x57b)[0x729f9b] > /usr/local/trafficserver-5.0.0/bin/traffic_server[0x7289da] > /lib64/libpthread.so.0(+0x3c06a07851)[0x2b7ecc978851] > /lib64/libc.so.6(clone+0x6d)[0x3c066e811d] > 报错的同时页面无法打开，关闭esi模块后一切正常，当然同时esi功能也失效了 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2897) enable-linux-native-aio X SSL
[
https://issues.apache.org/jira/browse/TS-2897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14045472#comment-14045472
]
bettydramit commented on TS-2897:
-
This patch may help for you(https://github.com/phonehold/with-aio-ssl-init)
> enable-linux-native-aio X SSL
> --
>
> Key: TS-2897
> URL: https://issues.apache.org/jira/browse/TS-2897
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Affects Versions: 5.0.0
>Reporter: Daniel Picolli Biazus
>
> Hi Guys,
> I could notice that ATS 5.0 is crashing when it is compiled with
> --enable-linux-native-aio option and serving over SSL connections.
> I got the following stack trace:
> [alts] alternate #1 (Q = 1) has these request/response hdrs:
> GET http://127.0.0.1:8080/file.mp4?n=1 HTTP/1.1
> User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.15.3
> zlib/1.2.3 libidn/1.18 libssh2/1.4.2
> Accept: */*
> Host: 127.0.0.1:8080
> Client-ip: xxx.xxx.xxx.xxx
> X-Forwarded-For: xxx.xxx.xxx.xxx
> HTTP/1.1 200 OK
> Server: nginx/1.0.15
> Date: Wed, 25 Jun 2014 18:26:39 GMT
> Content-Type: video/mp4
> Content-Length: 9455997
> Last-Modified: Wed, 25 Jun 2014 18:23:52 GMT
> Connection: keep-alive
> Expires: Wed, 25 Jun 2014 18:31:39 GMT
> Cache-Control: max-age=300
> Accept-Ranges: bytes
> [Jun 25 18:26:41.975] Server {0x7f0c05699700} DEBUG: (http_seq)
> [SelectFromAlternates] Chosen alternate # 0
> [alts] and the winner is alternate number 1
> NOTE: Traffic Server received Sig 11: Segmentation fault
> ./bin/traffic_server - STACK TRACE:
> /lib64/libpthread.so.0(+0xf710)[0x7f0c0a357710]
> ./bin/traffic_server(_Z12ink_aio_readP11AIOCallbacki+0x26)[0x6f7406]
> ./bin/traffic_server(_ZN7CacheVC10handleReadEiP5Event+0x292)[0x6af1e2]
> ./bin/traffic_server(_ZN7CacheVC21openReadStartEarliestEiP5Event+0x336)[0x6d72a6]
> ./bin/traffic_server(_ZN7CacheVC17openReadStartHeadEiP5Event+0x91c)[0x6d821c]
> ./bin/traffic_server(_ZN7CacheVC14handleReadDoneEiP5Event+0x42c)[0x6b63bc]
> ./bin/traffic_server(_ZN5Cache9open_readEP12ContinuationP7INK_MD5P7HTTPHdrP21CacheLookupHttpConfig13CacheFragTypePci+0x363)[0x6db9f3]
> ./bin/traffic_server(_ZN14CacheProcessor9open_readEP12ContinuationP3URLbP7HTTPHdrP21CacheLookupHttpConfigl13CacheFragType+0xad)[0x6b514d]
> ./bin/traffic_server(_ZN11HttpCacheSM9open_readEP3URLP7HTTPHdrP21CacheLookupHttpConfigl+0x94)[0x581424]
> ./bin/traffic_server(_ZN6HttpSM24do_cache_lookup_and_readEv+0xf3)[0x58f543]
> ./bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x714)[0x5a66c4]
> ./bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x2d2)[0x5a8302]
> ./bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x1f2)[0x5a61a2]
> ./bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x806)[0x5a67b6]
> ./bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x2d2)[0x5a8302]
> ./bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x1f2)[0x5a61a2]
> ./bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x2d2)[0x5a8302]
> ./bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x1f2)[0x5a61a2]
> ./bin/traffic_server(_ZN6HttpSM32state_read_client_request_headerEiPv+0x225)[0x59f735]
> ./bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0xd8)[0x5a32b8]
> ./bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x388)[0x5a83b8]
> ./bin/traffic_server(_ZN6HttpSM21attach_client_sessionEP17HttpClientSessionP14IOBufferReader+0x635)[0x5a4025]
> ./bin/traffic_server(_ZN17HttpClientSession15new_transactionEv+0x9d)[0x5823ed]
> ./bin/traffic_server(_ZN17HttpClientSession14new_connectionEP14NetVConnectionbP9MIOBufferP14IOBufferReader+0x2b7)[0x5846f7]
> ./bin/traffic_server(_ZN17HttpSessionAccept6acceptEP14NetVConnectionP9MIOBufferP14IOBufferReader+0x1de)[0x57e7fe]
> ./bin/traffic_server(_ZN23ProtocolProbeTrampoline17ioCompletionEventEiPv+0x5be)[0x4e916e]
> ./bin/traffic_server(_ZN18UnixNetVConnection19readSignalAndUpdateEi+0x27)[0x70b887]
> ./bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0xebf)[0x6fc2bf]
> ./bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x1f2)[0x703722]
> ./bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x73012f]
> ./bin/traffic_server(_ZN7EThread7executeEv+0x493)[0x730ad3]
> ./bin/traffic_server[0x72f4da]
> /lib64/libpthread.so.0(+0x79d1)[0x7f0c0a34f9d1]
> /lib64/libc.so.6(clone+0x6d)[0x7f0c096f8b5d]
> Segmentation fault
>
> This behavior is easily reproduced configuring ATS as a reverse proxy with a
> single origin serving over SSL with "--enable-linux-native-aio" enabled.
> Any thoughts ?
> Thanks & Regards,
> Daniel
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2900) TSHttpConnect response includes chunk sizes
[ https://issues.apache.org/jira/browse/TS-2900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14045470#comment-14045470 ] portl4t commented on TS-2900: - Fact, your plugin act as a browser, so chunked response should be processed in your plugin not matter what version the ATS is. I think your can use FetchSM to implement your business. > TSHttpConnect response includes chunk sizes > --- > > Key: TS-2900 > URL: https://issues.apache.org/jira/browse/TS-2900 > Project: Traffic Server > Issue Type: Bug >Affects Versions: 5.0.0 >Reporter: Peter Walsh > > I just upgraded from 4.2.1 to ATS 5.0.0 but am having issues in my plugins > that use TSHttpConnect. > When the response body is chunked, the response body being returned to my > plugin includes the chunk sizes in the response string. In ATS 4.x, the > plugins received the response body without the chunked sizes as part of it, > meaning ATS handled this under the covers so my plugin didn't have to. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2901) 使用esi模块时报 FATAL: FetchSM.cc:160: failed assert `header_done`
[ https://issues.apache.org/jira/browse/TS-2901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] helaku updated TS-2901: --- Affects Version/s: 5.0.0 > 使用esi模块时报 FATAL: FetchSM.cc:160: failed assert `header_done` > > > Key: TS-2901 > URL: https://issues.apache.org/jira/browse/TS-2901 > Project: Traffic Server > Issue Type: Bug > Components: Plugins >Affects Versions: 5.0.0 >Reporter: helaku > > 报错如下： > [TrafficServer] using root directory '/usr/local/trafficserver-5.0.0' > FATAL: FetchSM.cc:160: failed assert `header_done` > /usr/local/trafficserver-5.0.0/bin/traffic_server - STACK TRACE: > /usr/local/trafficserver-5.0.0/lib/libtsutil.so.5(+0x1f9b8)[0x2b7ecc7459b8] > /usr/local/trafficserver-5.0.0/lib/libtsutil.so.5(+0x1de7f)[0x2b7ecc743e7f] > /usr/local/trafficserver-5.0.0/bin/traffic_server(FetchSM::check_chunked()+0x3d2)[0x49e552] > /usr/local/trafficserver-5.0.0/bin/traffic_server(FetchSM::get_info_from_buffer(IOBufferReader*)+0xa1)[0x49e731] > /usr/local/trafficserver-5.0.0/bin/traffic_server(FetchSM::process_fetch_read(int)+0x20c)[0x4a019c] > /usr/local/trafficserver-5.0.0/bin/traffic_server(FetchSM::fetch_handler(int, > void*)+0x8b)[0x4a02cb] > /usr/local/trafficserver-5.0.0/bin/traffic_server(PluginVC::process_read_side(bool)+0x4ca)[0x4d839a] > /usr/local/trafficserver-5.0.0/bin/traffic_server(PluginVC::main_handler(int, > void*)+0x33a)[0x4da59a] > /usr/local/trafficserver-5.0.0/bin/traffic_server(EThread::process_event(Event*, > int)+0x8f)[0x72962f] > /usr/local/trafficserver-5.0.0/bin/traffic_server(EThread::execute()+0x57b)[0x729f9b] > /usr/local/trafficserver-5.0.0/bin/traffic_server[0x7289da] > /lib64/libpthread.so.0(+0x3c06a07851)[0x2b7ecc978851] > /lib64/libc.so.6(clone+0x6d)[0x3c066e811d] > 报错的同时页面无法打开，关闭esi模块后一切正常，当然同时esi功能也失效了 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TS-2901) 使用esi模块时报 FATAL: FetchSM.cc:160: failed assert `header_done`
helaku created TS-2901: -- Summary: 使用esi模块时报 FATAL: FetchSM.cc:160: failed assert `header_done` Key: TS-2901 URL: https://issues.apache.org/jira/browse/TS-2901 Project: Traffic Server Issue Type: Bug Components: Plugins Reporter: helaku 报错如下： [TrafficServer] using root directory '/usr/local/trafficserver-5.0.0' FATAL: FetchSM.cc:160: failed assert `header_done` /usr/local/trafficserver-5.0.0/bin/traffic_server - STACK TRACE: /usr/local/trafficserver-5.0.0/lib/libtsutil.so.5(+0x1f9b8)[0x2b7ecc7459b8] /usr/local/trafficserver-5.0.0/lib/libtsutil.so.5(+0x1de7f)[0x2b7ecc743e7f] /usr/local/trafficserver-5.0.0/bin/traffic_server(FetchSM::check_chunked()+0x3d2)[0x49e552] /usr/local/trafficserver-5.0.0/bin/traffic_server(FetchSM::get_info_from_buffer(IOBufferReader*)+0xa1)[0x49e731] /usr/local/trafficserver-5.0.0/bin/traffic_server(FetchSM::process_fetch_read(int)+0x20c)[0x4a019c] /usr/local/trafficserver-5.0.0/bin/traffic_server(FetchSM::fetch_handler(int, void*)+0x8b)[0x4a02cb] /usr/local/trafficserver-5.0.0/bin/traffic_server(PluginVC::process_read_side(bool)+0x4ca)[0x4d839a] /usr/local/trafficserver-5.0.0/bin/traffic_server(PluginVC::main_handler(int, void*)+0x33a)[0x4da59a] /usr/local/trafficserver-5.0.0/bin/traffic_server(EThread::process_event(Event*, int)+0x8f)[0x72962f] /usr/local/trafficserver-5.0.0/bin/traffic_server(EThread::execute()+0x57b)[0x729f9b] /usr/local/trafficserver-5.0.0/bin/traffic_server[0x7289da] /lib64/libpthread.so.0(+0x3c06a07851)[0x2b7ecc978851] /lib64/libc.so.6(clone+0x6d)[0x3c066e811d] 报错的同时页面无法打开，关闭esi模块后一切正常，当然同时esi功能也失效了 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2900) TSHttpConnect response includes chunk sizes
[ https://issues.apache.org/jira/browse/TS-2900?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Walsh updated TS-2900: Affects Version/s: 5.0.0 > TSHttpConnect response includes chunk sizes > --- > > Key: TS-2900 > URL: https://issues.apache.org/jira/browse/TS-2900 > Project: Traffic Server > Issue Type: Bug >Affects Versions: 5.0.0 >Reporter: Peter Walsh > > I just upgraded from 4.2.1 to ATS 5.0.0 but am having issues in my plugins > that use TSHttpConnect. > When the response body is chunked, the response body being returned to my > plugin includes the chunk sizes in the response string. In ATS 4.x, the > plugins received the response body without the chunked sizes as part of it, > meaning ATS handled this under the covers so my plugin didn't have to. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TS-2900) TSHttpConnect response includes chunk sizes
Peter Walsh created TS-2900: --- Summary: TSHttpConnect response includes chunk sizes Key: TS-2900 URL: https://issues.apache.org/jira/browse/TS-2900 Project: Traffic Server Issue Type: Bug Reporter: Peter Walsh I just upgraded from 4.2.1 to ATS 5.0.0 but am having issues in my plugins that use TSHttpConnect. When the response body is chunked, the response body being returned to my plugin includes the chunk sizes in the response string. In ATS 4.x, the plugins received the response body without the chunked sizes as part of it, meaning ATS handled this under the covers so my plugin didn't have to. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (TS-2890) Core dump in spdylay_submit_syn_reply
[
https://issues.apache.org/jira/browse/TS-2890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14045183#comment-14045183
]
Sudheer Vinukonda edited comment on TS-2890 at 6/26/14 10:07 PM:
-
It turns out that non-TLS (http) ports disable spdy by default. So, this core
dump is not caused by spdy over http connection. Further, the core re-appeared
in our prod hosts.
Debugging further, it seems that, due to some unknown reason, the event handler
may have dispatched the event to Spdy FetchSM, which tried to process this as a
fetch event. The MIME response header that spdy tried to submit as a syn_reply
seems like garbage (mime hdr length for the response is non-zero, but,
m_freetop seems to be zero, which doesn't make sense).
Below is some gdb output
{code}
(gdb) bt
#0 spdylay_submit_syn_reply (session=0x0, flags=0 '\000', stream_id=337,
nv=0x2b3f240ba150) at spdylay_submit.c:137
#1 0x005efa44 in spdy_process_fetch_header (this=0x2b3f149beeb0,
event=-2, edata=0x2b4013bb64c0) at SpdyClientSession.cc:402
#2 spdy_process_fetch (this=0x2b3f149beeb0, event=-2, edata=0x2b4013bb64c0) at
SpdyClientSession.cc:354
#3 SpdyClientSession::state_session_readwrite (this=0x2b3f149beeb0, event=-2,
edata=0x2b4013bb64c0) at SpdyClientSession.cc:284
#4 0x004a484a in handleEvent (this=0x2b4013bb64c0, error_event=0) at
../iocore/eventsystem/I_Continuation.h:146
#5 FetchSM::InvokePluginExt (this=0x2b4013bb64c0, error_event=0) at
FetchSM.cc:233
#6 0x004a4d27 in FetchSM::process_fetch_read (this=0x2b4013bb64c0,
event=) at FetchSM.cc:400
#7 0x004a4edb in FetchSM::fetch_handler (this=0x2b4013bb64c0,
event=104, edata=0x2b3dfc7df488) at FetchSM.cc:449
#8 0x004dd99a in PluginVC::process_read_side (this=0x2b3dfc7df390,
other_side_call=false) at PluginVC.cc:637
#9 0x004df98a in PluginVC::main_handler (this=0x2b3dfc7df390,
event=, data=0x2b3e50006940) at PluginVC.cc:208
#10 0x0073419f in handleEvent (this=0x2b3cf287d010, e=0x2b3e50006940,
calling_code=1) at I_Continuation.h:146
#11 EThread::process_event (this=0x2b3cf287d010, e=0x2b3e50006940,
calling_code=1) at UnixEThread.cc:145
#12 0x00734d73 in EThread::execute (this=0x2b3cf287d010) at
UnixEThread.cc:239
#13 0x0073354a in spawn_thread_internal (a=0x16d4d20) at Thread.cc:88
#14 0x2b3cf0a05851 in start_thread () from /lib64/libpthread.so.0
#15 0x00366a4e894d in clone () from /lib64/libc.so.6
(gdb) up
#1 0x005efa44 in spdy_process_fetch_header (this=0x2b3f149beeb0,
event=-2, edata=0x2b4013bb64c0) at SpdyClientSession.cc:402
402 SpdyClientSession.cc: No such file or directory.
in SpdyClientSession.cc
(gdb) up
#2 spdy_process_fetch (this=0x2b3f149beeb0, event=-2, edata=0x2b4013bb64c0) at
SpdyClientSession.cc:354
354 in SpdyClientSession.cc
(gdb) print *(((FetchSM*)fetch_sm)->client_response_hdr).m_mime
$1 = { = {m_type = 4, m_length = 592, m_obj_flags = 0},
m_presence_bits = 0, m_slot_accelerators = {4294967295, 4294967295, 4294967295,
4294967295}, m_cooked_stuff = {
m_cache_control = {m_mask = 0, m_secs_max_age = 0, m_secs_s_maxage = 0,
m_secs_max_stale = 0, m_secs_min_fresh = 0}, m_pragma = {m_no_cache = false}},
m_fblock_list_tail = 0x2b3f50d26908, m_first_fblock = { =
{m_type = 5, m_length = 528, m_obj_flags = 0}, m_freetop = 0, m_next = 0x0,
m_field_slots = {{
m_ptr_name = 0x2b3f42a4a011 "Content-Type: application/json;
charset=UTF-8\r\nCache-Control: no-store, private\r\nExpires: Thu, 01 Jan 1970
00:00:00 GMT\r\nX-Server-Chain:
jws10728.mail.gq1.yahoo.com\r\nX-Server-Timestamp: Thu, 26 Jun 20"...,
m_ptr_value = 0x2b3f42a4a01f "application/json;
charset=UTF-8\r\nCache-Control: no-store, private\r\nExpires: Thu, 01 Jan 1970
00:00:00 GMT\r\nX-Server-Chain:
jws10728.mail.gq1.yahoo.com\r\nX-Server-Timestamp: Thu, 26 Jun 2014 01:46:03
GM"..., m_next_dup = 0x0, m_wks_idx = 20, m_len_name = 12, m_len_value = 31,
m_n_v_raw_printable = 1 '\001',
m_n_v_raw_printable_pad = 4 '\004', m_readiness = 2 '\002', m_flags = 1
'\001'}, {
m_ptr_name = 0x2b3f42a4a040 "Cache-Control: no-store,
private\r\nExpires: Thu, 01 Jan 1970 00:00:00 GMT\r\nX-Server-Chain:
jws10728.mail.gq1.yahoo.com\r\nX-Server-Timestamp: Thu, 26 Jun 2014 01:46:03
GMT\r\nX-Server-Response-Time: 10ms\r\n"...,
m_ptr_value = 0x2b3f42a4a04f "no-store, private\r\nExpires: Thu, 01 Jan
1970 00:00:00 GMT\r\nX-Server-Chain:
jws10728.mail.gq1.yahoo.com\r\nX-Server-Timestamp: Thu, 26 Jun 2014 01:46:03
GMT\r\nX-Server-Response-Time: 10ms\r\nContent-Length:"..., m_next_dup = 0x0,
m_wks_idx = 10, m_len_name = 13, m_len_value = 17, m_n_v_raw_printable = 1
'\001',
m_n_v_raw_printable_pad = 4 '\004', m_readiness = 2 '\002', m_flags = 3
'\003'}, {
m_ptr_name = 0x2b3f42a4a062 "Expires: Thu, 01 Jan 1970 00:00:00
GMT\r\n
[jira] [Commented] (TS-2890) Core dump in spdylay_submit_syn_reply
[
https://issues.apache.org/jira/browse/TS-2890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14045183#comment-14045183
]
Sudheer Vinukonda commented on TS-2890:
---
It turns out that non-TLS (http) ports disable spdy by default. So, this core
dump is not caused by spdy over http connection. It also appeared again in our
prod hosts.
Debugging further, it seems that, due to some unknown reason, the event handler
may have dispatched the event to Spdy FetchSM, which tried to process this as a
fetch event. The MIME response header that spdy tried to submit as a syn_reply
seems like garbage (mime hdr length for the response is non-zero, but,
m_freetop seems to be non-zero, which doesn't make sense).
Below is some gdb output
{code}
(gdb) bt
#0 spdylay_submit_syn_reply (session=0x0, flags=0 '\000', stream_id=337,
nv=0x2b3f240ba150) at spdylay_submit.c:137
#1 0x005efa44 in spdy_process_fetch_header (this=0x2b3f149beeb0,
event=-2, edata=0x2b4013bb64c0) at SpdyClientSession.cc:402
#2 spdy_process_fetch (this=0x2b3f149beeb0, event=-2, edata=0x2b4013bb64c0) at
SpdyClientSession.cc:354
#3 SpdyClientSession::state_session_readwrite (this=0x2b3f149beeb0, event=-2,
edata=0x2b4013bb64c0) at SpdyClientSession.cc:284
#4 0x004a484a in handleEvent (this=0x2b4013bb64c0, error_event=0) at
../iocore/eventsystem/I_Continuation.h:146
#5 FetchSM::InvokePluginExt (this=0x2b4013bb64c0, error_event=0) at
FetchSM.cc:233
#6 0x004a4d27 in FetchSM::process_fetch_read (this=0x2b4013bb64c0,
event=) at FetchSM.cc:400
#7 0x004a4edb in FetchSM::fetch_handler (this=0x2b4013bb64c0,
event=104, edata=0x2b3dfc7df488) at FetchSM.cc:449
#8 0x004dd99a in PluginVC::process_read_side (this=0x2b3dfc7df390,
other_side_call=false) at PluginVC.cc:637
#9 0x004df98a in PluginVC::main_handler (this=0x2b3dfc7df390,
event=, data=0x2b3e50006940) at PluginVC.cc:208
#10 0x0073419f in handleEvent (this=0x2b3cf287d010, e=0x2b3e50006940,
calling_code=1) at I_Continuation.h:146
#11 EThread::process_event (this=0x2b3cf287d010, e=0x2b3e50006940,
calling_code=1) at UnixEThread.cc:145
#12 0x00734d73 in EThread::execute (this=0x2b3cf287d010) at
UnixEThread.cc:239
#13 0x0073354a in spawn_thread_internal (a=0x16d4d20) at Thread.cc:88
#14 0x2b3cf0a05851 in start_thread () from /lib64/libpthread.so.0
#15 0x00366a4e894d in clone () from /lib64/libc.so.6
(gdb) up
#1 0x005efa44 in spdy_process_fetch_header (this=0x2b3f149beeb0,
event=-2, edata=0x2b4013bb64c0) at SpdyClientSession.cc:402
402 SpdyClientSession.cc: No such file or directory.
in SpdyClientSession.cc
(gdb) up
#2 spdy_process_fetch (this=0x2b3f149beeb0, event=-2, edata=0x2b4013bb64c0) at
SpdyClientSession.cc:354
354 in SpdyClientSession.cc
(gdb) print *(((FetchSM*)fetch_sm)->client_response_hdr).m_mime
$1 = { = {m_type = 4, m_length = 592, m_obj_flags = 0},
m_presence_bits = 0, m_slot_accelerators = {4294967295, 4294967295, 4294967295,
4294967295}, m_cooked_stuff = {
m_cache_control = {m_mask = 0, m_secs_max_age = 0, m_secs_s_maxage = 0,
m_secs_max_stale = 0, m_secs_min_fresh = 0}, m_pragma = {m_no_cache = false}},
m_fblock_list_tail = 0x2b3f50d26908, m_first_fblock = { =
{m_type = 5, m_length = 528, m_obj_flags = 0}, m_freetop = 0, m_next = 0x0,
m_field_slots = {{
m_ptr_name = 0x2b3f42a4a011 "Content-Type: application/json;
charset=UTF-8\r\nCache-Control: no-store, private\r\nExpires: Thu, 01 Jan 1970
00:00:00 GMT\r\nX-Server-Chain:
jws10728.mail.gq1.yahoo.com\r\nX-Server-Timestamp: Thu, 26 Jun 20"...,
m_ptr_value = 0x2b3f42a4a01f "application/json;
charset=UTF-8\r\nCache-Control: no-store, private\r\nExpires: Thu, 01 Jan 1970
00:00:00 GMT\r\nX-Server-Chain:
jws10728.mail.gq1.yahoo.com\r\nX-Server-Timestamp: Thu, 26 Jun 2014 01:46:03
GM"..., m_next_dup = 0x0, m_wks_idx = 20, m_len_name = 12, m_len_value = 31,
m_n_v_raw_printable = 1 '\001',
m_n_v_raw_printable_pad = 4 '\004', m_readiness = 2 '\002', m_flags = 1
'\001'}, {
m_ptr_name = 0x2b3f42a4a040 "Cache-Control: no-store,
private\r\nExpires: Thu, 01 Jan 1970 00:00:00 GMT\r\nX-Server-Chain:
jws10728.mail.gq1.yahoo.com\r\nX-Server-Timestamp: Thu, 26 Jun 2014 01:46:03
GMT\r\nX-Server-Response-Time: 10ms\r\n"...,
m_ptr_value = 0x2b3f42a4a04f "no-store, private\r\nExpires: Thu, 01 Jan
1970 00:00:00 GMT\r\nX-Server-Chain:
jws10728.mail.gq1.yahoo.com\r\nX-Server-Timestamp: Thu, 26 Jun 2014 01:46:03
GMT\r\nX-Server-Response-Time: 10ms\r\nContent-Length:"..., m_next_dup = 0x0,
m_wks_idx = 10, m_len_name = 13, m_len_value = 17, m_n_v_raw_printable = 1
'\001',
m_n_v_raw_printable_pad = 4 '\004', m_readiness = 2 '\002', m_flags = 3
'\003'}, {
m_ptr_name = 0x2b3f42a4a062 "Expires: Thu, 01 Jan 1970 00:00:00
GMT\r\nX-Server-Chain: jws10728.mail.gq1.yahoo.com\r\nX-Serve
[jira] [Created] (TS-2899) traffic server does not build on ppc64 little endian
Breno Leitao created TS-2899: Summary: traffic server does not build on ppc64 little endian Key: TS-2899 URL: https://issues.apache.org/jira/browse/TS-2899 Project: Traffic Server Issue Type: Wish Components: Build Reporter: Breno Leitao When trying to build traffic search on ppc64 little endian, I got the following error: c++ -DHAVE_CONFIG_H -I. -I../../lib/ts -I../../lib -I../../lib/records -I../../lib/ts -D_FORTIFY_SOURCE=2 -Dlinux -D_LARGEFILE64_SOURCE=1 -D_COMPILE64BIT_SOURCE=1 -D_GNU_SOURCE -D_REENTRANT -I/usr/include/tcl8.5 -I/usr/include/libxml2 -Wunused-parameter -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -std=c++11 -pipe -Wall -feliminate-unused-debug-symbols -fno-strict-aliasing -Wno-invalid-offsetof -MT EventSystem.o -MD -MP -MF .deps/EventSystem.Tpo -c -o EventSystem.o EventSystem.cc In file included from ../../lib/ts/libts.h:64:0, from P_EventSystem.h:34, from EventSystem.cc:31: ../../lib/ts/ink_queue.h:144:2: error: #error "unsupported processor" #error "unsupported processor" If someone want to port it to ppc64 little endian, you can find a machine available at https://wiki.debian.org/ppc64el#Development_machines Thank you, Breno -- This message was sent by Atlassian JIRA (v6.2#6252)
