[jira] [Commented] (TS-2723) Add new features for ts_lua.
[ https://issues.apache.org/jira/browse/TS-2723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14004507#comment-14004507 ] portl4t commented on TS-2723: - I think we can ignore `ts.shared.DICT` to get other features in 5.0.0 release, and we may refine ts.shared.DICT later. I also agree to reuse ts api for doing base64 encoding and uri encoding. Add new features for ts_lua. Key: TS-2723 URL: https://issues.apache.org/jira/browse/TS-2723 Project: Traffic Server Issue Type: Bug Components: Lua, Plugins Reporter: portl4t Assignee: Kit Chan Fix For: 5.0.0 Attachments: 0001-TS-2723-add-new-features-for-ts_lua.patch, 0001-TS-2723-refine-doc-for-ts_lua.patch After TS-2555, Kit Chan and me will integrate new features from https://github.com/portl4t/ts-lua into plugins/experimental/ts_lua. -- 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-tabpanelfocusedCommentId=14004525#comment-14004525
]
kawtar Arbani commented on TS-2729:
---
hello,
I'm trying to apply these patches but I don't know which source code should I
have, I've download httpd-2.4.9, but i'm having some missing files.
Can you please help?
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: cleanuped-0002.patch, draft11.patch, draft12.patch,
fix-handling-version-string.patch, http2-0001.patch, http2-0002.patch,
ts2743.patch, ts2760.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=dir' 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-2825) Segmentation fault on POST request transformation
[
https://issues.apache.org/jira/browse/TS-2825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pasquale Puzio updated TS-2825:
---
Priority: Critical (was: Major)
Segmentation fault on POST request transformation
-
Key: TS-2825
URL: https://issues.apache.org/jira/browse/TS-2825
Project: Traffic Server
Issue Type: Bug
Components: Core, HTTP, Lua, Plugins, TS API
Reporter: Pasquale Puzio
Priority: Critical
I'm trying to write a simple encryption/decryption plugin for Apache Traffic
Server. The plugin should transform requests/responses in order to
encrypt/decrypt them. I decided to write the plugin in LUA (using the ts-lua
plugin available here https://github.com/portl4t/ts-lua)
function encrypt(data, eos)
if (data == '') then
return data, eos
end
if (eos == 1) then
ts.debug('End of Stream')
end
return data, eos
end
function do_remap()
ts.debug('do_remap')
if (ts.client_request.get_method() == 'POST') then
ts.hook(TS_LUA_REQUEST_TRANSFORM, encrypt)
end
ts.http.resp_cache_transformed(0)
ts.http.resp_cache_untransformed(0)
return 0
end
Everything works fine for GET and DELETE requests, but when I send a POST
chunked-encoded request, ATS crashes almost every time.
if I don't activate the request transformation hook, the chunked request is
forwarded perfectly. Most of the time, if one request is forwarded
succesfully, the one after crashes.
Here is the stack trace:
[May 20 13:16:28.105] Server {0x7f045a1c1700} DEBUG: (http_redirect)
[HttpSM::do_redirect]
[May 20 13:16:28.105] Server {0x7f045a1c1700} DEBUG: (http_redirect)
[HttpTunnel::deallocate_postdata_copy_buffers]
NOTE: Traffic Server received Sig 11: Segmentation fault
bin/traffic_server - STACK TRACE:
/lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0)[0x7f045cd29cb0]
bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x171)[0x5c274f]
bin/traffic_server(_ZN6HttpSM17state_api_calloutEiPv+0x883)[0x5c24cf]
bin/traffic_server(_ZN6HttpSM23do_api_callout_internalEv+0x1b7)[0x5ceaef]
bin/traffic_server(_ZN6HttpSM14do_api_calloutEv+0x26)[0x5dc18e]
bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x12f9)[0x5d6a19]
bin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x1ba)[0x5d5718]
bin/traffic_server(_ZN6HttpSM36state_common_wait_for_transform_readEP17HttpTransformInfoMS_FiiPvEiS2_+0x39b)[0x5c1a11]
bin/traffic_server(_ZN6HttpSM37state_request_wait_for_transform_readEiPv+0x1e1)[0x5c1483]
bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0x333)[0x5c5eeb]
bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x68)[0x4f06b2]
bin/traffic_server(_ZN17TransformTerminus12handle_eventEiPv+0x2f6)[0x538d2a]
bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x68)[0x4f06b2]
bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x11e)[0x7537e2]
bin/traffic_server(_ZN7EThread7executeEv+0xc9)[0x753a27]
bin/traffic_server[0x752ca7]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x7e9a)[0x7f045cd21e9a]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f045c0383fd]
Segmentation fault (core dumped)
I've already tried to use one of the example plugins for request
transformation and I still have the same problem. The only way to make the
problem disappear is to avoid request transformation.
Is there something wrong in the way I'm transforming requests? What does this
segmentation fault depend on?
Thanks
--
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-tabpanelfocusedCommentId=14004539#comment-14004539
]
Ryo Okubo commented on TS-2729:
---
Hi, kawtar
This patch is only for _TrafficServer_. so you can't apply it to httpd.
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: cleanuped-0002.patch, draft11.patch, draft12.patch,
fix-handling-version-string.patch, http2-0001.patch, http2-0002.patch,
ts2743.patch, ts2760.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=dir' 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-1125) POST's with Expect: 100-continue are slowed by delayed 100 response.
[ https://issues.apache.org/jira/browse/TS-1125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Feifei Cai updated TS-1125: --- Attachment: TS-1125.diff Some changes of the new patch: 1. Change the configuration option for 100 continue response, not using overridable configuration. 2. Use normal VIO APIs, instead of the initial fix of raw write. POST's with Expect: 100-continue are slowed by delayed 100 response. Key: TS-1125 URL: https://issues.apache.org/jira/browse/TS-1125 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 3.0.2 Environment: TS 3.0.2 going to Apache 2.2 web server Reporter: William Bardwell Assignee: Bryan Call Priority: Minor Labels: yahoo Fix For: 5.0.0 Attachments: TS-1125.diff, TS-1125.diff, ts1125.diff, ts1125.diff, ts1125.diff Sending a post like: POST / HTTP/1.1 Host: www.example.com Content-Length: 10 Expect: 100-continue directly to the web server immediately sends back: HTTP/1.1 100 Continue And then when the post data is sent, a status 200 response comes back. But when going through ATS the HTTP/1.1 100 Continue is not sent immediately, and instead is sent after the POST data has been received. This is legal, but it makes clients that are hoping for a 100 continue to wait a little while hoping to get that, ATS should forward that response through immediately. Note: I see curl using Expect: 100-continue with 1024 bytes of post data, but web searching indicates that some Microsoft products also use it. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2723) Add new features for ts_lua.
[ https://issues.apache.org/jira/browse/TS-2723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14004738#comment-14004738 ] Kit Chan commented on TS-2723: -- So [~portl4t], will you be submitting a new patch? If not, please let me know and I will be glad to make the changes on top of your existing one. Thanks. Add new features for ts_lua. Key: TS-2723 URL: https://issues.apache.org/jira/browse/TS-2723 Project: Traffic Server Issue Type: Bug Components: Lua, Plugins Reporter: portl4t Assignee: Kit Chan Fix For: 5.0.0 Attachments: 0001-TS-2723-add-new-features-for-ts_lua.patch, 0001-TS-2723-refine-doc-for-ts_lua.patch After TS-2555, Kit Chan and me will integrate new features from https://github.com/portl4t/ts-lua into plugins/experimental/ts_lua. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2794) Build failure related to header requirements of atscppapi
[
https://issues.apache.org/jira/browse/TS-2794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryo Okubo updated TS-2794:
--
Attachment: shared_ptr_h_in.patch
I see. I agree with your opinions and close pull-request for now.
As another solution which don't need config header, I suggest the way that
create shared_ptr.h automatically by using variables of configure.ac. It fixes
build failure but it may make complex autoconf's settings.
Build failure related to header requirements of atscppapi
-
Key: TS-2794
URL: https://issues.apache.org/jira/browse/TS-2794
Project: Traffic Server
Issue Type: Bug
Components: CPP API
Reporter: Ryo Okubo
Assignee: Brian Geffon
Fix For: 5.0.0
Attachments: shared_ptr_h_in.patch
When I built my plugin outside of trafficserver source tree, I found build
failure related to header requirements of atscppapi as below logs.
{noformat}
# I set /usr/local/trafficserver/ as prefix.
In file included from
/usr/local/trafficserver/include/atscppapi/Transaction.h:30:
/usr/local/trafficserver/include/atscppapi/shared_ptr.h:28:10: fatal error:
'ink_autoconf.h' file not found
#include ink_autoconf.h
^
1 error generated.
{noformat}
The shared_ptr.h requires a variable defined on ink_autoconf.h but it doesn't
exist in destination directory. so I've already posted Pull-Request on GitHub
to fix it. please review, and show me better solution if you have.
https://github.com/apache/trafficserver/pull/80
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2824) ioBufferAllocator objects in ATS master keep growing endlessly
[
https://issues.apache.org/jira/browse/TS-2824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14004756#comment-14004756
]
Sudheer Vinukonda commented on TS-2824:
---
Confirmed after running overnight that, the removal of TS-2592 does indeed
help. Without TS-2592's changes, the memory usage remains stable and the
ioBuffers don't grow indefinitely anymore.
ioBufferAllocator objects in ATS master keep growing endlessly
--
Key: TS-2824
URL: https://issues.apache.org/jira/browse/TS-2824
Project: Traffic Server
Issue Type: Bug
Components: Core
Reporter: Sudheer Vinukonda
During our production testing of ATS master, I noticed that ATS memory keeps
growing beyond ram cache size limits. Upon enabling the memory allocation
dump, it looks like the ioBufAllocator objects keep growing endlessly.
Talking to [~psudaemon] and [~amc] on irc, it looks like the issue might be
caused due to NOT in-use proxy allocator (local thread) objects accumulating
until they reach the per thread object count limit (250). This may be
significant memory for large sized objects (e.g 1MB or 2MB). [~psudaemon]
recommended to try reverting the changes in TS-2592 that force to use Proxy
allocator instead of global pool objects for ioBuffers. (Note that my
production host has ram cache set to 6G and that is completely used, but, the
ioBuffers just keep growing)
Here's the dump of memory allocations:
{code}
-bash-4.1$ sudo grep ioBufAllocator\[13\] traffic.out
0 | 0 |1048576 |
memory/ioBufAllocator[13]
1174405120 | 1151336448 |1048576 |
memory/ioBufAllocator[13]
4194304000 | 4186963968 |1048576 |
memory/ioBufAllocator[13]
1912602624 | 1908408320 |1048576 |
memory/ioBufAllocator[13]
771751936 | 759169024 |1048576 |
memory/ioBufAllocator[13]
1610612736 | 1608515584 |1048576 |
memory/ioBufAllocator[13]
1509949440 | 1484783616 |1048576 |
memory/ioBufAllocator[13]
3724541952 | 3697278976 |1048576 |
memory/ioBufAllocator[13]
2046820352 | 2023751680 |1048576 |
memory/ioBufAllocator[13]
2046820352 | 2036334592 |1048576 |
memory/ioBufAllocator[13]
2147483648 | 2128609280 |1048576 |
memory/ioBufAllocator[13]
2181038080 | 2172649472 |1048576 |
memory/ioBufAllocator[13]
2214592512 | 2204106752 |1048576 |
memory/ioBufAllocator[13]
2281701376 | 2253389824 |1048576 |
memory/ioBufAllocator[13]
2315255808 | 2287992832 |1048576 |
memory/ioBufAllocator[13]
2348810240 | 2316304384 |1048576 |
memory/ioBufAllocator[13]
2348810240 | 2336227328 |1048576 |
memory/ioBufAllocator[13]
2382364672 | 2380267520 |1048576 |
memory/ioBufAllocator[13]
2449473536 | 2424307712 |1048576 |
memory/ioBufAllocator[13]
2449473536 | 2447376384 |1048576 |
memory/ioBufAllocator[13]
2483027968 | 2474639360 |1048576 |
memory/ioBufAllocator[13]
2516582400 | 2507145216 |1048576 |
memory/ioBufAllocator[13]
2550136832 | 2543845376 |1048576 |
memory/ioBufAllocator[13]
2617245696 | 2599419904 |1048576 |
memory/ioBufAllocator[13]
2650800128 | 2626682880 |1048576 |
memory/ioBufAllocator[13]
2684354560 | 2659188736 |1048576 |
memory/ioBufAllocator[13]
2684354560 | 2675965952 |1048576 |
memory/ioBufAllocator[13]
2717908992 | 2690646016 |1048576 |
memory/ioBufAllocator[13]
2717908992 | 2713714688 |1048576 |
memory/ioBufAllocator[13]
2785017856 | 2758803456 |1048576 |
memory/ioBufAllocator[13]
2818572288 | 2792357888 |1048576 |
memory/ioBufAllocator[13]
2852126720 | 2823815168 |1048576 |
memory/ioBufAllocator[13]
2885681152 | 2882535424 |1048576 |
memory/ioBufAllocator[13]
2952790016 | 2921332736 |1048576 |
memory/ioBufAllocator[13]
298638 | 2959081472 |1048576 |
memory/ioBufAllocator[13]
298638 | 2985295872 |1048576 |
memory/ioBufAllocator[13]
3019898880 | 3014656000 |1048576 |
memory/ioBufAllocator[13]
3087007744 | 3067084800 |1048576 |
memory/ioBufAllocator[13]
3120562176 | 3104833536 |1048576 |
[jira] [Comment Edited] (TS-2794) Build failure related to header requirements of atscppapi
[
https://issues.apache.org/jira/browse/TS-2794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14004758#comment-14004758
]
Ryo Okubo edited comment on TS-2794 at 5/21/14 3:22 PM:
I see. I agree with your opinions and close pull-request for now.
As another solution which don't need config header, I suggest the way that
create shared_ptr.h automatically by using variables of configure.ac. Please
see attached patch about this. It fixes build failure but it may make complex
autoconf's settings.
was (Author: rokubo):
I see. I agree with your opinions and close pull-request for now.
As another solution which don't need config header, I suggest the way that
create shared_ptr.h automatically by using variables of configure.ac. It fixes
build failure but it may make complex autoconf's settings.
Build failure related to header requirements of atscppapi
-
Key: TS-2794
URL: https://issues.apache.org/jira/browse/TS-2794
Project: Traffic Server
Issue Type: Bug
Components: CPP API
Reporter: Ryo Okubo
Assignee: Brian Geffon
Fix For: 5.0.0
Attachments: shared_ptr_h_in.patch
When I built my plugin outside of trafficserver source tree, I found build
failure related to header requirements of atscppapi as below logs.
{noformat}
# I set /usr/local/trafficserver/ as prefix.
In file included from
/usr/local/trafficserver/include/atscppapi/Transaction.h:30:
/usr/local/trafficserver/include/atscppapi/shared_ptr.h:28:10: fatal error:
'ink_autoconf.h' file not found
#include ink_autoconf.h
^
1 error generated.
{noformat}
The shared_ptr.h requires a variable defined on ink_autoconf.h but it doesn't
exist in destination directory. so I've already posted Pull-Request on GitHub
to fix it. please review, and show me better solution if you have.
https://github.com/apache/trafficserver/pull/80
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Comment Edited] (TS-2817) ATS crash in SSLNetVConnection::load_buffer_and_write
[
https://issues.apache.org/jira/browse/TS-2817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14004791#comment-14004791
]
Sudheer Vinukonda edited comment on TS-2817 at 5/21/14 3:43 PM:
Confirmed that the core dump is related to TS-2815 changes (reverting back
TS-2815 seems to fix the crash).
was (Author: sudheerv):
Update - Reverting back TS-2815 changes seem to fix the core dump..
ATS crash in SSLNetVConnection::load_buffer_and_write
-
Key: TS-2817
URL: https://issues.apache.org/jira/browse/TS-2817
Project: Traffic Server
Issue Type: Bug
Components: Core
Reporter: Sudheer Vinukonda
Our production host running latest master crashed with the below stack
traces. Based on the stack traces, this might be related to a recent jira
TS-2815. On second thought, this may also be a duplicate of TS-2776.
{code}
[E. Mgmt] log == [TrafficManager] using root directory '/home/y'
[example_prep.sh] Checking/Moving old cores...
[TrafficServer] using root directory '/home/y'
NOTE: Traffic Server received Sig 11: Segmentation fault
/home/y/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0(+0x329720f500)[0x2b8c4da4f500]
/usr/lib64/libssl.so.10[0x331622b2e7]
/usr/lib64/libssl.so.10(ssl3_write_bytes+0x75)[0x331622b905]
/home/y/bin/traffic_server(_ZN17SSLNetVConnection21load_buffer_and_writeElRlS0_R17MIOBufferAccessorRi+0xdf)[0x6fbb6f]
/home/y/bin/traffic_server(_Z15write_to_net_ioP10NetHandlerP18UnixNetVConnectionP7EThread+0x368)[0x70f938]
/home/y/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x283)[0x7046d3]
/home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x73278f]
/home/y/bin/traffic_server(_ZN7EThread7executeEv+0x493)[0x733133]
/home/y/bin/traffic_server[0x731b3a]
/lib64/libpthread.so.0(+0x3297207851)[0x2b8c4da47851]
/lib64/libc.so.6(clone+0x6d)[0x3296ee890d]
[example_alarm_bin.sh] sent alarm: l10.ycs.sjb.yahoo.com [Sat May 17 20:13:29
2014] The TS-TM connection is broken for some reason. Either restart TS and TM
or correct this error for TM
to display TS statistics correctly
[E. Mgmt] log == [TrafficManager] using root directory '/home/y'
[example_prep.sh] Checking/Moving old cores...
[TrafficServer] using root directory '/home/y'
NOTE: Traffic Server received Sig 11: Segmentation fault
/home/y/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0(+0x329720f500)[0x2aed4fbcc500]
/lib64/libc.so.6(memcpy+0x15b)[0x3296e8997b]
/home/y/bin/traffic_server(_ZN9LogAccess11marshal_memEPcPKcii+0x2f)[0x60f11f]
/home/y/bin/traffic_server(_ZN13LogAccessHttp28marshal_client_req_url_canonEPc+0x20)[0x6114e0]
/home/y/bin/traffic_server(_ZN12LogFieldList7marshalEP9LogAccessPc+0x32)[0x61d1e2]
/home/y/bin/traffic_server(_ZN9LogObject3logEP9LogAccessPKc+0x319)[0x628ba9]
/home/y/bin/traffic_server(_ZN16LogObjectManager3logEP9LogAccess+0x5e)[0x6295be]
/home/y/bin/traffic_server(_ZN6HttpSM12update_statsEv+0x5d8)[0x599ce8]
/home/y/bin/traffic_server(_ZN6HttpSM9kill_thisEv+0x7a0)[0x5a4a40]
/home/y/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0x188)[0x5a4dc8]
/home/y/bin/traffic_server(_ZN10HttpTunnel12main_handlerEiPv+0xe0)[0x5e7050]
/home/y/bin/traffic_server[0x70d6f1]
/home/y/bin/traffic_server(_Z15write_to_net_ioP10NetHandlerP18UnixNetVConnectionP7EThread+0x95b)[0x70ff2b]
/home/y/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x283)[0x7046d3]
/home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x73278f]
/home/y/bin/traffic_server(_ZN7EThread7executeEv+0x493)[0x733133]
/home/y/bin/traffic_server[0x731b3a]
/lib64/libpthread.so.0(+0x3297207851)[0x2aed4fbc4851]
/lib64/libc.so.6(clone+0x6d)[0x3296ee890d]
[E. Mgmt] log == [TrafficManager] using root directory '/
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2817) ATS crash in SSLNetVConnection::load_buffer_and_write
[
https://issues.apache.org/jira/browse/TS-2817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14004791#comment-14004791
]
Sudheer Vinukonda commented on TS-2817:
---
Update - Reverting back TS-2815 changes seem to fix the core dump..
ATS crash in SSLNetVConnection::load_buffer_and_write
-
Key: TS-2817
URL: https://issues.apache.org/jira/browse/TS-2817
Project: Traffic Server
Issue Type: Bug
Components: Core
Reporter: Sudheer Vinukonda
Our production host running latest master crashed with the below stack
traces. Based on the stack traces, this might be related to a recent jira
TS-2815. On second thought, this may also be a duplicate of TS-2776.
{code}
[E. Mgmt] log == [TrafficManager] using root directory '/home/y'
[example_prep.sh] Checking/Moving old cores...
[TrafficServer] using root directory '/home/y'
NOTE: Traffic Server received Sig 11: Segmentation fault
/home/y/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0(+0x329720f500)[0x2b8c4da4f500]
/usr/lib64/libssl.so.10[0x331622b2e7]
/usr/lib64/libssl.so.10(ssl3_write_bytes+0x75)[0x331622b905]
/home/y/bin/traffic_server(_ZN17SSLNetVConnection21load_buffer_and_writeElRlS0_R17MIOBufferAccessorRi+0xdf)[0x6fbb6f]
/home/y/bin/traffic_server(_Z15write_to_net_ioP10NetHandlerP18UnixNetVConnectionP7EThread+0x368)[0x70f938]
/home/y/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x283)[0x7046d3]
/home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x73278f]
/home/y/bin/traffic_server(_ZN7EThread7executeEv+0x493)[0x733133]
/home/y/bin/traffic_server[0x731b3a]
/lib64/libpthread.so.0(+0x3297207851)[0x2b8c4da47851]
/lib64/libc.so.6(clone+0x6d)[0x3296ee890d]
[example_alarm_bin.sh] sent alarm: l10.ycs.sjb.yahoo.com [Sat May 17 20:13:29
2014] The TS-TM connection is broken for some reason. Either restart TS and TM
or correct this error for TM
to display TS statistics correctly
[E. Mgmt] log == [TrafficManager] using root directory '/home/y'
[example_prep.sh] Checking/Moving old cores...
[TrafficServer] using root directory '/home/y'
NOTE: Traffic Server received Sig 11: Segmentation fault
/home/y/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0(+0x329720f500)[0x2aed4fbcc500]
/lib64/libc.so.6(memcpy+0x15b)[0x3296e8997b]
/home/y/bin/traffic_server(_ZN9LogAccess11marshal_memEPcPKcii+0x2f)[0x60f11f]
/home/y/bin/traffic_server(_ZN13LogAccessHttp28marshal_client_req_url_canonEPc+0x20)[0x6114e0]
/home/y/bin/traffic_server(_ZN12LogFieldList7marshalEP9LogAccessPc+0x32)[0x61d1e2]
/home/y/bin/traffic_server(_ZN9LogObject3logEP9LogAccessPKc+0x319)[0x628ba9]
/home/y/bin/traffic_server(_ZN16LogObjectManager3logEP9LogAccess+0x5e)[0x6295be]
/home/y/bin/traffic_server(_ZN6HttpSM12update_statsEv+0x5d8)[0x599ce8]
/home/y/bin/traffic_server(_ZN6HttpSM9kill_thisEv+0x7a0)[0x5a4a40]
/home/y/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0x188)[0x5a4dc8]
/home/y/bin/traffic_server(_ZN10HttpTunnel12main_handlerEiPv+0xe0)[0x5e7050]
/home/y/bin/traffic_server[0x70d6f1]
/home/y/bin/traffic_server(_Z15write_to_net_ioP10NetHandlerP18UnixNetVConnectionP7EThread+0x95b)[0x70ff2b]
/home/y/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x283)[0x7046d3]
/home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x73278f]
/home/y/bin/traffic_server(_ZN7EThread7executeEv+0x493)[0x733133]
/home/y/bin/traffic_server[0x731b3a]
/lib64/libpthread.so.0(+0x3297207851)[0x2aed4fbc4851]
/lib64/libc.so.6(clone+0x6d)[0x3296ee890d]
[E. Mgmt] log == [TrafficManager] using root directory '/
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Comment Edited] (TS-2794) Build failure related to header requirements of atscppapi
[
https://issues.apache.org/jira/browse/TS-2794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14004758#comment-14004758
]
Ryo Okubo edited comment on TS-2794 at 5/21/14 3:44 PM:
I see. I agree with your opinions and close pull-request for now.
As another solution which don't need config header, I suggest the way that
create shared_ptr.h automatically by using variables of configure.ac. Please
see attached patch about this. It fixes build failure but it may make
autoconf's settings complex.
was (Author: rokubo):
I see. I agree with your opinions and close pull-request for now.
As another solution which don't need config header, I suggest the way that
create shared_ptr.h automatically by using variables of configure.ac. Please
see attached patch about this. It fixes build failure but it may make complex
autoconf's settings.
Build failure related to header requirements of atscppapi
-
Key: TS-2794
URL: https://issues.apache.org/jira/browse/TS-2794
Project: Traffic Server
Issue Type: Bug
Components: CPP API
Reporter: Ryo Okubo
Assignee: Brian Geffon
Fix For: 5.0.0
Attachments: shared_ptr_h_in.patch
When I built my plugin outside of trafficserver source tree, I found build
failure related to header requirements of atscppapi as below logs.
{noformat}
# I set /usr/local/trafficserver/ as prefix.
In file included from
/usr/local/trafficserver/include/atscppapi/Transaction.h:30:
/usr/local/trafficserver/include/atscppapi/shared_ptr.h:28:10: fatal error:
'ink_autoconf.h' file not found
#include ink_autoconf.h
^
1 error generated.
{noformat}
The shared_ptr.h requires a variable defined on ink_autoconf.h but it doesn't
exist in destination directory. so I've already posted Pull-Request on GitHub
to fix it. please review, and show me better solution if you have.
https://github.com/apache/trafficserver/pull/80
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2822) Crash in LogBufferIterator::next
[ https://issues.apache.org/jira/browse/TS-2822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14004894#comment-14004894 ] ASF subversion and git services commented on TS-2822: - Commit 374355c01caa7e2e88a51def5506abee6209fa51 in trafficserver's branch refs/heads/master from [~briang] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=374355c ] [TS-2822] Crash in LogBufferIterator::next Crash in LogBufferIterator::next Key: TS-2822 URL: https://issues.apache.org/jira/browse/TS-2822 Project: Traffic Server Issue Type: Bug Components: Logging Affects Versions: 4.2.1, 5.0.0 Reporter: Brian Geffon Assignee: Brian Geffon It appears there is a crash in traffic_logstats that's consistently happening in LogBufferIterator::next, a sample stack trace is attached. I'll be looking into the issue. #0 0x00465c1d in LogBufferIterator::next (this=0x7fff435bd7b0) at LogBuffer.cc:813 #1 0x00448fd2 in parse_log_buff (buf_header=0x7fff435bd900, summary=false) at logstats.cc:1234 #2 0x00449660 in process_file (in_fd=8, offset=0, max_age=0) at logstats.cc:1757 #3 0x0044d031 in main (argv=0x7fff435ce1a8) at logstats.cc:2558 It appears the issue is related to logstats.cc::process_file(), the final read when it will read the contents of the log buffer can return a value less than buffer_bytes; and since header is an aliased pointer of buffer, the contents of header and the subsequent buffers can be invalid data, the solution in my opinion would be to loop until all required data has been read before calling parse_log_buff(). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2822) Crash in LogBufferIterator::next
[ https://issues.apache.org/jira/browse/TS-2822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14004893#comment-14004893 ] ASF subversion and git services commented on TS-2822: - Commit 7c314c5c9bfa347fd583500698c2c586f668f7ea in trafficserver's branch refs/heads/master from [~briang] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=7c314c5 ] [TS-2822] Crash in LogBufferIterator::next Crash in LogBufferIterator::next Key: TS-2822 URL: https://issues.apache.org/jira/browse/TS-2822 Project: Traffic Server Issue Type: Bug Components: Logging Affects Versions: 4.2.1, 5.0.0 Reporter: Brian Geffon Assignee: Brian Geffon It appears there is a crash in traffic_logstats that's consistently happening in LogBufferIterator::next, a sample stack trace is attached. I'll be looking into the issue. #0 0x00465c1d in LogBufferIterator::next (this=0x7fff435bd7b0) at LogBuffer.cc:813 #1 0x00448fd2 in parse_log_buff (buf_header=0x7fff435bd900, summary=false) at logstats.cc:1234 #2 0x00449660 in process_file (in_fd=8, offset=0, max_age=0) at logstats.cc:1757 #3 0x0044d031 in main (argv=0x7fff435ce1a8) at logstats.cc:2558 It appears the issue is related to logstats.cc::process_file(), the final read when it will read the contents of the log buffer can return a value less than buffer_bytes; and since header is an aliased pointer of buffer, the contents of header and the subsequent buffers can be invalid data, the solution in my opinion would be to loop until all required data has been read before calling parse_log_buff(). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (TS-2822) Crash in LogBufferIterator::next
[ https://issues.apache.org/jira/browse/TS-2822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Geffon resolved TS-2822. -- Resolution: Fixed Crash in LogBufferIterator::next Key: TS-2822 URL: https://issues.apache.org/jira/browse/TS-2822 Project: Traffic Server Issue Type: Bug Components: Logging Affects Versions: 4.2.1, 5.0.0 Reporter: Brian Geffon Assignee: Brian Geffon Fix For: 5.0.0 It appears there is a crash in traffic_logstats that's consistently happening in LogBufferIterator::next, a sample stack trace is attached. I'll be looking into the issue. #0 0x00465c1d in LogBufferIterator::next (this=0x7fff435bd7b0) at LogBuffer.cc:813 #1 0x00448fd2 in parse_log_buff (buf_header=0x7fff435bd900, summary=false) at logstats.cc:1234 #2 0x00449660 in process_file (in_fd=8, offset=0, max_age=0) at logstats.cc:1757 #3 0x0044d031 in main (argv=0x7fff435ce1a8) at logstats.cc:2558 It appears the issue is related to logstats.cc::process_file(), the final read when it will read the contents of the log buffer can return a value less than buffer_bytes; and since header is an aliased pointer of buffer, the contents of header and the subsequent buffers can be invalid data, the solution in my opinion would be to loop until all required data has been read before calling parse_log_buff(). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2822) Crash in LogBufferIterator::next
[ https://issues.apache.org/jira/browse/TS-2822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Geffon updated TS-2822: - Backport to Version: 4.2.2 Crash in LogBufferIterator::next Key: TS-2822 URL: https://issues.apache.org/jira/browse/TS-2822 Project: Traffic Server Issue Type: Bug Components: Logging Affects Versions: 4.2.1, 5.0.0 Reporter: Brian Geffon Assignee: Brian Geffon Fix For: 5.0.0 It appears there is a crash in traffic_logstats that's consistently happening in LogBufferIterator::next, a sample stack trace is attached. I'll be looking into the issue. #0 0x00465c1d in LogBufferIterator::next (this=0x7fff435bd7b0) at LogBuffer.cc:813 #1 0x00448fd2 in parse_log_buff (buf_header=0x7fff435bd900, summary=false) at logstats.cc:1234 #2 0x00449660 in process_file (in_fd=8, offset=0, max_age=0) at logstats.cc:1757 #3 0x0044d031 in main (argv=0x7fff435ce1a8) at logstats.cc:2558 It appears the issue is related to logstats.cc::process_file(), the final read when it will read the contents of the log buffer can return a value less than buffer_bytes; and since header is an aliased pointer of buffer, the contents of header and the subsequent buffers can be invalid data, the solution in my opinion would be to loop until all required data has been read before calling parse_log_buff(). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Reopened] (TS-2822) Crash in LogBufferIterator::next
[ https://issues.apache.org/jira/browse/TS-2822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Geffon reopened TS-2822: -- Reopen for backport Crash in LogBufferIterator::next Key: TS-2822 URL: https://issues.apache.org/jira/browse/TS-2822 Project: Traffic Server Issue Type: Bug Components: Logging Affects Versions: 4.2.1, 5.0.0 Reporter: Brian Geffon Assignee: Brian Geffon Fix For: 5.0.0 It appears there is a crash in traffic_logstats that's consistently happening in LogBufferIterator::next, a sample stack trace is attached. I'll be looking into the issue. #0 0x00465c1d in LogBufferIterator::next (this=0x7fff435bd7b0) at LogBuffer.cc:813 #1 0x00448fd2 in parse_log_buff (buf_header=0x7fff435bd900, summary=false) at logstats.cc:1234 #2 0x00449660 in process_file (in_fd=8, offset=0, max_age=0) at logstats.cc:1757 #3 0x0044d031 in main (argv=0x7fff435ce1a8) at logstats.cc:2558 It appears the issue is related to logstats.cc::process_file(), the final read when it will read the contents of the log buffer can return a value less than buffer_bytes; and since header is an aliased pointer of buffer, the contents of header and the subsequent buffers can be invalid data, the solution in my opinion would be to loop until all required data has been read before calling parse_log_buff(). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2822) Crash in LogBufferIterator::next
[ https://issues.apache.org/jira/browse/TS-2822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Geffon updated TS-2822: - Fix Version/s: 5.0.0 Crash in LogBufferIterator::next Key: TS-2822 URL: https://issues.apache.org/jira/browse/TS-2822 Project: Traffic Server Issue Type: Bug Components: Logging Affects Versions: 4.2.1, 5.0.0 Reporter: Brian Geffon Assignee: Brian Geffon Fix For: 5.0.0 It appears there is a crash in traffic_logstats that's consistently happening in LogBufferIterator::next, a sample stack trace is attached. I'll be looking into the issue. #0 0x00465c1d in LogBufferIterator::next (this=0x7fff435bd7b0) at LogBuffer.cc:813 #1 0x00448fd2 in parse_log_buff (buf_header=0x7fff435bd900, summary=false) at logstats.cc:1234 #2 0x00449660 in process_file (in_fd=8, offset=0, max_age=0) at logstats.cc:1757 #3 0x0044d031 in main (argv=0x7fff435ce1a8) at logstats.cc:2558 It appears the issue is related to logstats.cc::process_file(), the final read when it will read the contents of the log buffer can return a value less than buffer_bytes; and since header is an aliased pointer of buffer, the contents of header and the subsequent buffers can be invalid data, the solution in my opinion would be to loop until all required data has been read before calling parse_log_buff(). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2822) Crash in LogBufferIterator::next
[ https://issues.apache.org/jira/browse/TS-2822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14004896#comment-14004896 ] Brian Geffon commented on TS-2822: -- [~psudaemon] can you please include this for backport, it should cleanly apply to 4.2.x. Crash in LogBufferIterator::next Key: TS-2822 URL: https://issues.apache.org/jira/browse/TS-2822 Project: Traffic Server Issue Type: Bug Components: Logging Affects Versions: 4.2.1, 5.0.0 Reporter: Brian Geffon Assignee: Brian Geffon Fix For: 5.0.0 It appears there is a crash in traffic_logstats that's consistently happening in LogBufferIterator::next, a sample stack trace is attached. I'll be looking into the issue. #0 0x00465c1d in LogBufferIterator::next (this=0x7fff435bd7b0) at LogBuffer.cc:813 #1 0x00448fd2 in parse_log_buff (buf_header=0x7fff435bd900, summary=false) at logstats.cc:1234 #2 0x00449660 in process_file (in_fd=8, offset=0, max_age=0) at logstats.cc:1757 #3 0x0044d031 in main (argv=0x7fff435ce1a8) at logstats.cc:2558 It appears the issue is related to logstats.cc::process_file(), the final read when it will read the contents of the log buffer can return a value less than buffer_bytes; and since header is an aliased pointer of buffer, the contents of header and the subsequent buffers can be invalid data, the solution in my opinion would be to loop until all required data has been read before calling parse_log_buff(). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TS-2826) SPDY implementation does not support OPTIONS method
Sudheer Vinukonda created TS-2826:
-
Summary: SPDY implementation does not support OPTIONS method
Key: TS-2826
URL: https://issues.apache.org/jira/browse/TS-2826
Project: Traffic Server
Issue Type: Bug
Components: SPDY
Reporter: Sudheer Vinukonda
SPDY implementation currently only supports the below methods. Need to add
OPTIONS method to it.
{code}
if (req-method == GET)
spdy_fetcher_launch(req, TS_FETCH_METHOD_GET);
else if (req-method == POST)
spdy_fetcher_launch(req, TS_FETCH_METHOD_POST);
else if (req-method == PURGE)
spdy_fetcher_launch(req, TS_FETCH_METHOD_PURGE);
else if (req-method == PUT)
spdy_fetcher_launch(req, TS_FETCH_METHOD_PUT);
else if (req-method == HEAD)
spdy_fetcher_launch(req, TS_FETCH_METHOD_HEAD);
else if (req-method == CONNECT)
spdy_fetcher_launch(req, TS_FETCH_METHOD_CONNECT);
else if (req-method == DELETE)
spdy_fetcher_launch(req, TS_FETCH_METHOD_DELETE);
else if (req-method == LAST)
spdy_fetcher_launch(req, TS_FETCH_METHOD_LAST);
else
spdy_prepare_status_response(sm, req-stream_id, STATUS_405);
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2826) SPDY implementation does not support OPTIONS and TRACE method
[
https://issues.apache.org/jira/browse/TS-2826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda updated TS-2826:
--
Description:
SPDY implementation currently only supports the below methods. Need to add
OPTIONS and TRACE methods to it.
{code}
if (req-method == GET)
spdy_fetcher_launch(req, TS_FETCH_METHOD_GET);
else if (req-method == POST)
spdy_fetcher_launch(req, TS_FETCH_METHOD_POST);
else if (req-method == PURGE)
spdy_fetcher_launch(req, TS_FETCH_METHOD_PURGE);
else if (req-method == PUT)
spdy_fetcher_launch(req, TS_FETCH_METHOD_PUT);
else if (req-method == HEAD)
spdy_fetcher_launch(req, TS_FETCH_METHOD_HEAD);
else if (req-method == CONNECT)
spdy_fetcher_launch(req, TS_FETCH_METHOD_CONNECT);
else if (req-method == DELETE)
spdy_fetcher_launch(req, TS_FETCH_METHOD_DELETE);
else if (req-method == LAST)
spdy_fetcher_launch(req, TS_FETCH_METHOD_LAST);
else
spdy_prepare_status_response(sm, req-stream_id, STATUS_405);
{code}
was:
SPDY implementation currently only supports the below methods. Need to add
OPTIONS method to it.
{code}
if (req-method == GET)
spdy_fetcher_launch(req, TS_FETCH_METHOD_GET);
else if (req-method == POST)
spdy_fetcher_launch(req, TS_FETCH_METHOD_POST);
else if (req-method == PURGE)
spdy_fetcher_launch(req, TS_FETCH_METHOD_PURGE);
else if (req-method == PUT)
spdy_fetcher_launch(req, TS_FETCH_METHOD_PUT);
else if (req-method == HEAD)
spdy_fetcher_launch(req, TS_FETCH_METHOD_HEAD);
else if (req-method == CONNECT)
spdy_fetcher_launch(req, TS_FETCH_METHOD_CONNECT);
else if (req-method == DELETE)
spdy_fetcher_launch(req, TS_FETCH_METHOD_DELETE);
else if (req-method == LAST)
spdy_fetcher_launch(req, TS_FETCH_METHOD_LAST);
else
spdy_prepare_status_response(sm, req-stream_id, STATUS_405);
{code}
SPDY implementation does not support OPTIONS and TRACE method
-
Key: TS-2826
URL: https://issues.apache.org/jira/browse/TS-2826
Project: Traffic Server
Issue Type: Bug
Components: SPDY
Reporter: Sudheer Vinukonda
SPDY implementation currently only supports the below methods. Need to add
OPTIONS and TRACE methods to it.
{code}
if (req-method == GET)
spdy_fetcher_launch(req, TS_FETCH_METHOD_GET);
else if (req-method == POST)
spdy_fetcher_launch(req, TS_FETCH_METHOD_POST);
else if (req-method == PURGE)
spdy_fetcher_launch(req, TS_FETCH_METHOD_PURGE);
else if (req-method == PUT)
spdy_fetcher_launch(req, TS_FETCH_METHOD_PUT);
else if (req-method == HEAD)
spdy_fetcher_launch(req, TS_FETCH_METHOD_HEAD);
else if (req-method == CONNECT)
spdy_fetcher_launch(req, TS_FETCH_METHOD_CONNECT);
else if (req-method == DELETE)
spdy_fetcher_launch(req, TS_FETCH_METHOD_DELETE);
else if (req-method == LAST)
spdy_fetcher_launch(req, TS_FETCH_METHOD_LAST);
else
spdy_prepare_status_response(sm, req-stream_id, STATUS_405);
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2826) SPDY implementation does not support OPTIONS and TRACE method
[
https://issues.apache.org/jira/browse/TS-2826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda updated TS-2826:
--
Summary: SPDY implementation does not support OPTIONS and TRACE method
(was: SPDY implementation does not support OPTIONS method)
SPDY implementation does not support OPTIONS and TRACE method
-
Key: TS-2826
URL: https://issues.apache.org/jira/browse/TS-2826
Project: Traffic Server
Issue Type: Bug
Components: SPDY
Reporter: Sudheer Vinukonda
SPDY implementation currently only supports the below methods. Need to add
OPTIONS method to it.
{code}
if (req-method == GET)
spdy_fetcher_launch(req, TS_FETCH_METHOD_GET);
else if (req-method == POST)
spdy_fetcher_launch(req, TS_FETCH_METHOD_POST);
else if (req-method == PURGE)
spdy_fetcher_launch(req, TS_FETCH_METHOD_PURGE);
else if (req-method == PUT)
spdy_fetcher_launch(req, TS_FETCH_METHOD_PUT);
else if (req-method == HEAD)
spdy_fetcher_launch(req, TS_FETCH_METHOD_HEAD);
else if (req-method == CONNECT)
spdy_fetcher_launch(req, TS_FETCH_METHOD_CONNECT);
else if (req-method == DELETE)
spdy_fetcher_launch(req, TS_FETCH_METHOD_DELETE);
else if (req-method == LAST)
spdy_fetcher_launch(req, TS_FETCH_METHOD_LAST);
else
spdy_prepare_status_response(sm, req-stream_id, STATUS_405);
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2826) SPDY implementation does not support OPTIONS and TRACE methods
[
https://issues.apache.org/jira/browse/TS-2826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda updated TS-2826:
--
Summary: SPDY implementation does not support OPTIONS and TRACE methods
(was: SPDY implementation does not support OPTIONS and TRACE method)
SPDY implementation does not support OPTIONS and TRACE methods
--
Key: TS-2826
URL: https://issues.apache.org/jira/browse/TS-2826
Project: Traffic Server
Issue Type: Bug
Components: SPDY
Reporter: Sudheer Vinukonda
SPDY implementation currently only supports the below methods. Need to add
OPTIONS and TRACE methods to it.
{code}
if (req-method == GET)
spdy_fetcher_launch(req, TS_FETCH_METHOD_GET);
else if (req-method == POST)
spdy_fetcher_launch(req, TS_FETCH_METHOD_POST);
else if (req-method == PURGE)
spdy_fetcher_launch(req, TS_FETCH_METHOD_PURGE);
else if (req-method == PUT)
spdy_fetcher_launch(req, TS_FETCH_METHOD_PUT);
else if (req-method == HEAD)
spdy_fetcher_launch(req, TS_FETCH_METHOD_HEAD);
else if (req-method == CONNECT)
spdy_fetcher_launch(req, TS_FETCH_METHOD_CONNECT);
else if (req-method == DELETE)
spdy_fetcher_launch(req, TS_FETCH_METHOD_DELETE);
else if (req-method == LAST)
spdy_fetcher_launch(req, TS_FETCH_METHOD_LAST);
else
spdy_prepare_status_response(sm, req-stream_id, STATUS_405);
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2826) SPDY implementation does not support OPTIONS and TRACE methods
[
https://issues.apache.org/jira/browse/TS-2826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda updated TS-2826:
--
Attachment: ts2826.diff
SPDY implementation does not support OPTIONS and TRACE methods
--
Key: TS-2826
URL: https://issues.apache.org/jira/browse/TS-2826
Project: Traffic Server
Issue Type: Bug
Components: SPDY
Reporter: Sudheer Vinukonda
Attachments: ts2826.diff
SPDY implementation currently only supports the below methods. Need to add
OPTIONS and TRACE methods to it.
{code}
if (req-method == GET)
spdy_fetcher_launch(req, TS_FETCH_METHOD_GET);
else if (req-method == POST)
spdy_fetcher_launch(req, TS_FETCH_METHOD_POST);
else if (req-method == PURGE)
spdy_fetcher_launch(req, TS_FETCH_METHOD_PURGE);
else if (req-method == PUT)
spdy_fetcher_launch(req, TS_FETCH_METHOD_PUT);
else if (req-method == HEAD)
spdy_fetcher_launch(req, TS_FETCH_METHOD_HEAD);
else if (req-method == CONNECT)
spdy_fetcher_launch(req, TS_FETCH_METHOD_CONNECT);
else if (req-method == DELETE)
spdy_fetcher_launch(req, TS_FETCH_METHOD_DELETE);
else if (req-method == LAST)
spdy_fetcher_launch(req, TS_FETCH_METHOD_LAST);
else
spdy_prepare_status_response(sm, req-stream_id, STATUS_405);
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2822) Crash in LogBufferIterator::next
[ https://issues.apache.org/jira/browse/TS-2822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14004994#comment-14004994 ] ASF subversion and git services commented on TS-2822: - Commit 8fc92c4c831e73831aed4e091bd0cb2cfd48725d in trafficserver's branch refs/heads/master from [~briang] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=8fc92c4 ] Revert [TS-2822] Crash in LogBufferIterator::next This reverts commit 7c314c5c9bfa347fd583500698c2c586f668f7ea. Crash in LogBufferIterator::next Key: TS-2822 URL: https://issues.apache.org/jira/browse/TS-2822 Project: Traffic Server Issue Type: Bug Components: Logging Affects Versions: 4.2.1, 5.0.0 Reporter: Brian Geffon Assignee: Brian Geffon Fix For: 5.0.0 It appears there is a crash in traffic_logstats that's consistently happening in LogBufferIterator::next, a sample stack trace is attached. I'll be looking into the issue. #0 0x00465c1d in LogBufferIterator::next (this=0x7fff435bd7b0) at LogBuffer.cc:813 #1 0x00448fd2 in parse_log_buff (buf_header=0x7fff435bd900, summary=false) at logstats.cc:1234 #2 0x00449660 in process_file (in_fd=8, offset=0, max_age=0) at logstats.cc:1757 #3 0x0044d031 in main (argv=0x7fff435ce1a8) at logstats.cc:2558 It appears the issue is related to logstats.cc::process_file(), the final read when it will read the contents of the log buffer can return a value less than buffer_bytes; and since header is an aliased pointer of buffer, the contents of header and the subsequent buffers can be invalid data, the solution in my opinion would be to loop until all required data has been read before calling parse_log_buff(). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2826) SPDY implementation does not support OPTIONS and TRACE methods
[
https://issues.apache.org/jira/browse/TS-2826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda updated TS-2826:
--
Labels: SPDY yahoo (was: )
SPDY implementation does not support OPTIONS and TRACE methods
--
Key: TS-2826
URL: https://issues.apache.org/jira/browse/TS-2826
Project: Traffic Server
Issue Type: Bug
Components: SPDY
Reporter: Sudheer Vinukonda
Labels: SPDY, yahoo
Attachments: ts2826.diff
SPDY implementation currently only supports the below methods. Need to add
OPTIONS and TRACE methods to it.
{code}
if (req-method == GET)
spdy_fetcher_launch(req, TS_FETCH_METHOD_GET);
else if (req-method == POST)
spdy_fetcher_launch(req, TS_FETCH_METHOD_POST);
else if (req-method == PURGE)
spdy_fetcher_launch(req, TS_FETCH_METHOD_PURGE);
else if (req-method == PUT)
spdy_fetcher_launch(req, TS_FETCH_METHOD_PUT);
else if (req-method == HEAD)
spdy_fetcher_launch(req, TS_FETCH_METHOD_HEAD);
else if (req-method == CONNECT)
spdy_fetcher_launch(req, TS_FETCH_METHOD_CONNECT);
else if (req-method == DELETE)
spdy_fetcher_launch(req, TS_FETCH_METHOD_DELETE);
else if (req-method == LAST)
spdy_fetcher_launch(req, TS_FETCH_METHOD_LAST);
else
spdy_prepare_status_response(sm, req-stream_id, STATUS_405);
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2822) Crash in LogBufferIterator::next
[ https://issues.apache.org/jira/browse/TS-2822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14004998#comment-14004998 ] ASF subversion and git services commented on TS-2822: - Commit 13453d9ab8c975fd12da632a49868eeaf2eb1fd3 in trafficserver's branch refs/heads/master from [~briang] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=13453d9 ] [TS-2822] Crash in LogBufferIterator::next Crash in LogBufferIterator::next Key: TS-2822 URL: https://issues.apache.org/jira/browse/TS-2822 Project: Traffic Server Issue Type: Bug Components: Logging Affects Versions: 4.2.1, 5.0.0 Reporter: Brian Geffon Assignee: Brian Geffon Fix For: 5.0.0 It appears there is a crash in traffic_logstats that's consistently happening in LogBufferIterator::next, a sample stack trace is attached. I'll be looking into the issue. #0 0x00465c1d in LogBufferIterator::next (this=0x7fff435bd7b0) at LogBuffer.cc:813 #1 0x00448fd2 in parse_log_buff (buf_header=0x7fff435bd900, summary=false) at logstats.cc:1234 #2 0x00449660 in process_file (in_fd=8, offset=0, max_age=0) at logstats.cc:1757 #3 0x0044d031 in main (argv=0x7fff435ce1a8) at logstats.cc:2558 It appears the issue is related to logstats.cc::process_file(), the final read when it will read the contents of the log buffer can return a value less than buffer_bytes; and since header is an aliased pointer of buffer, the contents of header and the subsequent buffers can be invalid data, the solution in my opinion would be to loop until all required data has been read before calling parse_log_buff(). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2822) Crash in LogBufferIterator::next
[ https://issues.apache.org/jira/browse/TS-2822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14005000#comment-14005000 ] Brian Geffon commented on TS-2822: -- [~psudaemon], Please use commit 13453d9ab8c975fd12da632a49868eeaf2eb1fd3 for backport. Thanks! Crash in LogBufferIterator::next Key: TS-2822 URL: https://issues.apache.org/jira/browse/TS-2822 Project: Traffic Server Issue Type: Bug Components: Logging Affects Versions: 4.2.1, 5.0.0 Reporter: Brian Geffon Assignee: Brian Geffon Fix For: 5.0.0 It appears there is a crash in traffic_logstats that's consistently happening in LogBufferIterator::next, a sample stack trace is attached. I'll be looking into the issue. #0 0x00465c1d in LogBufferIterator::next (this=0x7fff435bd7b0) at LogBuffer.cc:813 #1 0x00448fd2 in parse_log_buff (buf_header=0x7fff435bd900, summary=false) at logstats.cc:1234 #2 0x00449660 in process_file (in_fd=8, offset=0, max_age=0) at logstats.cc:1757 #3 0x0044d031 in main (argv=0x7fff435ce1a8) at logstats.cc:2558 It appears the issue is related to logstats.cc::process_file(), the final read when it will read the contents of the log buffer can return a value less than buffer_bytes; and since header is an aliased pointer of buffer, the contents of header and the subsequent buffers can be invalid data, the solution in my opinion would be to loop until all required data has been read before calling parse_log_buff(). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2822) Crash in LogBufferIterator::next
[ https://issues.apache.org/jira/browse/TS-2822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14005046#comment-14005046 ] Brian Geffon commented on TS-2822: -- Please also include 883a3d2c8f31ed4b7b004cb980a7307f88b760cb, sorry for the confusion! Crash in LogBufferIterator::next Key: TS-2822 URL: https://issues.apache.org/jira/browse/TS-2822 Project: Traffic Server Issue Type: Bug Components: Logging Affects Versions: 4.2.1, 5.0.0 Reporter: Brian Geffon Assignee: Brian Geffon Fix For: 5.0.0 It appears there is a crash in traffic_logstats that's consistently happening in LogBufferIterator::next, a sample stack trace is attached. I'll be looking into the issue. #0 0x00465c1d in LogBufferIterator::next (this=0x7fff435bd7b0) at LogBuffer.cc:813 #1 0x00448fd2 in parse_log_buff (buf_header=0x7fff435bd900, summary=false) at logstats.cc:1234 #2 0x00449660 in process_file (in_fd=8, offset=0, max_age=0) at logstats.cc:1757 #3 0x0044d031 in main (argv=0x7fff435ce1a8) at logstats.cc:2558 It appears the issue is related to logstats.cc::process_file(), the final read when it will read the contents of the log buffer can return a value less than buffer_bytes; and since header is an aliased pointer of buffer, the contents of header and the subsequent buffers can be invalid data, the solution in my opinion would be to loop until all required data has been read before calling parse_log_buff(). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2822) Crash in LogBufferIterator::next
[ https://issues.apache.org/jira/browse/TS-2822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14005040#comment-14005040 ] ASF subversion and git services commented on TS-2822: - Commit 883a3d2c8f31ed4b7b004cb980a7307f88b760cb in trafficserver's branch refs/heads/master from [~briang] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=883a3d2 ] [TS-2822] Adding check for zero length reads Crash in LogBufferIterator::next Key: TS-2822 URL: https://issues.apache.org/jira/browse/TS-2822 Project: Traffic Server Issue Type: Bug Components: Logging Affects Versions: 4.2.1, 5.0.0 Reporter: Brian Geffon Assignee: Brian Geffon Fix For: 5.0.0 It appears there is a crash in traffic_logstats that's consistently happening in LogBufferIterator::next, a sample stack trace is attached. I'll be looking into the issue. #0 0x00465c1d in LogBufferIterator::next (this=0x7fff435bd7b0) at LogBuffer.cc:813 #1 0x00448fd2 in parse_log_buff (buf_header=0x7fff435bd900, summary=false) at logstats.cc:1234 #2 0x00449660 in process_file (in_fd=8, offset=0, max_age=0) at logstats.cc:1757 #3 0x0044d031 in main (argv=0x7fff435ce1a8) at logstats.cc:2558 It appears the issue is related to logstats.cc::process_file(), the final read when it will read the contents of the log buffer can return a value less than buffer_bytes; and since header is an aliased pointer of buffer, the contents of header and the subsequent buffers can be invalid data, the solution in my opinion would be to loop until all required data has been read before calling parse_log_buff(). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2274) Better initial default configs
[ https://issues.apache.org/jira/browse/TS-2274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14005060#comment-14005060 ] Leif Hedstrom commented on TS-2274: --- From the Hangout: * Change connect_ports to 443 only * Change boolean records to be BOOL instead of INT * Document send_http11_requests * Share server sessions has changed - update release notes and docs. /amc * Enable background fill by default - file a jira for enabling that * Carlin to come up with defaults for reconnects * push_method_enabled, why oh why ? * ignore_client_cc_max_age should be turned on * normalize_ae_gzip on * Should we make permit.pinning enabled by default ? * Enable read-while-writer * Round_robin_nameservers should be on by default. * Increase HostDB size 128MB and size * Enable custom logs by default * Look at eliminating reverse_proxy.enabled * Return pristine_host_hdr back to 0 * Change default cypher suite * Turn on honor_cipher_order by default * Change streams to 100 for SPDY * Does update not work ? * Set sock_send_buffer_size_in to zero as default * proxy.config.diags.show_location set to on * File a ticket on auto-sizing task threads * Chunking size into records.config and/or tweak the deafults (pester AMC) * David Carlin11:39 AM Can we add this: proxy.config.net.default_inactivity_timeout http://docs.trafficserver.apache.org/en/latest/reference/configuration/records.config.en.html?highlight=proxy.config.http.cache.cache_urls_that_look_dynamic#proxy.config.http.cache.cache_urls_that_look_dynamic docs are broken Leif: add it to RTD or to this google doc I can't edit the google doc for some reason BTW I think the defaults for these should change, I dislike how the msgs go to diags.log AND /var/log/messages: CONFIG proxy.config.diags.output.error STRING L CONFIG proxy.config.diags.output.fatal STRING L CONFIG proxy.config.diags.output.emergency STRING L Better initial default configs -- Key: TS-2274 URL: https://issues.apache.org/jira/browse/TS-2274 Project: Traffic Server Issue Type: Bug Components: Configuration Reporter: Miles Libbey Fix For: 5.0.0 Seems like there are several config values that are not very smart for the newbie user: - cache size: storage.config: var/trafficserver 256M - max object size (though, perhaps this is now unlimited) - read-while-write settings? - 4-5 volumes for the volume config? - CONFIG proxy.config.cache.ram_cache_cutoff INT 4194304 ? Adam Dace in https://cwiki.apache.org/confluence/display/TS/WebProxyCacheSetup suggested several others, but, it looks to me like the settings are very machine specific (eg, specific IP addresses) Others? -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (TS-2274) Better initial default configs
[ https://issues.apache.org/jira/browse/TS-2274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-2274: - Assignee: Leif Hedstrom Better initial default configs -- Key: TS-2274 URL: https://issues.apache.org/jira/browse/TS-2274 Project: Traffic Server Issue Type: Bug Components: Configuration Reporter: Miles Libbey Assignee: Leif Hedstrom Fix For: 5.0.0 Seems like there are several config values that are not very smart for the newbie user: - cache size: storage.config: var/trafficserver 256M - max object size (though, perhaps this is now unlimited) - read-while-write settings? - 4-5 volumes for the volume config? - CONFIG proxy.config.cache.ram_cache_cutoff INT 4194304 ? Adam Dace in https://cwiki.apache.org/confluence/display/TS/WebProxyCacheSetup suggested several others, but, it looks to me like the settings are very machine specific (eg, specific IP addresses) Others? -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2779) atscppapi: bug in AsyncTimer - cancel results in crash
[ https://issues.apache.org/jira/browse/TS-2779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14005100#comment-14005100 ] ASF GitHub Bot commented on TS-2779: Github user asfgit closed the pull request at: https://github.com/apache/trafficserver/pull/77 atscppapi: bug in AsyncTimer - cancel results in crash -- Key: TS-2779 URL: https://issues.apache.org/jira/browse/TS-2779 Project: Traffic Server Issue Type: Bug Components: CPP API Reporter: Manjesh Nilange Assignee: Brian Geffon Fix For: 5.0.0 FATAL: InkIOCoreAPI.cc:223: failed assert `sdk_sanity_check_mutex(mutexp) == TS_SUCCESS` /usr/bin/traffic_server - STACK TRACE: /usr/lib64/libtsutil.so.3(ink_fatal+0xc9)[0x77bb2c05] /usr/lib64/libtsutil.so.3(_ink_assert+0x3c)[0x77bb1c48] /usr/bin/traffic_server(_TSReleaseAssert+0x29)[0x4f41a7] /usr/bin/traffic_server(TSMutexLock+0x30)[0x50dcc1] /usr/lib/libatscppapi.so.1(_ZN9atscppapi10AsyncTimer6cancelEv+0x27)[0x7fffe9ae26b9] /usr/lib/libatscppapi.so.1(_ZN9atscppapi10AsyncTimerD1Ev+0x2d)[0x7fffe9ae27a3] /usr/lib/libatscppapi.so.1(_ZN9atscppapi10AsyncTimerD0Ev+0x18)[0x7fffe9ae2824] /home/mnilange/Projects/postbuffer/postbuffer.so(_ZN10PostBufferD1Ev+0x98)[0x7fffe9d14346] /home/mnilange/Projects/postbuffer/postbuffer.so(_ZN10PostBufferD0Ev+0x18)[0x7fffe9d144b6] /usr/lib/libatscppapi.so.1(+0x1ceca)[0x7fffe9ad1eca] -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2779) atscppapi: bug in AsyncTimer - cancel results in crash
[ https://issues.apache.org/jira/browse/TS-2779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14005097#comment-14005097 ] ASF subversion and git services commented on TS-2779: - Commit 92ad666f9e7d102c549aa381620cfed89fc9ec57 in trafficserver's branch refs/heads/master from [~manjesh] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=92ad666 ] fix for TS-2779 (atscppapi: bug in AsyncTimer - cancel results in crash); This closes #77 atscppapi: bug in AsyncTimer - cancel results in crash -- Key: TS-2779 URL: https://issues.apache.org/jira/browse/TS-2779 Project: Traffic Server Issue Type: Bug Components: CPP API Reporter: Manjesh Nilange Assignee: Brian Geffon Fix For: 5.0.0 FATAL: InkIOCoreAPI.cc:223: failed assert `sdk_sanity_check_mutex(mutexp) == TS_SUCCESS` /usr/bin/traffic_server - STACK TRACE: /usr/lib64/libtsutil.so.3(ink_fatal+0xc9)[0x77bb2c05] /usr/lib64/libtsutil.so.3(_ink_assert+0x3c)[0x77bb1c48] /usr/bin/traffic_server(_TSReleaseAssert+0x29)[0x4f41a7] /usr/bin/traffic_server(TSMutexLock+0x30)[0x50dcc1] /usr/lib/libatscppapi.so.1(_ZN9atscppapi10AsyncTimer6cancelEv+0x27)[0x7fffe9ae26b9] /usr/lib/libatscppapi.so.1(_ZN9atscppapi10AsyncTimerD1Ev+0x2d)[0x7fffe9ae27a3] /usr/lib/libatscppapi.so.1(_ZN9atscppapi10AsyncTimerD0Ev+0x18)[0x7fffe9ae2824] /home/mnilange/Projects/postbuffer/postbuffer.so(_ZN10PostBufferD1Ev+0x98)[0x7fffe9d14346] /home/mnilange/Projects/postbuffer/postbuffer.so(_ZN10PostBufferD0Ev+0x18)[0x7fffe9d144b6] /usr/lib/libatscppapi.so.1(+0x1ceca)[0x7fffe9ad1eca] -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2822) Crash in LogBufferIterator::next
[ https://issues.apache.org/jira/browse/TS-2822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14005098#comment-14005098 ] ASF subversion and git services commented on TS-2822: - Commit 088d5fe08c85d60aa782de6c110d08f643ad2071 in trafficserver's branch refs/heads/master from [~briang] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=088d5fe ] [TS-2822] Adding check for zero length reads Crash in LogBufferIterator::next Key: TS-2822 URL: https://issues.apache.org/jira/browse/TS-2822 Project: Traffic Server Issue Type: Bug Components: Logging Affects Versions: 4.2.1, 5.0.0 Reporter: Brian Geffon Assignee: Brian Geffon Fix For: 5.0.0 It appears there is a crash in traffic_logstats that's consistently happening in LogBufferIterator::next, a sample stack trace is attached. I'll be looking into the issue. #0 0x00465c1d in LogBufferIterator::next (this=0x7fff435bd7b0) at LogBuffer.cc:813 #1 0x00448fd2 in parse_log_buff (buf_header=0x7fff435bd900, summary=false) at logstats.cc:1234 #2 0x00449660 in process_file (in_fd=8, offset=0, max_age=0) at logstats.cc:1757 #3 0x0044d031 in main (argv=0x7fff435ce1a8) at logstats.cc:2558 It appears the issue is related to logstats.cc::process_file(), the final read when it will read the contents of the log buffer can return a value less than buffer_bytes; and since header is an aliased pointer of buffer, the contents of header and the subsequent buffers can be invalid data, the solution in my opinion would be to loop until all required data has been read before calling parse_log_buff(). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2632) Range request will always lock object in cache, even thought it's rarely cacheable
[ https://issues.apache.org/jira/browse/TS-2632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14005175#comment-14005175 ] ASF subversion and git services commented on TS-2632: - Commit 88fc99a47ef551e08c2dea1491016e89fd013324 in trafficserver's branch refs/heads/master from [~zwoop] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=88fc99a ] TS-2632 Do not lock the object in cache (by default) on Range requests Range request will always lock object in cache, even thought it's rarely cacheable -- Key: TS-2632 URL: https://issues.apache.org/jira/browse/TS-2632 Project: Traffic Server Issue Type: Bug Components: Cache, HTTP Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 5.0.0 Attachments: range.diff Right now, if a client sends a Range: request, we still lock the URL in the cache, under the assumption that it will be written to. Since we don't support partial objects, in almost all cases, we'll not write the object and therefore release the object. I suggest we change this such that we never try to write lock a URL in the presence of a Range: header in the client request. This will allow other requests to go to origin faster, and better yet, it allows a request without a Range: header to properly lock the URL for writing. This turns out to be important for implementing e.g. background filling as a plugin. There is one use case where this might be useful; If the origin does not respond with a 206 (partial object), we can now cache the full object. However, this is a pretty rare case, and for someone to support this, all you have to do is to remove the Range: header on the request. I'm opening up this bug right now for discussion, if anyone have any concerns about this change, please let me know. It is an incompatible change, without configuration options, but that should be ok for the v5.0.0 release. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2632) Range request will always lock object in cache, even thought it's rarely cacheable
[ https://issues.apache.org/jira/browse/TS-2632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14005177#comment-14005177 ] ASF subversion and git services commented on TS-2632: - Commit 2a0ef8a0e53036730ec94008bb29c9e115163956 in trafficserver's branch refs/heads/master from [~zwoop] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=2a0ef8a ] Added TS-2632. Range request will always lock object in cache, even thought it's rarely cacheable -- Key: TS-2632 URL: https://issues.apache.org/jira/browse/TS-2632 Project: Traffic Server Issue Type: Bug Components: Cache, HTTP Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 5.0.0 Attachments: range.diff Right now, if a client sends a Range: request, we still lock the URL in the cache, under the assumption that it will be written to. Since we don't support partial objects, in almost all cases, we'll not write the object and therefore release the object. I suggest we change this such that we never try to write lock a URL in the presence of a Range: header in the client request. This will allow other requests to go to origin faster, and better yet, it allows a request without a Range: header to properly lock the URL for writing. This turns out to be important for implementing e.g. background filling as a plugin. There is one use case where this might be useful; If the origin does not respond with a 206 (partial object), we can now cache the full object. However, this is a pretty rare case, and for someone to support this, all you have to do is to remove the Range: header on the request. I'm opening up this bug right now for discussion, if anyone have any concerns about this change, please let me know. It is an incompatible change, without configuration options, but that should be ok for the v5.0.0 release. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2824) ioBufferAllocator objects in ATS master keep growing endlessly
[
https://issues.apache.org/jira/browse/TS-2824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14005240#comment-14005240
]
ASF subversion and git services commented on TS-2824:
-
Commit 9a435de7e1bd400d5b4f333514a73004427cdc9c in trafficserver's branch
refs/heads/master from [~psudaemon]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=9a435de ]
TS-2824: Revert TS-2592 (2fbd4b6)
ioBufferAllocator objects in ATS master keep growing endlessly
--
Key: TS-2824
URL: https://issues.apache.org/jira/browse/TS-2824
Project: Traffic Server
Issue Type: Bug
Components: Core
Reporter: Sudheer Vinukonda
During our production testing of ATS master, I noticed that ATS memory keeps
growing beyond ram cache size limits. Upon enabling the memory allocation
dump, it looks like the ioBufAllocator objects keep growing endlessly.
Talking to [~psudaemon] and [~amc] on irc, it looks like the issue might be
caused due to NOT in-use proxy allocator (local thread) objects accumulating
until they reach the per thread object count limit (250). This may be
significant memory for large sized objects (e.g 1MB or 2MB). [~psudaemon]
recommended to try reverting the changes in TS-2592 that force to use Proxy
allocator instead of global pool objects for ioBuffers. (Note that my
production host has ram cache set to 6G and that is completely used, but, the
ioBuffers just keep growing)
Here's the dump of memory allocations:
{code}
-bash-4.1$ sudo grep ioBufAllocator\[13\] traffic.out
0 | 0 |1048576 |
memory/ioBufAllocator[13]
1174405120 | 1151336448 |1048576 |
memory/ioBufAllocator[13]
4194304000 | 4186963968 |1048576 |
memory/ioBufAllocator[13]
1912602624 | 1908408320 |1048576 |
memory/ioBufAllocator[13]
771751936 | 759169024 |1048576 |
memory/ioBufAllocator[13]
1610612736 | 1608515584 |1048576 |
memory/ioBufAllocator[13]
1509949440 | 1484783616 |1048576 |
memory/ioBufAllocator[13]
3724541952 | 3697278976 |1048576 |
memory/ioBufAllocator[13]
2046820352 | 2023751680 |1048576 |
memory/ioBufAllocator[13]
2046820352 | 2036334592 |1048576 |
memory/ioBufAllocator[13]
2147483648 | 2128609280 |1048576 |
memory/ioBufAllocator[13]
2181038080 | 2172649472 |1048576 |
memory/ioBufAllocator[13]
2214592512 | 2204106752 |1048576 |
memory/ioBufAllocator[13]
2281701376 | 2253389824 |1048576 |
memory/ioBufAllocator[13]
2315255808 | 2287992832 |1048576 |
memory/ioBufAllocator[13]
2348810240 | 2316304384 |1048576 |
memory/ioBufAllocator[13]
2348810240 | 2336227328 |1048576 |
memory/ioBufAllocator[13]
2382364672 | 2380267520 |1048576 |
memory/ioBufAllocator[13]
2449473536 | 2424307712 |1048576 |
memory/ioBufAllocator[13]
2449473536 | 2447376384 |1048576 |
memory/ioBufAllocator[13]
2483027968 | 2474639360 |1048576 |
memory/ioBufAllocator[13]
2516582400 | 2507145216 |1048576 |
memory/ioBufAllocator[13]
2550136832 | 2543845376 |1048576 |
memory/ioBufAllocator[13]
2617245696 | 2599419904 |1048576 |
memory/ioBufAllocator[13]
2650800128 | 2626682880 |1048576 |
memory/ioBufAllocator[13]
2684354560 | 2659188736 |1048576 |
memory/ioBufAllocator[13]
2684354560 | 2675965952 |1048576 |
memory/ioBufAllocator[13]
2717908992 | 2690646016 |1048576 |
memory/ioBufAllocator[13]
2717908992 | 2713714688 |1048576 |
memory/ioBufAllocator[13]
2785017856 | 2758803456 |1048576 |
memory/ioBufAllocator[13]
2818572288 | 2792357888 |1048576 |
memory/ioBufAllocator[13]
2852126720 | 2823815168 |1048576 |
memory/ioBufAllocator[13]
2885681152 | 2882535424 |1048576 |
memory/ioBufAllocator[13]
2952790016 | 2921332736 |1048576 |
memory/ioBufAllocator[13]
298638 | 2959081472 |1048576 |
memory/ioBufAllocator[13]
298638 | 2985295872 |1048576 |
memory/ioBufAllocator[13]
3019898880 | 3014656000 |1048576 |
memory/ioBufAllocator[13]
3087007744 | 3067084800 |1048576 |
memory/ioBufAllocator[13]
[jira] [Commented] (TS-2592) ioBufAllocator not using proxyAllocator
[ https://issues.apache.org/jira/browse/TS-2592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14005241#comment-14005241 ] ASF subversion and git services commented on TS-2592: - Commit 9a435de7e1bd400d5b4f333514a73004427cdc9c in trafficserver's branch refs/heads/master from [~psudaemon] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=9a435de ] TS-2824: Revert TS-2592 (2fbd4b6) ioBufAllocator not using proxyAllocator --- Key: TS-2592 URL: https://issues.apache.org/jira/browse/TS-2592 Project: Traffic Server Issue Type: Improvement Reporter: Phil Sorber Assignee: Phil Sorber Priority: Trivial Fix For: 5.0.0 There is a proxyAllocator for ioBufAllocator but it is not actually in use. I was not able to find anything in the git history where it was taken out of use, so assuming this was overlooked. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (TS-2824) ioBufferAllocator objects in ATS master keep growing endlessly
[
https://issues.apache.org/jira/browse/TS-2824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Sorber resolved TS-2824.
-
Resolution: Fixed
Fix Version/s: 5.0.0
Assignee: Phil Sorber
Fixed this by reverting TS-2592 (2fbd4b6)
ioBufferAllocator objects in ATS master keep growing endlessly
--
Key: TS-2824
URL: https://issues.apache.org/jira/browse/TS-2824
Project: Traffic Server
Issue Type: Bug
Components: Core
Reporter: Sudheer Vinukonda
Assignee: Phil Sorber
Fix For: 5.0.0
During our production testing of ATS master, I noticed that ATS memory keeps
growing beyond ram cache size limits. Upon enabling the memory allocation
dump, it looks like the ioBufAllocator objects keep growing endlessly.
Talking to [~psudaemon] and [~amc] on irc, it looks like the issue might be
caused due to NOT in-use proxy allocator (local thread) objects accumulating
until they reach the per thread object count limit (250). This may be
significant memory for large sized objects (e.g 1MB or 2MB). [~psudaemon]
recommended to try reverting the changes in TS-2592 that force to use Proxy
allocator instead of global pool objects for ioBuffers. (Note that my
production host has ram cache set to 6G and that is completely used, but, the
ioBuffers just keep growing)
Here's the dump of memory allocations:
{code}
-bash-4.1$ sudo grep ioBufAllocator\[13\] traffic.out
0 | 0 |1048576 |
memory/ioBufAllocator[13]
1174405120 | 1151336448 |1048576 |
memory/ioBufAllocator[13]
4194304000 | 4186963968 |1048576 |
memory/ioBufAllocator[13]
1912602624 | 1908408320 |1048576 |
memory/ioBufAllocator[13]
771751936 | 759169024 |1048576 |
memory/ioBufAllocator[13]
1610612736 | 1608515584 |1048576 |
memory/ioBufAllocator[13]
1509949440 | 1484783616 |1048576 |
memory/ioBufAllocator[13]
3724541952 | 3697278976 |1048576 |
memory/ioBufAllocator[13]
2046820352 | 2023751680 |1048576 |
memory/ioBufAllocator[13]
2046820352 | 2036334592 |1048576 |
memory/ioBufAllocator[13]
2147483648 | 2128609280 |1048576 |
memory/ioBufAllocator[13]
2181038080 | 2172649472 |1048576 |
memory/ioBufAllocator[13]
2214592512 | 2204106752 |1048576 |
memory/ioBufAllocator[13]
2281701376 | 2253389824 |1048576 |
memory/ioBufAllocator[13]
2315255808 | 2287992832 |1048576 |
memory/ioBufAllocator[13]
2348810240 | 2316304384 |1048576 |
memory/ioBufAllocator[13]
2348810240 | 2336227328 |1048576 |
memory/ioBufAllocator[13]
2382364672 | 2380267520 |1048576 |
memory/ioBufAllocator[13]
2449473536 | 2424307712 |1048576 |
memory/ioBufAllocator[13]
2449473536 | 2447376384 |1048576 |
memory/ioBufAllocator[13]
2483027968 | 2474639360 |1048576 |
memory/ioBufAllocator[13]
2516582400 | 2507145216 |1048576 |
memory/ioBufAllocator[13]
2550136832 | 2543845376 |1048576 |
memory/ioBufAllocator[13]
2617245696 | 2599419904 |1048576 |
memory/ioBufAllocator[13]
2650800128 | 2626682880 |1048576 |
memory/ioBufAllocator[13]
2684354560 | 2659188736 |1048576 |
memory/ioBufAllocator[13]
2684354560 | 2675965952 |1048576 |
memory/ioBufAllocator[13]
2717908992 | 2690646016 |1048576 |
memory/ioBufAllocator[13]
2717908992 | 2713714688 |1048576 |
memory/ioBufAllocator[13]
2785017856 | 2758803456 |1048576 |
memory/ioBufAllocator[13]
2818572288 | 2792357888 |1048576 |
memory/ioBufAllocator[13]
2852126720 | 2823815168 |1048576 |
memory/ioBufAllocator[13]
2885681152 | 2882535424 |1048576 |
memory/ioBufAllocator[13]
2952790016 | 2921332736 |1048576 |
memory/ioBufAllocator[13]
298638 | 2959081472 |1048576 |
memory/ioBufAllocator[13]
298638 | 2985295872 |1048576 |
memory/ioBufAllocator[13]
3019898880 | 3014656000 |1048576 |
memory/ioBufAllocator[13]
3087007744 | 3067084800 |1048576 |
memory/ioBufAllocator[13]
3120562176 | 3104833536 |1048576 |
memory/ioBufAllocator[13]
3154116608 | 3146776576 |1048576
[jira] [Commented] (TS-2274) Better initial default configs
[ https://issues.apache.org/jira/browse/TS-2274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14005253#comment-14005253 ] ASF subversion and git services commented on TS-2274: - Commit 32e968578b9afc5b49ee817d7287f249bd9efe69 in trafficserver's branch refs/heads/master from [~zwoop] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=32e9685 ] TS-2274 Minimize the default records.config Better initial default configs -- Key: TS-2274 URL: https://issues.apache.org/jira/browse/TS-2274 Project: Traffic Server Issue Type: Bug Components: Configuration Reporter: Miles Libbey Assignee: Leif Hedstrom Fix For: 5.0.0 Seems like there are several config values that are not very smart for the newbie user: - cache size: storage.config: var/trafficserver 256M - max object size (though, perhaps this is now unlimited) - read-while-write settings? - 4-5 volumes for the volume config? - CONFIG proxy.config.cache.ram_cache_cutoff INT 4194304 ? Adam Dace in https://cwiki.apache.org/confluence/display/TS/WebProxyCacheSetup suggested several others, but, it looks to me like the settings are very machine specific (eg, specific IP addresses) Others? -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2274) Better initial default configs
[ https://issues.apache.org/jira/browse/TS-2274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14005307#comment-14005307 ] ASF subversion and git services commented on TS-2274: - Commit 9b169973b8b4c6720dde32ba740dc0d7d52cc2ca in trafficserver's branch refs/heads/master from [~zwoop] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=9b16997 ] TS-2274 Set sock_send_buffer_size_in to 0 by default Better initial default configs -- Key: TS-2274 URL: https://issues.apache.org/jira/browse/TS-2274 Project: Traffic Server Issue Type: Bug Components: Configuration Reporter: Miles Libbey Assignee: Leif Hedstrom Fix For: 5.0.0 Seems like there are several config values that are not very smart for the newbie user: - cache size: storage.config: var/trafficserver 256M - max object size (though, perhaps this is now unlimited) - read-while-write settings? - 4-5 volumes for the volume config? - CONFIG proxy.config.cache.ram_cache_cutoff INT 4194304 ? Adam Dace in https://cwiki.apache.org/confluence/display/TS/WebProxyCacheSetup suggested several others, but, it looks to me like the settings are very machine specific (eg, specific IP addresses) Others? -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2274) Better initial default configs
[ https://issues.apache.org/jira/browse/TS-2274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14005309#comment-14005309 ] ASF subversion and git services commented on TS-2274: - Commit b3009146bcd58d2b23b06412ffa61936192afcc1 in trafficserver's branch refs/heads/master from [~zwoop] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=b300914 ] TS-2274 Fix the regressions Better initial default configs -- Key: TS-2274 URL: https://issues.apache.org/jira/browse/TS-2274 Project: Traffic Server Issue Type: Bug Components: Configuration Reporter: Miles Libbey Assignee: Leif Hedstrom Fix For: 5.0.0 Seems like there are several config values that are not very smart for the newbie user: - cache size: storage.config: var/trafficserver 256M - max object size (though, perhaps this is now unlimited) - read-while-write settings? - 4-5 volumes for the volume config? - CONFIG proxy.config.cache.ram_cache_cutoff INT 4194304 ? Adam Dace in https://cwiki.apache.org/confluence/display/TS/WebProxyCacheSetup suggested several others, but, it looks to me like the settings are very machine specific (eg, specific IP addresses) Others? -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2274) Better initial default configs
[ https://issues.apache.org/jira/browse/TS-2274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14005308#comment-14005308 ] ASF subversion and git services commented on TS-2274: - Commit 82401537663e5e57dddfd8d1a98c5ecdbdf39d8a in trafficserver's branch refs/heads/master from [~zwoop] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=8240153 ] TS-2274 Set diags.show_location to on Better initial default configs -- Key: TS-2274 URL: https://issues.apache.org/jira/browse/TS-2274 Project: Traffic Server Issue Type: Bug Components: Configuration Reporter: Miles Libbey Assignee: Leif Hedstrom Fix For: 5.0.0 Seems like there are several config values that are not very smart for the newbie user: - cache size: storage.config: var/trafficserver 256M - max object size (though, perhaps this is now unlimited) - read-while-write settings? - 4-5 volumes for the volume config? - CONFIG proxy.config.cache.ram_cache_cutoff INT 4194304 ? Adam Dace in https://cwiki.apache.org/confluence/display/TS/WebProxyCacheSetup suggested several others, but, it looks to me like the settings are very machine specific (eg, specific IP addresses) Others? -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2274) Better initial default configs
[ https://issues.apache.org/jira/browse/TS-2274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14005306#comment-14005306 ] ASF subversion and git services commented on TS-2274: - Commit 1a3418210b64a15ecb870ba5375571f8da784ee8 in trafficserver's branch refs/heads/master from [~zwoop] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=1a34182 ] TS-2274 Set the default SPDY max streams to 100 Better initial default configs -- Key: TS-2274 URL: https://issues.apache.org/jira/browse/TS-2274 Project: Traffic Server Issue Type: Bug Components: Configuration Reporter: Miles Libbey Assignee: Leif Hedstrom Fix For: 5.0.0 Seems like there are several config values that are not very smart for the newbie user: - cache size: storage.config: var/trafficserver 256M - max object size (though, perhaps this is now unlimited) - read-while-write settings? - 4-5 volumes for the volume config? - CONFIG proxy.config.cache.ram_cache_cutoff INT 4194304 ? Adam Dace in https://cwiki.apache.org/confluence/display/TS/WebProxyCacheSetup suggested several others, but, it looks to me like the settings are very machine specific (eg, specific IP addresses) Others? -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2826) SPDY implementation does not support OPTIONS and TRACE methods
[
https://issues.apache.org/jira/browse/TS-2826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-2826:
---
Fix Version/s: 5.0.0
SPDY implementation does not support OPTIONS and TRACE methods
--
Key: TS-2826
URL: https://issues.apache.org/jira/browse/TS-2826
Project: Traffic Server
Issue Type: Bug
Components: SPDY
Reporter: Sudheer Vinukonda
Labels: SPDY, yahoo
Fix For: 5.0.0
Attachments: ts2826.diff
SPDY implementation currently only supports the below methods. Need to add
OPTIONS and TRACE methods to it.
{code}
if (req-method == GET)
spdy_fetcher_launch(req, TS_FETCH_METHOD_GET);
else if (req-method == POST)
spdy_fetcher_launch(req, TS_FETCH_METHOD_POST);
else if (req-method == PURGE)
spdy_fetcher_launch(req, TS_FETCH_METHOD_PURGE);
else if (req-method == PUT)
spdy_fetcher_launch(req, TS_FETCH_METHOD_PUT);
else if (req-method == HEAD)
spdy_fetcher_launch(req, TS_FETCH_METHOD_HEAD);
else if (req-method == CONNECT)
spdy_fetcher_launch(req, TS_FETCH_METHOD_CONNECT);
else if (req-method == DELETE)
spdy_fetcher_launch(req, TS_FETCH_METHOD_DELETE);
else if (req-method == LAST)
spdy_fetcher_launch(req, TS_FETCH_METHOD_LAST);
else
spdy_prepare_status_response(sm, req-stream_id, STATUS_405);
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Assigned] (TS-2826) SPDY implementation does not support OPTIONS and TRACE methods
[
https://issues.apache.org/jira/browse/TS-2826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call reassigned TS-2826:
--
Assignee: Bryan Call
SPDY implementation does not support OPTIONS and TRACE methods
--
Key: TS-2826
URL: https://issues.apache.org/jira/browse/TS-2826
Project: Traffic Server
Issue Type: Bug
Components: SPDY
Reporter: Sudheer Vinukonda
Assignee: Bryan Call
Labels: SPDY, yahoo
Fix For: 5.0.0
Attachments: ts2826.diff
SPDY implementation currently only supports the below methods. Need to add
OPTIONS and TRACE methods to it.
{code}
if (req-method == GET)
spdy_fetcher_launch(req, TS_FETCH_METHOD_GET);
else if (req-method == POST)
spdy_fetcher_launch(req, TS_FETCH_METHOD_POST);
else if (req-method == PURGE)
spdy_fetcher_launch(req, TS_FETCH_METHOD_PURGE);
else if (req-method == PUT)
spdy_fetcher_launch(req, TS_FETCH_METHOD_PUT);
else if (req-method == HEAD)
spdy_fetcher_launch(req, TS_FETCH_METHOD_HEAD);
else if (req-method == CONNECT)
spdy_fetcher_launch(req, TS_FETCH_METHOD_CONNECT);
else if (req-method == DELETE)
spdy_fetcher_launch(req, TS_FETCH_METHOD_DELETE);
else if (req-method == LAST)
spdy_fetcher_launch(req, TS_FETCH_METHOD_LAST);
else
spdy_prepare_status_response(sm, req-stream_id, STATUS_405);
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2826) SPDY implementation does not support OPTIONS and TRACE methods
[
https://issues.apache.org/jira/browse/TS-2826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14005328#comment-14005328
]
ASF subversion and git services commented on TS-2826:
-
Commit a214393daf91b4c261a2ead8e1a434f85a873f5c in trafficserver's branch
refs/heads/master from [~sudheerv]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=a214393 ]
TS-2826: SPDY implementation does not support OPTIONS and TRACE methods
SPDY implementation does not support OPTIONS and TRACE methods
--
Key: TS-2826
URL: https://issues.apache.org/jira/browse/TS-2826
Project: Traffic Server
Issue Type: Bug
Components: SPDY
Reporter: Sudheer Vinukonda
Labels: SPDY, yahoo
Fix For: 5.0.0
Attachments: ts2826.diff
SPDY implementation currently only supports the below methods. Need to add
OPTIONS and TRACE methods to it.
{code}
if (req-method == GET)
spdy_fetcher_launch(req, TS_FETCH_METHOD_GET);
else if (req-method == POST)
spdy_fetcher_launch(req, TS_FETCH_METHOD_POST);
else if (req-method == PURGE)
spdy_fetcher_launch(req, TS_FETCH_METHOD_PURGE);
else if (req-method == PUT)
spdy_fetcher_launch(req, TS_FETCH_METHOD_PUT);
else if (req-method == HEAD)
spdy_fetcher_launch(req, TS_FETCH_METHOD_HEAD);
else if (req-method == CONNECT)
spdy_fetcher_launch(req, TS_FETCH_METHOD_CONNECT);
else if (req-method == DELETE)
spdy_fetcher_launch(req, TS_FETCH_METHOD_DELETE);
else if (req-method == LAST)
spdy_fetcher_launch(req, TS_FETCH_METHOD_LAST);
else
spdy_prepare_status_response(sm, req-stream_id, STATUS_405);
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2826) SPDY implementation does not support OPTIONS and TRACE methods
[
https://issues.apache.org/jira/browse/TS-2826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14005329#comment-14005329
]
ASF subversion and git services commented on TS-2826:
-
Commit ceaf993fe03ed4d2cac527d6c08b35216522a93e in trafficserver's branch
refs/heads/master from [~bcall]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=ceaf993 ]
Added TS-2826 to changes
SPDY implementation does not support OPTIONS and TRACE methods
--
Key: TS-2826
URL: https://issues.apache.org/jira/browse/TS-2826
Project: Traffic Server
Issue Type: Bug
Components: SPDY
Reporter: Sudheer Vinukonda
Labels: SPDY, yahoo
Fix For: 5.0.0
Attachments: ts2826.diff
SPDY implementation currently only supports the below methods. Need to add
OPTIONS and TRACE methods to it.
{code}
if (req-method == GET)
spdy_fetcher_launch(req, TS_FETCH_METHOD_GET);
else if (req-method == POST)
spdy_fetcher_launch(req, TS_FETCH_METHOD_POST);
else if (req-method == PURGE)
spdy_fetcher_launch(req, TS_FETCH_METHOD_PURGE);
else if (req-method == PUT)
spdy_fetcher_launch(req, TS_FETCH_METHOD_PUT);
else if (req-method == HEAD)
spdy_fetcher_launch(req, TS_FETCH_METHOD_HEAD);
else if (req-method == CONNECT)
spdy_fetcher_launch(req, TS_FETCH_METHOD_CONNECT);
else if (req-method == DELETE)
spdy_fetcher_launch(req, TS_FETCH_METHOD_DELETE);
else if (req-method == LAST)
spdy_fetcher_launch(req, TS_FETCH_METHOD_LAST);
else
spdy_prepare_status_response(sm, req-stream_id, STATUS_405);
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2400) Our default SSL cipher-suite advocates speed over security
[
https://issues.apache.org/jira/browse/TS-2400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14005341#comment-14005341
]
Leif Hedstrom commented on TS-2400:
---
Moving to Bryan. From the discussions, we want this for v5.0.0:
* Change default cipher suite
* Turn on honor_cipher_order by default
Our default SSL cipher-suite advocates speed over security
--
Key: TS-2400
URL: https://issues.apache.org/jira/browse/TS-2400
Project: Traffic Server
Issue Type: Bug
Components: Configuration, SSL
Reporter: Igor Galić
Assignee: Bryan Call
Fix For: 5.0.0
Our default cipher-suite advocates speed over security:
{code}
RC4-SHA:AES128-SHA:DES-CBC3-SHA:AES256-SHA:ALL:!aNULL:!EXP:!LOW:!MD5:!SSLV2:!NULL
{code}
Worse yet, it still has RC4 in there, along with some other bad defaults. RC4
must be eradicated:
https://blogs.technet.com/b/srd/archive/2013/11/12/security-advisory-2868725-recommendation-to-disable-rc4.aspx?Redirected=true
We should by default advocate security, which means, we should advocate
Perfect Forward Secrecy, which means we should also advocate OpenSSL =
1.0.1e
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2400) Our default SSL cipher-suite advocates speed over security
[
https://issues.apache.org/jira/browse/TS-2400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2400:
--
Assignee: Bryan Call (was: Igor Galić)
Our default SSL cipher-suite advocates speed over security
--
Key: TS-2400
URL: https://issues.apache.org/jira/browse/TS-2400
Project: Traffic Server
Issue Type: Bug
Components: Configuration, SSL
Reporter: Igor Galić
Assignee: Bryan Call
Fix For: 5.0.0
Our default cipher-suite advocates speed over security:
{code}
RC4-SHA:AES128-SHA:DES-CBC3-SHA:AES256-SHA:ALL:!aNULL:!EXP:!LOW:!MD5:!SSLV2:!NULL
{code}
Worse yet, it still has RC4 in there, along with some other bad defaults. RC4
must be eradicated:
https://blogs.technet.com/b/srd/archive/2013/11/12/security-advisory-2868725-recommendation-to-disable-rc4.aspx?Redirected=true
We should by default advocate security, which means, we should advocate
Perfect Forward Secrecy, which means we should also advocate OpenSSL =
1.0.1e
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (TS-2827) Add a BOOL type for records.config
Leif Hedstrom created TS-2827: - Summary: Add a BOOL type for records.config Key: TS-2827 URL: https://issues.apache.org/jira/browse/TS-2827 Project: Traffic Server Issue Type: New Feature Components: Configuration Reporter: Leif Hedstrom We have the underlying plumbing already for a bool type in lib records, so it should be easy to just add a BOOL type shadowing over the INT. This will make it much clearer what configs are 0|1 vs a real integer. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2827) Add a BOOL type for records.config
[ https://issues.apache.org/jira/browse/TS-2827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2827: -- Fix Version/s: 5.1.0 Add a BOOL type for records.config -- Key: TS-2827 URL: https://issues.apache.org/jira/browse/TS-2827 Project: Traffic Server Issue Type: New Feature Components: Configuration Reporter: Leif Hedstrom Fix For: 5.1.0 We have the underlying plumbing already for a bool type in lib records, so it should be easy to just add a BOOL type shadowing over the INT. This will make it much clearer what configs are 0|1 vs a real integer. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2274) Better initial default configs
[ https://issues.apache.org/jira/browse/TS-2274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14005359#comment-14005359 ] ASF subversion and git services commented on TS-2274: - Commit f660f5667d99b3bb36ab4f9bd33740b9db2144b4 in trafficserver's branch refs/heads/master from [~zwoop] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=f660f56 ] TS-2274 Set the default for proxy.config.env_prep to NULL Better initial default configs -- Key: TS-2274 URL: https://issues.apache.org/jira/browse/TS-2274 Project: Traffic Server Issue Type: Bug Components: Configuration Reporter: Miles Libbey Assignee: Leif Hedstrom Fix For: 5.0.0 Seems like there are several config values that are not very smart for the newbie user: - cache size: storage.config: var/trafficserver 256M - max object size (though, perhaps this is now unlimited) - read-while-write settings? - 4-5 volumes for the volume config? - CONFIG proxy.config.cache.ram_cache_cutoff INT 4194304 ? Adam Dace in https://cwiki.apache.org/confluence/display/TS/WebProxyCacheSetup suggested several others, but, it looks to me like the settings are very machine specific (eg, specific IP addresses) Others? -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TS-2828) Increase HostDB default sizes
Leif Hedstrom created TS-2828: - Summary: Increase HostDB default sizes Key: TS-2828 URL: https://issues.apache.org/jira/browse/TS-2828 Project: Traffic Server Issue Type: Improvement Components: Core, DNS Reporter: Leif Hedstrom Alan suggests 128MB / 256K entries. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2828) Increase HostDB default sizes
[ https://issues.apache.org/jira/browse/TS-2828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2828: -- Priority: Critical (was: Major) Increase HostDB default sizes - Key: TS-2828 URL: https://issues.apache.org/jira/browse/TS-2828 Project: Traffic Server Issue Type: Improvement Components: Core, DNS Reporter: Leif Hedstrom Priority: Critical Fix For: 5.0.0 Alan suggests 128MB / 256K entries. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2828) Increase HostDB default sizes
[ https://issues.apache.org/jira/browse/TS-2828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2828: -- Fix Version/s: 5.0.0 Increase HostDB default sizes - Key: TS-2828 URL: https://issues.apache.org/jira/browse/TS-2828 Project: Traffic Server Issue Type: Improvement Components: Core, DNS Reporter: Leif Hedstrom Fix For: 5.0.0 Alan suggests 128MB / 256K entries. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2828) Increase HostDB default sizes
[ https://issues.apache.org/jira/browse/TS-2828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2828: -- Assignee: Alan M. Carroll Increase HostDB default sizes - Key: TS-2828 URL: https://issues.apache.org/jira/browse/TS-2828 Project: Traffic Server Issue Type: Improvement Components: Core, DNS Reporter: Leif Hedstrom Assignee: Alan M. Carroll Priority: Critical Fix For: 5.0.0 Alan suggests 128MB / 256K entries. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-1125) POST's with Expect: 100-continue are slowed by delayed 100 response.
[ https://issues.apache.org/jira/browse/TS-1125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14005375#comment-14005375 ] ASF subversion and git services commented on TS-1125: - Commit e5da353c51fc6b1bc5cc150db4a5f4f4e334fd6c in trafficserver's branch refs/heads/master from [~ffcai] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=e5da353 ] TS-1125: POST's with Expect: 100-continue are slowed by delayed 100 response POST's with Expect: 100-continue are slowed by delayed 100 response. Key: TS-1125 URL: https://issues.apache.org/jira/browse/TS-1125 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 3.0.2 Environment: TS 3.0.2 going to Apache 2.2 web server Reporter: William Bardwell Assignee: Bryan Call Priority: Minor Labels: yahoo Fix For: 5.0.0 Attachments: TS-1125.diff, TS-1125.diff, ts1125.diff, ts1125.diff, ts1125.diff Sending a post like: POST / HTTP/1.1 Host: www.example.com Content-Length: 10 Expect: 100-continue directly to the web server immediately sends back: HTTP/1.1 100 Continue And then when the post data is sent, a status 200 response comes back. But when going through ATS the HTTP/1.1 100 Continue is not sent immediately, and instead is sent after the POST data has been received. This is legal, but it makes clients that are hoping for a 100 continue to wait a little while hoping to get that, ATS should forward that response through immediately. Note: I see curl using Expect: 100-continue with 1024 bytes of post data, but web searching indicates that some Microsoft products also use it. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2757) logging crashes on reconfiguration
[
https://issues.apache.org/jira/browse/TS-2757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14005381#comment-14005381
]
ASF subversion and git services commented on TS-2757:
-
Commit 99c19a0139b14aaf94029baa4e269a95438325cf in trafficserver's branch
refs/heads/master from [~jpe...@apache.org]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=99c19a0 ]
TS-2757: the Derefer should actually delete things
logging crashes on reconfiguration
--
Key: TS-2757
URL: https://issues.apache.org/jira/browse/TS-2757
Project: Traffic Server
Issue Type: Bug
Components: Logging
Affects Versions: 5.0.0
Reporter: James Peach
Assignee: James Peach
Labels: A
Fix For: 5.0.0
If you use {{TSTextLogObjectCreate}} in a plugin, when those log objects are
deleted, the object manager crashes. It looks like {{_APIobjects}} has a
stale pointer.
{code}
(gdb) bt
#0 0x005e8c47 in LogObjectManager::~LogObjectManager
(this=0x4bf0028, __in_chrg=value optimized out) at LogObject.cc:903
#1 0x005d33e2 in LogConfig::~LogConfig (this=0x4bf,
__in_chrg=value optimized out) at LogConfig.cc:573
#2 0x005d3446 in LogConfig::~LogConfig (this=0x4bf,
__in_chrg=value optimized out) at LogConfig.cc:573
#3 0x00617b8a in ConfigProcessor::release (this=0xafa720, id=5,
info=0x4bf) at ProxyConfig.cc:210
#4 0x00618496 in ConfigInfoReleaser::handle_event (this=0x21c5a00)
at ProxyConfig.cc:106
#5 0x004e5920 in Continuation::handleEvent (this=0x21c5a00, event=2,
data=0xe926780) at ../iocore/eventsystem/I_Continuation.h:146
#6 0x006d17b6 in EThread::process_event (this=0x2e08000,
e=0xe926780, calling_code=2) at UnixEThread.cc:145
#7 0x006d1ad1 in EThread::execute (this=0x2e08000) at
UnixEThread.cc:224
#8 0x006d0da0 in spawn_thread_internal (a=0x21ddd60) at Thread.cc:88
#9 0x2b507e273851 in start_thread () from /lib64/libpthread.so.0
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2765) Memory Leak in SSLConfig initialization
[
https://issues.apache.org/jira/browse/TS-2765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14005389#comment-14005389
]
ASF subversion and git services commented on TS-2765:
-
Commit c6af7a64425477d5196b6a6c7de392efe186e07e in trafficserver's branch
refs/heads/master from [~bcall]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=c6af7a6 ]
Added TS-2765 to changes
Memory Leak in SSLConfig initialization
---
Key: TS-2765
URL: https://issues.apache.org/jira/browse/TS-2765
Project: Traffic Server
Issue Type: Bug
Components: Core
Reporter: Sudheer Vinukonda
Assignee: Bryan Call
Labels: review, spdy, yahoo
Fix For: 5.0.0
Attachments: ts2765.diff
While debugging memory leak during SPDY testing on a production host noticed
a couple of leaks (13 bytes each) during SSL Config initialization. Below is
the valgrind output showing the leak. These bugs also exist in 4.0.
{code}
==29790== Thread 1:
==29790== 13 bytes in 1 blocks are definitely lost in loss record 168 of 2,653
==29790==at 0x4C279EE: malloc (vg_replace_malloc.c:270)
==29790==by 0x4E50E3D: ats_malloc (ink_memory.cc:50)
==29790==by 0x4E50E9D: _xstrdup (ink_memory.cc:236)
==29790==by 0x70E90B: RecDataSet(RecDataT, RecData*, RecData*)
(RecUtils.cc:148)
==29790==by 0x70729C: RecGetRecord_Xmalloc(char const*, RecDataT,
RecData*, bool) (RecCore.cc:780)
==29790==by 0x707327: RecGetRecordString_Xmalloc(char const*, char**,
bool) (RecCore.cc:382)
==29790==by 0x6DAF2C: SSLConfigParams::initialize() (SSLConfig.cc:214)
==29790==by 0x6DB5AD: SSLConfig::startup() (SSLConfig.cc:265)
==29790==by 0x6DBB29: SSLNetProcessor::start(int, unsigned long)
(SSLNetProcessor.cc:51)
==29790==by 0x4D0723: main (Main.cc:1557)
==29790==
==29790== 13 bytes in 1 blocks are definitely lost in loss record 169 of 2,653
==29790==at 0x4C279EE: malloc (vg_replace_malloc.c:270)
==29790==by 0x4E50E3D: ats_malloc (ink_memory.cc:50)
==29790==by 0x4E50E9D: _xstrdup (ink_memory.cc:236)
==29790==by 0x70E90B: RecDataSet(RecDataT, RecData*, RecData*)
(RecUtils.cc:148)
==29790==by 0x70729C: RecGetRecord_Xmalloc(char const*, RecDataT,
RecData*, bool) (RecCore.cc:780)
==29790==by 0x707327: RecGetRecordString_Xmalloc(char const*, char**,
bool) (RecCore.cc:382)
==29790==by 0x6DB0E2: SSLConfigParams::initialize() (SSLConfig.cc:246)
==29790==by 0x6DB5AD: SSLConfig::startup() (SSLConfig.cc:265)
==29790==by 0x6DBB29: SSLNetProcessor::start(int, unsigned long)
(SSLNetProcessor.cc:51)
==29790==by 0x4D0723: main (Main.cc:1557)
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2765) Memory Leak in SSLConfig initialization
[
https://issues.apache.org/jira/browse/TS-2765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14005388#comment-14005388
]
ASF subversion and git services commented on TS-2765:
-
Commit dcc579668381d763d5be908ea737cbbb6a3bd075 in trafficserver's branch
refs/heads/master from [~sudheerv]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=dcc5796 ]
TS-2765: Memory Leak in SSLConfig initialization
Memory Leak in SSLConfig initialization
---
Key: TS-2765
URL: https://issues.apache.org/jira/browse/TS-2765
Project: Traffic Server
Issue Type: Bug
Components: Core
Reporter: Sudheer Vinukonda
Assignee: Bryan Call
Labels: review, spdy, yahoo
Fix For: 5.0.0
Attachments: ts2765.diff
While debugging memory leak during SPDY testing on a production host noticed
a couple of leaks (13 bytes each) during SSL Config initialization. Below is
the valgrind output showing the leak. These bugs also exist in 4.0.
{code}
==29790== Thread 1:
==29790== 13 bytes in 1 blocks are definitely lost in loss record 168 of 2,653
==29790==at 0x4C279EE: malloc (vg_replace_malloc.c:270)
==29790==by 0x4E50E3D: ats_malloc (ink_memory.cc:50)
==29790==by 0x4E50E9D: _xstrdup (ink_memory.cc:236)
==29790==by 0x70E90B: RecDataSet(RecDataT, RecData*, RecData*)
(RecUtils.cc:148)
==29790==by 0x70729C: RecGetRecord_Xmalloc(char const*, RecDataT,
RecData*, bool) (RecCore.cc:780)
==29790==by 0x707327: RecGetRecordString_Xmalloc(char const*, char**,
bool) (RecCore.cc:382)
==29790==by 0x6DAF2C: SSLConfigParams::initialize() (SSLConfig.cc:214)
==29790==by 0x6DB5AD: SSLConfig::startup() (SSLConfig.cc:265)
==29790==by 0x6DBB29: SSLNetProcessor::start(int, unsigned long)
(SSLNetProcessor.cc:51)
==29790==by 0x4D0723: main (Main.cc:1557)
==29790==
==29790== 13 bytes in 1 blocks are definitely lost in loss record 169 of 2,653
==29790==at 0x4C279EE: malloc (vg_replace_malloc.c:270)
==29790==by 0x4E50E3D: ats_malloc (ink_memory.cc:50)
==29790==by 0x4E50E9D: _xstrdup (ink_memory.cc:236)
==29790==by 0x70E90B: RecDataSet(RecDataT, RecData*, RecData*)
(RecUtils.cc:148)
==29790==by 0x70729C: RecGetRecord_Xmalloc(char const*, RecDataT,
RecData*, bool) (RecCore.cc:780)
==29790==by 0x707327: RecGetRecordString_Xmalloc(char const*, char**,
bool) (RecCore.cc:382)
==29790==by 0x6DB0E2: SSLConfigParams::initialize() (SSLConfig.cc:246)
==29790==by 0x6DB5AD: SSLConfig::startup() (SSLConfig.cc:265)
==29790==by 0x6DBB29: SSLNetProcessor::start(int, unsigned long)
(SSLNetProcessor.cc:51)
==29790==by 0x4D0723: main (Main.cc:1557)
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2274) Better initial default configs
[ https://issues.apache.org/jira/browse/TS-2274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14005399#comment-14005399 ] ASF subversion and git services commented on TS-2274: - Commit 7c3c17ec748a8f11012af1a471877ec885c8ba96 in trafficserver's branch refs/heads/master from [~zwoop] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=7c3c17e ] TS-2274 Restore enough configurations that makes traffic_cop start again Thanks to Bryan for testing / finding this. Better initial default configs -- Key: TS-2274 URL: https://issues.apache.org/jira/browse/TS-2274 Project: Traffic Server Issue Type: Bug Components: Configuration Reporter: Miles Libbey Assignee: Leif Hedstrom Fix For: 5.0.0 Seems like there are several config values that are not very smart for the newbie user: - cache size: storage.config: var/trafficserver 256M - max object size (though, perhaps this is now unlimited) - read-while-write settings? - 4-5 volumes for the volume config? - CONFIG proxy.config.cache.ram_cache_cutoff INT 4194304 ? Adam Dace in https://cwiki.apache.org/confluence/display/TS/WebProxyCacheSetup suggested several others, but, it looks to me like the settings are very machine specific (eg, specific IP addresses) Others? -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2636) Enhance ATS custom logging to support WIPE_FIELD_VALUE filter action
[ https://issues.apache.org/jira/browse/TS-2636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14005403#comment-14005403 ] ASF subversion and git services commented on TS-2636: - Commit 5acff2c66d7b9ae795cd6d4bfac196c3acbe3d1a in trafficserver's branch refs/heads/master from [~sudheerv] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=5acff2c ] TS-2636: Enhance ATS custom logging to support WIPE_FIELD_VALUE filter action Adding documentation Enhance ATS custom logging to support WIPE_FIELD_VALUE filter action Key: TS-2636 URL: https://issues.apache.org/jira/browse/TS-2636 Project: Traffic Server Issue Type: New Feature Components: Logging Reporter: Sudheer Vinukonda Assignee: Bryan Call Labels: Review, yahoo Fix For: 5.0.0 Attachments: ts2636-doc.diff, ts2636.diff Currently, ATS custom logging supports LogFilters with actions Accept, Reject. This feature request is to add a new filter action WIPE. WIPE can be used in hiding sensitive parameters (e.g. userid, password) within the query part of a URL. Attached is a draft version of the patch. Kindly review and comment. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2780) Core dump in SpdyRequest::clear() in production testing of SPDY
[
https://issues.apache.org/jira/browse/TS-2780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14005410#comment-14005410
]
Bryan Call commented on TS-2780:
On a production host that is serving static content:
{code}
-bash-4.1$ sudo grep 'req null in SpdSM::clear' diags.log
[May 9 03:30:36.579] Server {0x2b64cd55e700} ERROR: req null in SpdSM::clear
[May 19 22:13:05.611] Server {0x2ac876fc9700} ERROR: req null in SpdSM::clear
[May 21 05:14:47.868] Server {0x2ada465bf700} ERROR: req null in SpdSM::clear
[May 21 18:48:41.789] Server {0x2b413be45700} ERROR: req null in SpdSM::clear
{code}
Core dump in SpdyRequest::clear() in production testing of SPDY
---
Key: TS-2780
URL: https://issues.apache.org/jira/browse/TS-2780
Project: Traffic Server
Issue Type: Bug
Components: SPDY
Reporter: Sudheer Vinukonda
Assignee: Bryan Call
Labels: spdy, yahoo
Fix For: 5.0.0
Attachments: ts2780.diff
Noticed the below core dump in SpdyRequest::clear() during production testing
on our proxy platform.
{code}
NOTE: Traffic Server received Sig 11: Segmentation fault
/home/y/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0(+0x3420a0f500)[0x2b47cff7d500]
/home/y/bin/traffic_server(_ZN11SpdyRequest5clearEv+0x14)[0x5d06d4]
/home/y/bin/traffic_server(_ZN6SpdySM5clearEv+0x34)[0x5d0b84]
/home/y/bin/traffic_server[0x5d13d1]
/home/y/bin/traffic_server(_ZN18UnixNetVConnection14readSignalDoneEiP10NetHandler+0x3d)[0x6efbcd]
/home/y/bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0xc76)[0x6df3e6]
/home/y/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x1f2)[0x6e6b12]
/home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x714aaf]
/home/y/bin/traffic_server(_ZN7EThread7executeEv+0x493)[0x715453]
/home/y/bin/traffic_server[0x713e5a]
/lib64/libpthread.so.0(+0x3420a07851)[0x2b47cff75851]
/lib64/libc.so.6(clone+0x6d)[0x34202e894d]
{code}
gdb output shows that req may be a null pointer in SpdySM::clear()
{code}
(gdb) bt
#0 SpdyRequest::clear (this=0x0) at SpdySM.cc:44
#1 0x005d0b84 in SpdySM::clear (this=0x2aefdc4b46a0) at SpdySM.cc:116
#2 0x005d13d1 in spdy_default_handler (contp=value optimized out,
event=TS_EVENT_VCONN_INACTIVITY_TIMEOUT, edata=value optimized out) at
SpdySM.cc:258
#3 0x006eeabb in handleEvent (event=value optimized out,
vc=0x2aefcc141ca0) at ../../iocore/eventsystem/I_Continuation.h:146
#4 read_signal_and_update (event=value optimized out, vc=0x2aefcc141ca0)
at UnixNetVConnection.cc:216
#5 0x006f3cd4 in UnixNetVConnection::mainEvent (this=0x2aefcc141ca0,
event=value optimized out, e=value optimized out) at
UnixNetVConnection.cc:1152
#6 0x006e7d0e in handleEvent (this=0x1634af0, event=value optimized
out, e=0x136e850) at ../../iocore/eventsystem/I_Continuation.h:146
#7 InactivityCop::check_inactivity (this=0x1634af0, event=value optimized
out, e=0x136e850) at UnixNet.cc:67
#8 0x00714aaf in handleEvent (this=0x2aef48f91010, e=0x136e850,
calling_code=2) at I_Continuation.h:146
#9 EThread::process_event (this=0x2aef48f91010, e=0x136e850, calling_code=2)
at UnixEThread.cc:145
#10 0x00715623 in EThread::execute (this=0x2aef48f91010) at
UnixEThread.cc:224
#11 0x00713e5a in spawn_thread_internal (a=0x163d000) at Thread.cc:88
#12 0x2aed0a8a1851 in start_thread () from /lib64/libpthread.so.0
#13 0x0034202e894d in clone () from /lib64/libc.so.6
(gdb) print this
$1 = (SpdyRequest * const) 0x0
(gdb) up
#1 0x005d0b84 in SpdySM::clear (this=0x2aefdc4b46a0) at SpdySM.cc:116
116 in SpdySM.cc
(gdb) print req
$2 = (SpdyRequest *) 0x0
(gdb) print iter
$3 = {first = 25, second = }
(gdb) print req_map
$4 = std::map with 3 elements = {
[1] = 0x2aefd81e5ae0,
[25] = 0x0,
[27] = 0x0
}
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2284) Run with no configs
[ https://issues.apache.org/jira/browse/TS-2284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2284: -- Fix Version/s: (was: 5.0.0) 5.1.0 Run with no configs --- Key: TS-2284 URL: https://issues.apache.org/jira/browse/TS-2284 Project: Traffic Server Issue Type: Sub-task Components: Configuration Reporter: Phil Sorber Assignee: Leif Hedstrom Fix For: 5.1.0 In addition to running with empty configs (TS-2282), we should be able to run with no configs and not write them out (TS-2283). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2282) Allow ATS to run with empty config
[ https://issues.apache.org/jira/browse/TS-2282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2282: -- Fix Version/s: (was: 5.0.0) 5.1.0 Allow ATS to run with empty config -- Key: TS-2282 URL: https://issues.apache.org/jira/browse/TS-2282 Project: Traffic Server Issue Type: Sub-task Components: Configuration Reporter: Phil Sorber Assignee: Leif Hedstrom Fix For: 5.1.0 Traffic server should start and run with empty config files using the defaults. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2282) Allow ATS to run with empty config
[ https://issues.apache.org/jira/browse/TS-2282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14005414#comment-14005414 ] Leif Hedstrom commented on TS-2282: --- Due to _cop and _manager being stupid, it seems unlikely we can get this done for v5.0.0 Allow ATS to run with empty config -- Key: TS-2282 URL: https://issues.apache.org/jira/browse/TS-2282 Project: Traffic Server Issue Type: Sub-task Components: Configuration Reporter: Phil Sorber Assignee: Leif Hedstrom Fix For: 5.1.0 Traffic server should start and run with empty config files using the defaults. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2284) Run with no configs
[ https://issues.apache.org/jira/browse/TS-2284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14005413#comment-14005413 ] Leif Hedstrom commented on TS-2284: --- Seems unlikely we can get this in, so moving out to 5.1.0 for now. Run with no configs --- Key: TS-2284 URL: https://issues.apache.org/jira/browse/TS-2284 Project: Traffic Server Issue Type: Sub-task Components: Configuration Reporter: Phil Sorber Assignee: Leif Hedstrom Fix For: 5.1.0 In addition to running with empty configs (TS-2282), we should be able to run with no configs and not write them out (TS-2283). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (TS-2274) Better initial default configs
[ https://issues.apache.org/jira/browse/TS-2274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-2274. --- Resolution: Fixed Better initial default configs -- Key: TS-2274 URL: https://issues.apache.org/jira/browse/TS-2274 Project: Traffic Server Issue Type: Bug Components: Configuration Reporter: Miles Libbey Assignee: Leif Hedstrom Fix For: 5.0.0 Seems like there are several config values that are not very smart for the newbie user: - cache size: storage.config: var/trafficserver 256M - max object size (though, perhaps this is now unlimited) - read-while-write settings? - 4-5 volumes for the volume config? - CONFIG proxy.config.cache.ram_cache_cutoff INT 4194304 ? Adam Dace in https://cwiki.apache.org/confluence/display/TS/WebProxyCacheSetup suggested several others, but, it looks to me like the settings are very machine specific (eg, specific IP addresses) Others? -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2829) Replace alloca() with variable arrays
[ https://issues.apache.org/jira/browse/TS-2829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2829: -- Fix Version/s: (was: 5.0.0) 5.1.0 Replace alloca() with variable arrays - Key: TS-2829 URL: https://issues.apache.org/jira/browse/TS-2829 Project: Traffic Server Issue Type: Bug Components: Core, Portability Reporter: James Peach Assignee: Leif Hedstrom Fix For: 5.1.0 We should drop Solaris Studio support for the 3.4 release. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TS-2829) Replace alloca() with variable arrays
Leif Hedstrom created TS-2829: - Summary: Replace alloca() with variable arrays Key: TS-2829 URL: https://issues.apache.org/jira/browse/TS-2829 Project: Traffic Server Issue Type: Bug Components: Core, Portability Reporter: James Peach Assignee: Leif Hedstrom Fix For: 5.0.0 We should drop Solaris Studio support for the 3.4 release. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2820) Crash in transformations
[ https://issues.apache.org/jira/browse/TS-2820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-2820: --- Fix Version/s: 5.0.0 Crash in transformations Key: TS-2820 URL: https://issues.apache.org/jira/browse/TS-2820 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Brian Geffon Assignee: Brian Geffon Fix For: 5.0.0 I'm seeing an easy to reproduce crash in 4.2.0 and master (5.0.0), so I'm assuming it was introduced between 3.2.x and 4.1.0. To reproduce I'm using a simple null transformation plugin and just making repeated curl requests. HttpTunnel::consumer_handler (this=0x7fffea652db8, event=103, c=0x7fffea652e08) at HttpTunnel.cc:1300 1300 c-buffer_reader-mbuf-dealloc_reader(c-buffer_reader); (gdb) bt #0 HttpTunnel::consumer_handler (this=0x7fffea652db8, event=103, c=0x7fffea652e08) at HttpTunnel.cc:1300 #1 0x005e6a2d in HttpTunnel::main_handler (this=0x7fffea652db8, event=optimized out, data=optimized out) at HttpTunnel.cc:1525 #2 0x727e9981 in handleTransformationPluginRead (state=0x7fffa00d7db0, contp=0x7fffd4021b70) at TransformationPlugin.cc:175 #3 (anonymous namespace)::handleTransformationPluginEvents (contp=optimized out, event=optimized out, edata=optimized out) at TransformationPlugin.cc:217 #4 0x0073792f in handleEvent (data=0x7fffdc18fbf0, event=1, this=optimized out) at I_Continuation.h:181 #5 EThread::process_event (this=0x767d5010, e=0x7fffdc18fbf0, calling_code=1) at UnixEThread.cc:145 #6 0x0073845b in EThread::execute (this=0x767d5010) at UnixEThread.cc:196 #7 0x00736cda in spawn_thread_internal (a=0x10898d0) at Thread.cc:88 #8 0x0033a1607851 in start_thread () from /lib64/libpthread.so.0 #9 0x0033a12e890d in clone () from /lib64/libc.so.6 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (TS-1486) drop solaris studio support
[ https://issues.apache.org/jira/browse/TS-1486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-1486. --- Resolution: Fixed drop solaris studio support --- Key: TS-1486 URL: https://issues.apache.org/jira/browse/TS-1486 Project: Traffic Server Issue Type: Bug Components: Core, Portability Reporter: James Peach Assignee: Leif Hedstrom Fix For: 5.0.0 We should drop Solaris Studio support for the 3.4 release. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-1486) drop solaris studio support
[ https://issues.apache.org/jira/browse/TS-1486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14005423#comment-14005423 ] ASF subversion and git services commented on TS-1486: - Commit 06825735ca85c3d910e9d6cceb6b8628ece757a4 in trafficserver's branch refs/heads/master from [~zwoop] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=0682573 ] TS-1486 Drop support for Sun Studio compilers drop solaris studio support --- Key: TS-1486 URL: https://issues.apache.org/jira/browse/TS-1486 Project: Traffic Server Issue Type: Bug Components: Core, Portability Reporter: James Peach Assignee: Leif Hedstrom Fix For: 5.0.0 We should drop Solaris Studio support for the 3.4 release. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (TS-2684) Add a log-file feature to background fetch plugin
[ https://issues.apache.org/jira/browse/TS-2684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-2684. --- Resolution: Fixed Add a log-file feature to background fetch plugin - Key: TS-2684 URL: https://issues.apache.org/jira/browse/TS-2684 Project: Traffic Server Issue Type: New Feature Components: Plugins Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 5.0.0 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2684) Add a log-file feature to background fetch plugin
[ https://issues.apache.org/jira/browse/TS-2684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14005445#comment-14005445 ] ASF subversion and git services commented on TS-2684: - Commit 24d860c05584388923d50cc45c44c44e43870c69 in trafficserver's branch refs/heads/master from [~zwoop] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=24d860c ] Added TS-2684 properly, and cleanup the erronous addition. Add a log-file feature to background fetch plugin - Key: TS-2684 URL: https://issues.apache.org/jira/browse/TS-2684 Project: Traffic Server Issue Type: New Feature Components: Plugins Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 5.0.0 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2577) Tracing on e.g. -T http_hdrs does not show Proxy Request headers accurately
[
https://issues.apache.org/jira/browse/TS-2577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14005440#comment-14005440
]
ASF subversion and git services commented on TS-2577:
-
Commit 9c48c936557ca60a66c2842a851676602ce1138e in trafficserver's branch
refs/heads/master from [~maskit]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=9c48c93 ]
[TS-2577] Tracing on e.g. -T http_hdrs does not show Proxy Request
headers accurately
Tracing on e.g. -T http_hdrs does not show Proxy Request headers accurately
---
Key: TS-2577
URL: https://issues.apache.org/jira/browse/TS-2577
Project: Traffic Server
Issue Type: Bug
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
Labels: review
Fix For: 5.0.0
Attachments: quickfix.patch
In particular, if a plugin changes some proxy request headers in a
TS_HTTP_SEND_REQUEST_HDR_HOOK, the tracer will show the header as it was
*before* the plugin hooks are invoked.
This seems wrong, and makes it difficult to debug plugin behavior. It should
clearly produce the header output *after* the plugin hook. In my case, the
produced output from -T http_hdrs is
{code}
+ Proxy's Request +
-- State Machine Id: 0
GET /foo/bar.jpg HTTP/1.1
User-Agent: curl/7.32.0
Accept: */*
Host: host.example.com
Client-ip: 127.0.0.1
X-Forwarded-For: 127.0.0.1
{code}
However, my plugin is injecting both a Date: and an Authorization: header in
a TS_HTTP_SEND_REQUEST_HDR_HOOK hook, which the origin does get. In the
tracer, a later header dump shows the expected header, but it's not
particularly sensical that it is shown after the request and origin response.
{code}
+ Cached Request Hdr +
-- State Machine Id: 0
GET http://host.example.com/foo/bar.jpg HTTP/1.1
User-Agent: curl/7.32.0
Accept: */*
Host: host.example.com
Client-ip: 127.0.0.1
X-Forwarded-For: 127.0.0.1
Date: Wed, 19 Feb 2014 21:17:29 +
Authorization: AWS my-key:=
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (TS-2577) Tracing on e.g. -T http_hdrs does not show Proxy Request headers accurately
[
https://issues.apache.org/jira/browse/TS-2577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom resolved TS-2577.
---
Resolution: Fixed
Tracing on e.g. -T http_hdrs does not show Proxy Request headers accurately
---
Key: TS-2577
URL: https://issues.apache.org/jira/browse/TS-2577
Project: Traffic Server
Issue Type: Bug
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
Labels: review
Fix For: 5.0.0
Attachments: quickfix.patch
In particular, if a plugin changes some proxy request headers in a
TS_HTTP_SEND_REQUEST_HDR_HOOK, the tracer will show the header as it was
*before* the plugin hooks are invoked.
This seems wrong, and makes it difficult to debug plugin behavior. It should
clearly produce the header output *after* the plugin hook. In my case, the
produced output from -T http_hdrs is
{code}
+ Proxy's Request +
-- State Machine Id: 0
GET /foo/bar.jpg HTTP/1.1
User-Agent: curl/7.32.0
Accept: */*
Host: host.example.com
Client-ip: 127.0.0.1
X-Forwarded-For: 127.0.0.1
{code}
However, my plugin is injecting both a Date: and an Authorization: header in
a TS_HTTP_SEND_REQUEST_HDR_HOOK hook, which the origin does get. In the
tracer, a later header dump shows the expected header, but it's not
particularly sensical that it is shown after the request and origin response.
{code}
+ Cached Request Hdr +
-- State Machine Id: 0
GET http://host.example.com/foo/bar.jpg HTTP/1.1
User-Agent: curl/7.32.0
Accept: */*
Host: host.example.com
Client-ip: 127.0.0.1
X-Forwarded-For: 127.0.0.1
Date: Wed, 19 Feb 2014 21:17:29 +
Authorization: AWS my-key:=
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2779) atscppapi: bug in AsyncTimer - cancel results in crash
[ https://issues.apache.org/jira/browse/TS-2779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14005465#comment-14005465 ] Manjesh Nilange commented on TS-2779: - Done. atscppapi: bug in AsyncTimer - cancel results in crash -- Key: TS-2779 URL: https://issues.apache.org/jira/browse/TS-2779 Project: Traffic Server Issue Type: Bug Components: CPP API Reporter: Manjesh Nilange Assignee: Brian Geffon Fix For: 5.0.0 FATAL: InkIOCoreAPI.cc:223: failed assert `sdk_sanity_check_mutex(mutexp) == TS_SUCCESS` /usr/bin/traffic_server - STACK TRACE: /usr/lib64/libtsutil.so.3(ink_fatal+0xc9)[0x77bb2c05] /usr/lib64/libtsutil.so.3(_ink_assert+0x3c)[0x77bb1c48] /usr/bin/traffic_server(_TSReleaseAssert+0x29)[0x4f41a7] /usr/bin/traffic_server(TSMutexLock+0x30)[0x50dcc1] /usr/lib/libatscppapi.so.1(_ZN9atscppapi10AsyncTimer6cancelEv+0x27)[0x7fffe9ae26b9] /usr/lib/libatscppapi.so.1(_ZN9atscppapi10AsyncTimerD1Ev+0x2d)[0x7fffe9ae27a3] /usr/lib/libatscppapi.so.1(_ZN9atscppapi10AsyncTimerD0Ev+0x18)[0x7fffe9ae2824] /home/mnilange/Projects/postbuffer/postbuffer.so(_ZN10PostBufferD1Ev+0x98)[0x7fffe9d14346] /home/mnilange/Projects/postbuffer/postbuffer.so(_ZN10PostBufferD0Ev+0x18)[0x7fffe9d144b6] /usr/lib/libatscppapi.so.1(+0x1ceca)[0x7fffe9ad1eca] -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (TS-2779) atscppapi: bug in AsyncTimer - cancel results in crash
[ https://issues.apache.org/jira/browse/TS-2779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manjesh Nilange resolved TS-2779. - Resolution: Fixed atscppapi: bug in AsyncTimer - cancel results in crash -- Key: TS-2779 URL: https://issues.apache.org/jira/browse/TS-2779 Project: Traffic Server Issue Type: Bug Components: CPP API Reporter: Manjesh Nilange Assignee: Brian Geffon Fix For: 5.0.0 FATAL: InkIOCoreAPI.cc:223: failed assert `sdk_sanity_check_mutex(mutexp) == TS_SUCCESS` /usr/bin/traffic_server - STACK TRACE: /usr/lib64/libtsutil.so.3(ink_fatal+0xc9)[0x77bb2c05] /usr/lib64/libtsutil.so.3(_ink_assert+0x3c)[0x77bb1c48] /usr/bin/traffic_server(_TSReleaseAssert+0x29)[0x4f41a7] /usr/bin/traffic_server(TSMutexLock+0x30)[0x50dcc1] /usr/lib/libatscppapi.so.1(_ZN9atscppapi10AsyncTimer6cancelEv+0x27)[0x7fffe9ae26b9] /usr/lib/libatscppapi.so.1(_ZN9atscppapi10AsyncTimerD1Ev+0x2d)[0x7fffe9ae27a3] /usr/lib/libatscppapi.so.1(_ZN9atscppapi10AsyncTimerD0Ev+0x18)[0x7fffe9ae2824] /home/mnilange/Projects/postbuffer/postbuffer.so(_ZN10PostBufferD1Ev+0x98)[0x7fffe9d14346] /home/mnilange/Projects/postbuffer/postbuffer.so(_ZN10PostBufferD0Ev+0x18)[0x7fffe9d144b6] /usr/lib/libatscppapi.so.1(+0x1ceca)[0x7fffe9ad1eca] -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2421) HostDB creates files FOR THE DEVIL
[
https://issues.apache.org/jira/browse/TS-2421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2421:
--
Fix Version/s: (was: 5.0.0)
sometime
HostDB creates files FOR THE DEVIL
--
Key: TS-2421
URL: https://issues.apache.org/jira/browse/TS-2421
Project: Traffic Server
Issue Type: Bug
Components: DNS, Security
Reporter: Igor Galić
Assignee: Leif Hedstrom
Fix For: sometime
from iocore/hostdb/MultiCache.cc:
{code}
// XXX: Shouldn't that be 0664?
//
if ((fd =::open(p, O_CREAT | O_WRONLY | O_TRUNC, 0666)) = 0) {
{code}
Yes. Yes it should.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2421) HostDB creates files FOR THE DEVIL
[
https://issues.apache.org/jira/browse/TS-2421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14005474#comment-14005474
]
Leif Hedstrom commented on TS-2421:
---
Hmmm, I don't see this actually, I mean, none of the files gets created with
that perm. Maybe this is dead code?
HostDB creates files FOR THE DEVIL
--
Key: TS-2421
URL: https://issues.apache.org/jira/browse/TS-2421
Project: Traffic Server
Issue Type: Bug
Components: DNS, Security
Reporter: Igor Galić
Assignee: Leif Hedstrom
Fix For: sometime
from iocore/hostdb/MultiCache.cc:
{code}
// XXX: Shouldn't that be 0664?
//
if ((fd =::open(p, O_CREAT | O_WRONLY | O_TRUNC, 0666)) = 0) {
{code}
Yes. Yes it should.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2421) HostDB creates files FOR THE DEVIL
[
https://issues.apache.org/jira/browse/TS-2421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2421:
--
Fix Version/s: (was: sometime)
5.2.0
HostDB creates files FOR THE DEVIL
--
Key: TS-2421
URL: https://issues.apache.org/jira/browse/TS-2421
Project: Traffic Server
Issue Type: Bug
Components: DNS, Security
Reporter: Igor Galić
Assignee: Leif Hedstrom
Fix For: 5.2.0
from iocore/hostdb/MultiCache.cc:
{code}
// XXX: Shouldn't that be 0664?
//
if ((fd =::open(p, O_CREAT | O_WRONLY | O_TRUNC, 0666)) = 0) {
{code}
Yes. Yes it should.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2830) Make SPDY configurable.
[ https://issues.apache.org/jira/browse/TS-2830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14005505#comment-14005505 ] Alan M. Carroll commented on TS-2830: - This is a big commit. As part of it I got rid of TSClientProtoStack, it didn't work well with the configuration stuff. We'll have to replace some functionality for outbound connections at some point. See the documentation for what's been made configurable. Make SPDY configurable. --- Key: TS-2830 URL: https://issues.apache.org/jira/browse/TS-2830 Project: Traffic Server Issue Type: Improvement Components: Core, SPDY Reporter: Alan M. Carroll Add configuration options for SPDY, both per port and global. See documentation for details. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TS-2830) Make SPDY configurable.
Alan M. Carroll created TS-2830: --- Summary: Make SPDY configurable. Key: TS-2830 URL: https://issues.apache.org/jira/browse/TS-2830 Project: Traffic Server Issue Type: Improvement Components: Core, SPDY Reporter: Alan M. Carroll Add configuration options for SPDY, both per port and global. See documentation for details. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2830) Make SPDY configurable.
[ https://issues.apache.org/jira/browse/TS-2830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14005507#comment-14005507 ] ASF subversion and git services commented on TS-2830: - Commit b7e69b0fab91fc6a573b871bb11d82cb663e3a63 in trafficserver's branch refs/heads/master from [~amc] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=b7e69b0 ] TS-2830 Make SPDY configurable. Make SPDY configurable. --- Key: TS-2830 URL: https://issues.apache.org/jira/browse/TS-2830 Project: Traffic Server Issue Type: Improvement Components: Core, SPDY Reporter: Alan M. Carroll Add configuration options for SPDY, both per port and global. See documentation for details. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2830) Make SPDY configurable.
[ https://issues.apache.org/jira/browse/TS-2830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14005528#comment-14005528 ] ASF subversion and git services commented on TS-2830: - Commit ada6b33e8b55a16acbb8d9580530e4c11fc24862 in trafficserver's branch refs/heads/master from [~amc] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=ada6b33 ] TS-2830 Make gcc 4.1.2 happy. Make SPDY configurable. --- Key: TS-2830 URL: https://issues.apache.org/jira/browse/TS-2830 Project: Traffic Server Issue Type: Improvement Components: Core, SPDY Reporter: Alan M. Carroll Add configuration options for SPDY, both per port and global. See documentation for details. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-1665) Remove traffic_shell
[ https://issues.apache.org/jira/browse/TS-1665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14005570#comment-14005570 ] ASF subversion and git services commented on TS-1665: - Commit 2369a1a499135ba146a74316f2ea424a75a75fb1 in trafficserver's branch refs/heads/master from [~zwoop] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=2369a1a ] TS-1665 Remove traffic_shell Remove traffic_shell Key: TS-1665 URL: https://issues.apache.org/jira/browse/TS-1665 Project: Traffic Server Issue Type: Improvement Components: Core Reporter: Phil Sorber Assignee: Leif Hedstrom Fix For: 5.0.0 Remove traffic_shell. traffic_shell is mostly dysfunctional, Linux specific wrappers that make the assumption that an Administrator has no idea what they are doing, while being entirely undocumented. We should remove it, which should make it a lot easier to get rid of the TCL dependency. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (TS-1665) Remove traffic_shell
[ https://issues.apache.org/jira/browse/TS-1665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-1665. --- Resolution: Fixed Remove traffic_shell Key: TS-1665 URL: https://issues.apache.org/jira/browse/TS-1665 Project: Traffic Server Issue Type: Improvement Components: Core Reporter: Phil Sorber Assignee: Leif Hedstrom Fix For: 5.0.0 Remove traffic_shell. traffic_shell is mostly dysfunctional, Linux specific wrappers that make the assumption that an Administrator has no idea what they are doing, while being entirely undocumented. We should remove it, which should make it a lot easier to get rid of the TCL dependency. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2723) Add new features for ts_lua.
[ https://issues.apache.org/jira/browse/TS-2723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] portl4t updated TS-2723: Attachment: 0002-TS-2723-add-new-features-for-ts_lua.patch I remove some features out, including: ts.shared.DICT ts.re.match (relys on ts.shared.DICT) ts.base64_encoding ts.base64_decoding ts.escape_uri ts.unescape_uri ts.http.redirect (remove http_ctx-rri) We can refine base64 encoding and uri encoding later. Add new features for ts_lua. Key: TS-2723 URL: https://issues.apache.org/jira/browse/TS-2723 Project: Traffic Server Issue Type: Bug Components: Lua, Plugins Reporter: portl4t Assignee: Kit Chan Fix For: 5.0.0 Attachments: 0001-TS-2723-add-new-features-for-ts_lua.patch, 0001-TS-2723-refine-doc-for-ts_lua.patch, 0002-TS-2723-add-new-features-for-ts_lua.patch After TS-2555, Kit Chan and me will integrate new features from https://github.com/portl4t/ts-lua into plugins/experimental/ts_lua. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2801) Enabling SPDY can cause page corruptions
[ https://issues.apache.org/jira/browse/TS-2801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14005640#comment-14005640 ] Leif Hedstrom commented on TS-2801: --- I enabled SPDY again, and so far no corruptions. Enabling SPDY can cause page corruptions Key: TS-2801 URL: https://issues.apache.org/jira/browse/TS-2801 Project: Traffic Server Issue Type: Bug Components: SPDY Reporter: Leif Hedstrom Fix For: 5.0.0 Attachments: Screenshot 2014-05-12 at 05.06.15 PM.png When I build ATS with SPDY support, I see (sometimes) severe page corruptions on my site. What's even odd, these corruptions happens even more frequently from browsers which do not support SPDY. Disabling SPDY from the build fixes the issues, and regular HTTPS traffic is no long corrupted. See the attached screenschot from a corruption from https://www.ogre.com using a non-SPDY browser. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2801) Enabling SPDY can cause page corruptions
[ https://issues.apache.org/jira/browse/TS-2801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2801: -- Fix Version/s: (was: sometime) 5.0.0 Enabling SPDY can cause page corruptions Key: TS-2801 URL: https://issues.apache.org/jira/browse/TS-2801 Project: Traffic Server Issue Type: Bug Components: SPDY Reporter: Leif Hedstrom Fix For: 5.0.0 Attachments: Screenshot 2014-05-12 at 05.06.15 PM.png When I build ATS with SPDY support, I see (sometimes) severe page corruptions on my site. What's even odd, these corruptions happens even more frequently from browsers which do not support SPDY. Disabling SPDY from the build fixes the issues, and regular HTTPS traffic is no long corrupted. See the attached screenschot from a corruption from https://www.ogre.com using a non-SPDY browser. -- This message was sent by Atlassian JIRA (v6.2#6252)
