[jira] [Updated] (TS-2697) We should version the apichecker.pl script
[
https://issues.apache.org/jira/browse/TS-2697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll updated TS-2697:
Fix Version/s: (was: 5.1.0)
5.2.0
We should version the apichecker.pl script
Key: TS-2697
URL: https://issues.apache.org/jira/browse/TS-2697
Project: Traffic Server
Issue Type: Improvement
Components: Tools, TS API
Reporter: Leif Hedstrom
Assignee: Bryan Call
Fix For: 5.2.0
We should have two data sets:
{code}
v2tov3
v4tov5
{code}
and the default is to use the last one, with an option to use another (or
both). The way the script works, it's not useful for most people to see the
old v2tov3 API changes.
As part of this, we should also assure that all API changes that have already
gone into v5.0.0 has appropriate configuration in the v4tov5 data set.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2718) header_rewrite does some unorthodox const casting around Resource class
[ https://issues.apache.org/jira/browse/TS-2718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-2718: Fix Version/s: (was: 5.1.0) sometime header_rewrite does some unorthodox const casting around Resource class --- Key: TS-2718 URL: https://issues.apache.org/jira/browse/TS-2718 Project: Traffic Server Issue Type: Improvement Components: Plugins Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: sometime We should eliminate that. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2703) Add a text log feature for the escalate plugin
[ https://issues.apache.org/jira/browse/TS-2703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-2703: Fix Version/s: (was: 5.1.0) 6.0.0 Add a text log feature for the escalate plugin -- Key: TS-2703 URL: https://issues.apache.org/jira/browse/TS-2703 Project: Traffic Server Issue Type: New Feature Components: Plugins Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 6.0.0 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2785) Warnings from configure and sphinx / python
[
https://issues.apache.org/jira/browse/TS-2785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll updated TS-2785:
Fix Version/s: (was: 5.1.0)
Warnings from configure and sphinx / python
---
Key: TS-2785
URL: https://issues.apache.org/jira/browse/TS-2785
Project: Traffic Server
Issue Type: Bug
Components: Configuration, Documentation
Reporter: Leif Hedstrom
Assignee: Phil Sorber
On RHEL5, we get this error when running configure:
{code}
checking for python script directory... ${prefix}/lib/python2.4/site-packages
File ./doc/conf.py, line 401
except Exception as e:
^
SyntaxError: invalid syntax
File ./doc/conf.py, line 401
except Exception as e:
^
SyntaxError: invalid syntax
File ./doc/conf.py, line 401
except Exception as e:
^
SyntaxError: invalid syntax
File ./doc/conf.py, line 401
except Exception as e:
^
SyntaxError: invalid syntax
File ./doc/conf.py, line 401
except Exception as e:
^
SyntaxError: invalid syntax
checking for sphinx-build... false
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Closed] (TS-2785) Warnings from configure and sphinx / python
[
https://issues.apache.org/jira/browse/TS-2785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll closed TS-2785.
---
Resolution: Won't Fix
This is really hard to fix and not easily reproducible.
Warnings from configure and sphinx / python
---
Key: TS-2785
URL: https://issues.apache.org/jira/browse/TS-2785
Project: Traffic Server
Issue Type: Bug
Components: Configuration, Documentation
Reporter: Leif Hedstrom
Assignee: Phil Sorber
On RHEL5, we get this error when running configure:
{code}
checking for python script directory... ${prefix}/lib/python2.4/site-packages
File ./doc/conf.py, line 401
except Exception as e:
^
SyntaxError: invalid syntax
File ./doc/conf.py, line 401
except Exception as e:
^
SyntaxError: invalid syntax
File ./doc/conf.py, line 401
except Exception as e:
^
SyntaxError: invalid syntax
File ./doc/conf.py, line 401
except Exception as e:
^
SyntaxError: invalid syntax
File ./doc/conf.py, line 401
except Exception as e:
^
SyntaxError: invalid syntax
checking for sphinx-build... false
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2796) Leaking CacheVConnections
[ https://issues.apache.org/jira/browse/TS-2796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-2796: Fix Version/s: (was: 5.1.0) 5.2.0 Leaking CacheVConnections - Key: TS-2796 URL: https://issues.apache.org/jira/browse/TS-2796 Project: Traffic Server Issue Type: Bug Components: Cache Affects Versions: 4.2.1, 5.0.0 Reporter: Brian Geffon Assignee: Brian Geffon Labels: yahoo Fix For: 5.2.0 It appears there is a memory leak in 4.0.x, 4.2.x, and master leaking CacheVConnections resulting in IOBufAllocator leaking also, here is an example: allocated |in-use | type size | free list name 67108864 | 0 |2097152 | memory/ioBufAllocator[14] 67108864 | 19922944 |1048576 | memory/ioBufAllocator[13] 4798283776 | 14155776 | 524288 | memory/ioBufAllocator[12] 7281311744 | 98304000 | 262144 | memory/ioBufAllocator[11] 1115684864 | 148242432 | 131072 | memory/ioBufAllocator[10] 497544 | 379977728 | 65536 | memory/ioBufAllocator[9] 9902751744 | 5223546880 | 32768 | memory/ioBufAllocator[8] 14762901504 |14762311680 | 16384 | memory/ioBufAllocator[7] 6558056448 | 6557859840 | 8192 | memory/ioBufAllocator[6] 41418752 | 30502912 | 4096 | memory/ioBufAllocator[5] 524288 | 0 | 2048 | memory/ioBufAllocator[4] 0 | 0 | 1024 | memory/ioBufAllocator[3] 0 | 0 |512 | memory/ioBufAllocator[2] 32768 | 0 |256 | memory/ioBufAllocator[1] 0 | 0 |128 | memory/ioBufAllocator[0] 2138112 |2124192 |928 | memory/cacheVConnection [~bcall] has observed this issue on 4.0.x, and we have observed this on 4.2.x. The code path in CacheVC that is allocating the IoBuffers is memory/IOBuffer/Cache.cc:2603; however, that's just the observable symptom the real issue here is the leaking CacheVC. -- 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
]
Alan M. Carroll updated TS-2794:
Fix Version/s: (was: 5.1.0)
5.2.0
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.2.0
Attachments: extend-tsxs.diff, 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] [Assigned] (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 ] Alan M. Carroll reassigned TS-2827: --- Assignee: Alan M. Carroll 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 Assignee: Alan M. Carroll Fix For: 6.0.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] [Updated] (TS-2790) remove deprecated VConnection::do_io
[
https://issues.apache.org/jira/browse/TS-2790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll updated TS-2790:
Fix Version/s: (was: 5.1.0)
5.2.0
remove deprecated VConnection::do_io
Key: TS-2790
URL: https://issues.apache.org/jira/browse/TS-2790
Project: Traffic Server
Issue Type: Bug
Components: Cleanup, Core
Reporter: James Peach
Fix For: 5.2.0
{{VConnection::do_io}} is marked as deprecated and has probably been
deprecated forever. We should remove this code and fix all the callers to use
the more specific API.
--
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 ] Alan M. Carroll updated TS-2827: Fix Version/s: (was: 5.1.0) 6.0.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: 6.0.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] [Updated] (TS-2836) TS attempt to connect to dead server at least once
[ https://issues.apache.org/jira/browse/TS-2836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-2836: Fix Version/s: (was: 5.1.0) 5.2.0 TS attempt to connect to dead server at least once -- Key: TS-2836 URL: https://issues.apache.org/jira/browse/TS-2836 Project: Traffic Server Issue Type: Bug Affects Versions: 4.0.2, 5.0.0 Reporter: Masakazu Kitajo Fix For: 5.2.0 Even if I set proxy.config.http.connect_attempts_max_retries_dead_server to 0, Traffic Server attempt to connect to dead server. || The configuration value || Number of times TS attempt to connect || | 0 | 1 | | 1 | 1 | | 2 | 2 | | 3 | 3 | -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2835) Remove some dead code in ParseRules
[
https://issues.apache.org/jira/browse/TS-2835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll updated TS-2835:
Fix Version/s: (was: 5.1.0)
5.2.0
Remove some dead code in ParseRules
---
Key: TS-2835
URL: https://issues.apache.org/jira/browse/TS-2835
Project: Traffic Server
Issue Type: Improvement
Components: Cleanup
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
Fix For: 5.2.0
I'd like to remove the #iffdef's around
{code}
COMPILE_PARSE_RULES
{code}
and
{code}
THIS_IS_THE_ORIGINAL_CODE
{code}
In the ParseRules.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Closed] (TS-2828) Increase HostDB default sizes
[ https://issues.apache.org/jira/browse/TS-2828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll closed TS-2828. --- Resolution: Won't Fix Too much for default, easy to adjust. 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.1.0 Alan suggests 128MB / 256K entries. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2836) TS attempt to connect to dead server at least once
[ https://issues.apache.org/jira/browse/TS-2836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14083052#comment-14083052 ] Alan M. Carroll commented on TS-2836: - We have no idea what the expected behavior is - should a value of 0 mean never connect to an origin server? TS attempt to connect to dead server at least once -- Key: TS-2836 URL: https://issues.apache.org/jira/browse/TS-2836 Project: Traffic Server Issue Type: Bug Affects Versions: 4.0.2, 5.0.0 Reporter: Masakazu Kitajo Fix For: 5.2.0 Even if I set proxy.config.http.connect_attempts_max_retries_dead_server to 0, Traffic Server attempt to connect to dead server. || The configuration value || Number of times TS attempt to connect || | 0 | 1 | | 1 | 1 | | 2 | 2 | | 3 | 3 | -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2860) AArch64 support
[ https://issues.apache.org/jira/browse/TS-2860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-2860: Assignee: Phil Sorber (was: Leif Hedstrom) AArch64 support --- Key: TS-2860 URL: https://issues.apache.org/jira/browse/TS-2860 Project: Traffic Server Issue Type: New Feature Components: Build, Portability Reporter: Marcin Juszkiewicz Assignee: Phil Sorber Fix For: 5.1.0 Attachments: trafficserver-aarch64.patch Out of the box traffic server does not build on AArch64 (64-bit ARM) architecture. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (TS-2840) CPU affinity for SSL threads (and possibly others?)
[ https://issues.apache.org/jira/browse/TS-2840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll closed TS-2840. --- Resolution: Won't Fix Fix Version/s: (was: 5.1.0) By default SSL processing has been moved to normal NET threads which have affinity. Long term the SSL threads will be completely removed so this is not useful. CPU affinity for SSL threads (and possibly others?) --- Key: TS-2840 URL: https://issues.apache.org/jira/browse/TS-2840 Project: Traffic Server Issue Type: Improvement Components: Core, SSL Reporter: Leif Hedstrom After discussions on IRC, it sounds like we don't have / support affinity for the SSL threads? -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (TS-2864) Remove old server_port / server_port_attr configurations
[ https://issues.apache.org/jira/browse/TS-2864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll resolved TS-2864. - Resolution: Fixed Remove old server_port / server_port_attr configurations Key: TS-2864 URL: https://issues.apache.org/jira/browse/TS-2864 Project: Traffic Server Issue Type: Bug Components: Configuration Reporter: Leif Hedstrom Assignee: Alan M. Carroll Fix For: 5.1.0 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Reopened] (TS-2864) Remove old server_port / server_port_attr configurations
[ https://issues.apache.org/jira/browse/TS-2864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll reopened TS-2864: - Remove stuff in records.config. Remove old server_port / server_port_attr configurations Key: TS-2864 URL: https://issues.apache.org/jira/browse/TS-2864 Project: Traffic Server Issue Type: Bug Components: Configuration Reporter: Leif Hedstrom Assignee: Alan M. Carroll Fix For: 5.1.0 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2884) TSActionCancel() on TSNetAccept() causes spinning thread
[ https://issues.apache.org/jira/browse/TS-2884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-2884: Fix Version/s: (was: 5.1.0) sometime TSActionCancel() on TSNetAccept() causes spinning thread Key: TS-2884 URL: https://issues.apache.org/jira/browse/TS-2884 Project: Traffic Server Issue Type: Bug Components: Network Reporter: William Bardwell Priority: Minor Fix For: sometime It looks like the NetAccept::acceptLoopEvent() just loops calling do_blocking_accept() and doesn't check for an error return value... -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2871) traffic_line not accepting certain int values
[ https://issues.apache.org/jira/browse/TS-2871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-2871: Fix Version/s: (was: 5.1.0) 5.2.0 traffic_line not accepting certain int values - Key: TS-2871 URL: https://issues.apache.org/jira/browse/TS-2871 Project: Traffic Server Issue Type: Bug Components: Configuration Reporter: Bryan Call Fix For: 5.2.0 traffic_line has problem with accepting values like -1 and 2147483648 for configuration option that have those as acceptable integer values. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2888) Fix build_error_response() to not take a vararg and perhaps not even a format
[ https://issues.apache.org/jira/browse/TS-2888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-2888: Fix Version/s: (was: 5.1.0) 6.0.0 Fix build_error_response() to not take a vararg and perhaps not even a format - Key: TS-2888 URL: https://issues.apache.org/jira/browse/TS-2888 Project: Traffic Server Issue Type: Improvement Components: Core, HTTP Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 6.0.0 As the body factory is now required, build_error_response() has a legacy option which generally is not used (except one case which I'm hoping to fix as well). I've already fixed most usage as part of TS-2886, those additional format strings would never have been used after we made body factory mandatory. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2883) core dump in TSFetchCreate()
[
https://issues.apache.org/jira/browse/TS-2883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll updated TS-2883:
Assignee: Bryan Call
core dump in TSFetchCreate()
Key: TS-2883
URL: https://issues.apache.org/jira/browse/TS-2883
Project: Traffic Server
Issue Type: Bug
Components: Core, SPDY
Reporter: Sudheer Vinukonda
Assignee: Bryan Call
Labels: crash
Fix For: 5.1.0
Attachments: TS-2883.diff
{code}
(gdb) bt
#0 ink_freelist_new (f=0x2923050) at ink_queue.cc:202
#1 0x004c0cd2 in alloc (contp=0x2b86821e2120,
method=TS_FETCH_METHOD_POST,
url=0x2b865d64f228
https://aa-mg5.mail.yahoo.com/ws/mail/v2.0/jsonrpc?appid=YahooMailNeom=BatchExecutewssid=nG7kmTWsJCDaction=compose_0_savedraftactionCount=88debugmid=2_0_0_3_126623_AMNwimIAAC82U5ZXLwAAAFWGrR8deb;...,
version=0x2b865da5ace8 HTTP/1.1, client_addr=value optimized out,
flags=value optimized out) at ../lib/ts/Allocator.h:117
#2 TSFetchCreate (contp=0x2b86821e2120, method=TS_FETCH_METHOD_POST,
url=0x2b865d64f228
https://aa-mg5.mail.yahoo.com/ws/mail/v2.0/jsonrpc?appid=YahooMailNeom=BatchExecutewssid=nG7kmTWsJCDaction=compose_0_savedraftactionCount=88debugmid=2_0_0_3_126623_AMNwimIAAC82U5ZXLwAAAFWGrR8deb;...,
version=0x2b865da5ace8 HTTP/1.1, client_addr=value optimized out,
flags=value optimized out) at InkAPI.cc:7289
#3 0x005f117e in spdy_fetcher_launch (req=0x2b871c2fa900,
method=TS_FETCH_METHOD_POST) at SpdyCallbacks.cc:187
#4 0x005f1faa in spdy_process_syn_stream_frame (session=value
optimized out, type=value optimized out, frame=value optimized out,
user_data=0x2b86821e2120)
at SpdyCallbacks.cc:295
#5 spdy_on_ctrl_recv_callback (session=value optimized out, type=value
optimized out, frame=value optimized out, user_data=0x2b86821e2120) at
SpdyCallbacks.cc:335
#6 0x00738050 in spdylay_session_on_syn_stream_received
(session=0x2b865defce10, frame=0x2b858f987a20) at spdylay_session.c:1782
#7 0x00738d57 in spdylay_session_process_ctrl_frame
(session=0x2b865defce10, in=0x2b858f987a90 \200\003, inlen=value optimized
out) at spdylay_session.c:2246
#8 spdylay_session_mem_recv (session=0x2b865defce10, in=0x2b858f987a90
\200\003, inlen=value optimized out) at spdylay_session.c:2805
#9 0x00738f89 in spdylay_session_recv (session=0x2b865defce10) at
spdylay_session.c:2828
#10 0x005ef17b in spdy_process_read (this=0x2b86821e2120, event=100,
edata=value optimized out) at SpdyClientSession.cc:279
#11 SpdyClientSession::state_session_readwrite (this=0x2b86821e2120,
event=100, edata=value optimized out) at SpdyClientSession.cc:236
#12 0x0070dbd7 in handleEvent (this=0x2b86fc1d2cf0, event=value
optimized out) at ../../iocore/eventsystem/I_Continuation.h:146
#13 read_signal_and_update (this=0x2b86fc1d2cf0, event=value optimized out)
at UnixNetVConnection.cc:138
#14 UnixNetVConnection::readSignalAndUpdate (this=0x2b86fc1d2cf0,
event=value optimized out) at UnixNetVConnection.cc:914
#15 0x006fe66f in SSLNetVConnection::net_read_io
(this=0x2b86fc1d2cf0, nh=0x2b858d46bbf0, lthread=0x2b858d468010) at
SSLNetVConnection.cc:294
#16 0x00705a72 in NetHandler::mainNetEvent (this=0x2b858d46bbf0,
event=value optimized out, e=value optimized out) at UnixNet.cc:399
#17 0x007323ef in handleEvent (this=0x2b858d468010, e=0x2a7db30,
calling_code=5) at I_Continuation.h:146
#18 EThread::process_event (this=0x2b858d468010, e=0x2a7db30, calling_code=5)
at UnixEThread.cc:145
#19 0x00732d93 in EThread::execute (this=0x2b858d468010) at
UnixEThread.cc:269
#20 0x0073179a in spawn_thread_internal (a=0x2e404e0) at Thread.cc:88
#21 0x2b835bf28851 in start_thread () from /lib64/libpthread.so.0
#22 0x00361a0e894d in clone () from /lib64/libc.so.6
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2890) Core dump in spdylay_submit_syn_reply
[
https://issues.apache.org/jira/browse/TS-2890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll updated TS-2890:
Fix Version/s: (was: 5.1.0)
5.2.0
Core dump in spdylay_submit_syn_reply
-
Key: TS-2890
URL: https://issues.apache.org/jira/browse/TS-2890
Project: Traffic Server
Issue Type: Bug
Components: SPDY
Reporter: Sudheer Vinukonda
Fix For: 5.2.0
session object seems to be fine in spdy_process_fetch_header(), but, is null
inside spdylay_submit_syn_reply() resulting in a crash. Based on the stack
trace, this looks to be spdy connection on http port.
{code}
#0 spdylay_submit_syn_reply (session=0x0, flags=0 '\000', stream_id=33,
nv=0x2ba4dc1d9c90) at spdylay_submit.c:137
#1 0x005ef804 in spdy_process_fetch_header (this=0x2ba62cbdc880,
event=-2, edata=0x2ba68aa47a60) at SpdyClientSession.cc:366
#2 spdy_process_fetch (this=0x2ba62cbdc880, event=-2, edata=0x2ba68aa47a60)
at SpdyClientSession.cc:321
#3 SpdyClientSession::state_session_readwrite (this=0x2ba62cbdc880,
event=-2, edata=0x2ba68aa47a60) at SpdyClientSession.cc:251
#4 0x004a46da in handleEvent (this=0x2ba68aa47a60, error_event=0) at
../iocore/eventsystem/I_Continuation.h:146
#5 FetchSM::InvokePluginExt (this=0x2ba68aa47a60, error_event=0) at
FetchSM.cc:233
#6 0x004a4bb7 in FetchSM::process_fetch_read (this=0x2ba68aa47a60,
event=value optimized out) at FetchSM.cc:400
#7 0x004a4d6b in FetchSM::fetch_handler (this=0x2ba68aa47a60,
event=104, edata=0x2ba670cf8a18) at FetchSM.cc:449
#8 0x004dd82a in PluginVC::process_read_side (this=0x2ba670cf8920,
other_side_call=false) at PluginVC.cc:637
#9 0x004df81a in PluginVC::main_handler (this=0x2ba670cf8920,
event=value optimized out, data=0x2ba539202740) at PluginVC.cc:208
#10 0x0073409f in handleEvent (this=0x2ba3b2323010, e=0x2ba539202740,
calling_code=1) at I_Continuation.h:146
#11 EThread::process_event (this=0x2ba3b2323010, e=0x2ba539202740,
calling_code=1) at UnixEThread.cc:145
#12 0x00734c73 in EThread::execute (this=0x2ba3b2323010) at
UnixEThread.cc:239
#13 0x0073344a in spawn_thread_internal (a=0x2645060) at Thread.cc:88
#14 0x2ba3aaf15851 in start_thread () from /lib64/libpthread.so.0
#15 0x0038818e894d in clone () from /lib64/libc.so.6
(gdb) print session
$36 = (spdylay_session *) 0x0
(gdb) up
#1 0x005ef804 in spdy_process_fetch_header (this=0x2ba62cbdc880,
event=-2, edata=0x2ba68aa47a60) at SpdyClientSession.cc:366
366 SpdyClientSession.cc: No such file or directory.
in SpdyClientSession.cc
(gdb) print sm-session
$37 = (spdylay_session *) 0x2ba56ad12130
(gdb) print *sm-session
$38 = {streams = {table = 0x2ba5689b86d0, tablelen = 16, size = 0}, ob_pq =
{q = 0x2ba56989df50, length = 0, capacity = 4096, compar = 0x736a50
spdylay_outbound_item_compar}, ob_ss_pq = {
q = 0x2ba5681edfd0, length = 0, capacity = 4096, compar = 0x736a50
spdylay_outbound_item_compar}, aob = {item = 0x0, framebuf = 0x2ba64d7e4be0
\200\003, framebufmax = 4104,
framebuflen = 0, framebufoff = 0}, iframe = {inflatebuf = {capacity =
4096, root = {data = 0x0, next = 0x0}, current = 0x2ba56ad121b8, len = 0,
last_offset = 4096},
buf = 0x2ba56913a3c0 \300\235'k\245+, headbufoff = 0, bufmax = 4104,
buflen = 0, payloadlen = 0, off = 0, state = SPDYLAY_RECV_HEAD, error_code =
0,
headbuf = \000\000\000\000\000\000\000}, hd_deflater = {zst = {next_in
= 0x0, avail_in = 0, total_in = 0, next_out = 0x0, avail_out = 0, total_out =
0, msg = 0x0,
state = 0x2ba64f2b6900, zalloc = 0x3882408da0 zcalloc, zfree =
0x3882408d90 zcfree, opaque = 0x0, data_type = 2, adler = 3821447106,
reserved = 0}, version = 3}, hd_inflater = {
zst = {next_in = 0x0, avail_in = 0, total_in = 0, next_out = 0x0,
avail_out = 0, total_out = 0, msg = 0x0, state = 0x2ba64cb426e0, zalloc =
0x3882408da0 zcalloc,
zfree = 0x3882408d90 zcfree, opaque = 0x0, data_type = 0, adler = 1,
reserved = 0}, version = 3}, cli_certvec = {vector = 0x0, size = 0, capacity
= 0, last_slot = 0}, callbacks = {
send_callback = 0x5f15b0 spdy_send_callback(spdylay_session*, uint8_t
const*, size_t, int, void*),
recv_callback = 0x5f14f0 spdy_recv_callback(spdylay_session*, uint8_t*,
size_t, int, void*),
on_ctrl_recv_callback = 0x5f1fc0
spdy_on_ctrl_recv_callback(spdylay_session*, spdylay_frame_type,
spdylay_frame*, void*),
on_invalid_ctrl_recv_callback = 0x5f1000
spdy_on_invalid_ctrl_recv_callback(spdylay_session*, spdylay_frame_type,
spdylay_frame*, uint32_t, void*),
on_data_chunk_recv_callback = 0x5f1ce0
spdy_on_data_chunk_recv_callback(spdylay_session*, uint8_t, int32_t, uint8_t
[jira] [Updated] (TS-2897) enable-linux-native-aio X SSL
[
https://issues.apache.org/jira/browse/TS-2897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll updated TS-2897:
Assignee: Brian Geffon
enable-linux-native-aio X SSL
--
Key: TS-2897
URL: https://issues.apache.org/jira/browse/TS-2897
Project: Traffic Server
Issue Type: Bug
Components: Core
Affects Versions: 5.0.0
Reporter: Daniel Picolli Biazus
Assignee: Brian Geffon
Labels: crash, review
Fix For: 5.2.0
Hi Guys,
I could notice that ATS 5.0 is crashing when it is compiled with
--enable-linux-native-aio option and serving over SSL connections.
I got the following stack trace:
[alts] alternate #1 (Q = 1) has these request/response hdrs:
GET http://127.0.0.1:8080/file.mp4?n=1 HTTP/1.1
User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.15.3
zlib/1.2.3 libidn/1.18 libssh2/1.4.2
Accept: */*
Host: 127.0.0.1:8080
Client-ip: xxx.xxx.xxx.xxx
X-Forwarded-For: xxx.xxx.xxx.xxx
HTTP/1.1 200 OK
Server: nginx/1.0.15
Date: Wed, 25 Jun 2014 18:26:39 GMT
Content-Type: video/mp4
Content-Length: 9455997
Last-Modified: Wed, 25 Jun 2014 18:23:52 GMT
Connection: keep-alive
Expires: Wed, 25 Jun 2014 18:31:39 GMT
Cache-Control: max-age=300
Accept-Ranges: bytes
[Jun 25 18:26:41.975] Server {0x7f0c05699700} DEBUG: (http_seq)
[SelectFromAlternates] Chosen alternate # 0
[alts] and the winner is alternate number 1
NOTE: Traffic Server received Sig 11: Segmentation fault
./bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0(+0xf710)[0x7f0c0a357710]
./bin/traffic_server(_Z12ink_aio_readP11AIOCallbacki+0x26)[0x6f7406]
./bin/traffic_server(_ZN7CacheVC10handleReadEiP5Event+0x292)[0x6af1e2]
./bin/traffic_server(_ZN7CacheVC21openReadStartEarliestEiP5Event+0x336)[0x6d72a6]
./bin/traffic_server(_ZN7CacheVC17openReadStartHeadEiP5Event+0x91c)[0x6d821c]
./bin/traffic_server(_ZN7CacheVC14handleReadDoneEiP5Event+0x42c)[0x6b63bc]
./bin/traffic_server(_ZN5Cache9open_readEP12ContinuationP7INK_MD5P7HTTPHdrP21CacheLookupHttpConfig13CacheFragTypePci+0x363)[0x6db9f3]
./bin/traffic_server(_ZN14CacheProcessor9open_readEP12ContinuationP3URLbP7HTTPHdrP21CacheLookupHttpConfigl13CacheFragType+0xad)[0x6b514d]
./bin/traffic_server(_ZN11HttpCacheSM9open_readEP3URLP7HTTPHdrP21CacheLookupHttpConfigl+0x94)[0x581424]
./bin/traffic_server(_ZN6HttpSM24do_cache_lookup_and_readEv+0xf3)[0x58f543]
./bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x714)[0x5a66c4]
./bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x2d2)[0x5a8302]
./bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x1f2)[0x5a61a2]
./bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x806)[0x5a67b6]
./bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x2d2)[0x5a8302]
./bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x1f2)[0x5a61a2]
./bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x2d2)[0x5a8302]
./bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x1f2)[0x5a61a2]
./bin/traffic_server(_ZN6HttpSM32state_read_client_request_headerEiPv+0x225)[0x59f735]
./bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0xd8)[0x5a32b8]
./bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x388)[0x5a83b8]
./bin/traffic_server(_ZN6HttpSM21attach_client_sessionEP17HttpClientSessionP14IOBufferReader+0x635)[0x5a4025]
./bin/traffic_server(_ZN17HttpClientSession15new_transactionEv+0x9d)[0x5823ed]
./bin/traffic_server(_ZN17HttpClientSession14new_connectionEP14NetVConnectionbP9MIOBufferP14IOBufferReader+0x2b7)[0x5846f7]
./bin/traffic_server(_ZN17HttpSessionAccept6acceptEP14NetVConnectionP9MIOBufferP14IOBufferReader+0x1de)[0x57e7fe]
./bin/traffic_server(_ZN23ProtocolProbeTrampoline17ioCompletionEventEiPv+0x5be)[0x4e916e]
./bin/traffic_server(_ZN18UnixNetVConnection19readSignalAndUpdateEi+0x27)[0x70b887]
./bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0xebf)[0x6fc2bf]
./bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x1f2)[0x703722]
./bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x73012f]
./bin/traffic_server(_ZN7EThread7executeEv+0x493)[0x730ad3]
./bin/traffic_server[0x72f4da]
/lib64/libpthread.so.0(+0x79d1)[0x7f0c0a34f9d1]
/lib64/libc.so.6(clone+0x6d)[0x7f0c096f8b5d]
Segmentation fault
This behavior is easily reproduced configuring ATS as a reverse proxy with a
single origin serving over SSL with --enable-linux-native-aio enabled.
Any thoughts ?
Thanks Regards,
Daniel
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2897) enable-linux-native-aio X SSL
[
https://issues.apache.org/jira/browse/TS-2897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll updated TS-2897:
Fix Version/s: (was: 5.1.0)
5.2.0
enable-linux-native-aio X SSL
--
Key: TS-2897
URL: https://issues.apache.org/jira/browse/TS-2897
Project: Traffic Server
Issue Type: Bug
Components: Core
Affects Versions: 5.0.0
Reporter: Daniel Picolli Biazus
Labels: crash, review
Fix For: 5.2.0
Hi Guys,
I could notice that ATS 5.0 is crashing when it is compiled with
--enable-linux-native-aio option and serving over SSL connections.
I got the following stack trace:
[alts] alternate #1 (Q = 1) has these request/response hdrs:
GET http://127.0.0.1:8080/file.mp4?n=1 HTTP/1.1
User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.15.3
zlib/1.2.3 libidn/1.18 libssh2/1.4.2
Accept: */*
Host: 127.0.0.1:8080
Client-ip: xxx.xxx.xxx.xxx
X-Forwarded-For: xxx.xxx.xxx.xxx
HTTP/1.1 200 OK
Server: nginx/1.0.15
Date: Wed, 25 Jun 2014 18:26:39 GMT
Content-Type: video/mp4
Content-Length: 9455997
Last-Modified: Wed, 25 Jun 2014 18:23:52 GMT
Connection: keep-alive
Expires: Wed, 25 Jun 2014 18:31:39 GMT
Cache-Control: max-age=300
Accept-Ranges: bytes
[Jun 25 18:26:41.975] Server {0x7f0c05699700} DEBUG: (http_seq)
[SelectFromAlternates] Chosen alternate # 0
[alts] and the winner is alternate number 1
NOTE: Traffic Server received Sig 11: Segmentation fault
./bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0(+0xf710)[0x7f0c0a357710]
./bin/traffic_server(_Z12ink_aio_readP11AIOCallbacki+0x26)[0x6f7406]
./bin/traffic_server(_ZN7CacheVC10handleReadEiP5Event+0x292)[0x6af1e2]
./bin/traffic_server(_ZN7CacheVC21openReadStartEarliestEiP5Event+0x336)[0x6d72a6]
./bin/traffic_server(_ZN7CacheVC17openReadStartHeadEiP5Event+0x91c)[0x6d821c]
./bin/traffic_server(_ZN7CacheVC14handleReadDoneEiP5Event+0x42c)[0x6b63bc]
./bin/traffic_server(_ZN5Cache9open_readEP12ContinuationP7INK_MD5P7HTTPHdrP21CacheLookupHttpConfig13CacheFragTypePci+0x363)[0x6db9f3]
./bin/traffic_server(_ZN14CacheProcessor9open_readEP12ContinuationP3URLbP7HTTPHdrP21CacheLookupHttpConfigl13CacheFragType+0xad)[0x6b514d]
./bin/traffic_server(_ZN11HttpCacheSM9open_readEP3URLP7HTTPHdrP21CacheLookupHttpConfigl+0x94)[0x581424]
./bin/traffic_server(_ZN6HttpSM24do_cache_lookup_and_readEv+0xf3)[0x58f543]
./bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x714)[0x5a66c4]
./bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x2d2)[0x5a8302]
./bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x1f2)[0x5a61a2]
./bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x806)[0x5a67b6]
./bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x2d2)[0x5a8302]
./bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x1f2)[0x5a61a2]
./bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x2d2)[0x5a8302]
./bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x1f2)[0x5a61a2]
./bin/traffic_server(_ZN6HttpSM32state_read_client_request_headerEiPv+0x225)[0x59f735]
./bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0xd8)[0x5a32b8]
./bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x388)[0x5a83b8]
./bin/traffic_server(_ZN6HttpSM21attach_client_sessionEP17HttpClientSessionP14IOBufferReader+0x635)[0x5a4025]
./bin/traffic_server(_ZN17HttpClientSession15new_transactionEv+0x9d)[0x5823ed]
./bin/traffic_server(_ZN17HttpClientSession14new_connectionEP14NetVConnectionbP9MIOBufferP14IOBufferReader+0x2b7)[0x5846f7]
./bin/traffic_server(_ZN17HttpSessionAccept6acceptEP14NetVConnectionP9MIOBufferP14IOBufferReader+0x1de)[0x57e7fe]
./bin/traffic_server(_ZN23ProtocolProbeTrampoline17ioCompletionEventEiPv+0x5be)[0x4e916e]
./bin/traffic_server(_ZN18UnixNetVConnection19readSignalAndUpdateEi+0x27)[0x70b887]
./bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0xebf)[0x6fc2bf]
./bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x1f2)[0x703722]
./bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x73012f]
./bin/traffic_server(_ZN7EThread7executeEv+0x493)[0x730ad3]
./bin/traffic_server[0x72f4da]
/lib64/libpthread.so.0(+0x79d1)[0x7f0c0a34f9d1]
/lib64/libc.so.6(clone+0x6d)[0x7f0c096f8b5d]
Segmentation fault
This behavior is easily reproduced configuring ATS as a reverse proxy with a
single origin serving over SSL with --enable-linux-native-aio enabled.
Any thoughts ?
Thanks Regards,
Daniel
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2894) Spdy slow start..
[ https://issues.apache.org/jira/browse/TS-2894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-2894: Fix Version/s: (was: 5.1.0) sometime Spdy slow start.. - Key: TS-2894 URL: https://issues.apache.org/jira/browse/TS-2894 Project: Traffic Server Issue Type: Improvement Components: SPDY Reporter: Sudheer Vinukonda Assignee: Bryan Call Fix For: sometime Attachments: TS-2894.diff When production testing with spdy/5.0.0, we ran into an issue in some of our systems, where, the spdy hosts would flap constantly due to the flood of requests. We further noticed that, where the 4.0.x version or 5.0.0 w/ spdy turned off, would recover quickly following a restart, spdy enabled hosts would continue to receive flood of requests and continue to flap. During this time, traffic server is generally busy reading from the disk and can not handle too many requests, and is made miserable by spdy's support of multiple concurrent streams. To handle such a sudden flood of requests, I'm implementing a simple slow start mechanism with spdy. The idea is to increase the max_concurrent_streams_in gradually based on a configured timer, rather than use the configured value right away. The steps I chose to implement are 1, 25, 50, 75 and 100% of the configured max_concurrent_streams_in. Note that, currently, max_concurrent_streams_in only affects new spdy sessions. Existing sessions (if any) would continue to use their older values. Not too sure, if everyone would be interested in this..but, thought of still uploading my patch, incase, someone is interested. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2900) TSHttpConnect response includes chunk sizes
[ https://issues.apache.org/jira/browse/TS-2900?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-2900: Fix Version/s: (was: 5.1.0) 5.2.0 TSHttpConnect response includes chunk sizes --- Key: TS-2900 URL: https://issues.apache.org/jira/browse/TS-2900 Project: Traffic Server Issue Type: Bug Affects Versions: 5.0.0 Reporter: Peter Walsh Fix For: 5.2.0 I just upgraded from 4.2.1 to ATS 5.0.0 but am having issues in my plugins that use TSHttpConnect. When the response body is chunked, the response body being returned to my plugin includes the chunk sizes in the response string. In ATS 4.x, the plugins received the response body without the chunked sizes as part of it, meaning ATS handled this under the covers so my plugin didn't have to. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2905) Logging Fields (pqsi/shi) displays *Not IP address [0]* during TCP_HIT
[ https://issues.apache.org/jira/browse/TS-2905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-2905: Fix Version/s: (was: 5.2.0) 5.1.0 Logging Fields (pqsi/shi) displays *Not IP address [0]* during TCP_HIT Key: TS-2905 URL: https://issues.apache.org/jira/browse/TS-2905 Project: Traffic Server Issue Type: Bug Components: Logging Reporter: Avinash Katika Assignee: James Peach Priority: Minor Fix For: 5.1.0 When we are trying to log the fields(pqsi/shi) in access logs during TCP_HIT the value being displayed is *Not IP address [0]*.But we expect value displayed to be 0 as per the documentation. Version being used:4.2.1 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2905) Logging Fields (pqsi/shi) displays *Not IP address [0]* during TCP_HIT
[ https://issues.apache.org/jira/browse/TS-2905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-2905: Assignee: James Peach (was: Alan M. Carroll) Logging Fields (pqsi/shi) displays *Not IP address [0]* during TCP_HIT Key: TS-2905 URL: https://issues.apache.org/jira/browse/TS-2905 Project: Traffic Server Issue Type: Bug Components: Logging Reporter: Avinash Katika Assignee: James Peach Priority: Minor Fix For: 5.1.0 When we are trying to log the fields(pqsi/shi) in access logs during TCP_HIT the value being displayed is *Not IP address [0]*.But we expect value displayed to be 0 as per the documentation. Version being used:4.2.1 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (TS-2905) Logging Fields (pqsi/shi) displays *Not IP address [0]* during TCP_HIT
[ https://issues.apache.org/jira/browse/TS-2905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll reassigned TS-2905: --- Assignee: Alan M. Carroll Logging Fields (pqsi/shi) displays *Not IP address [0]* during TCP_HIT Key: TS-2905 URL: https://issues.apache.org/jira/browse/TS-2905 Project: Traffic Server Issue Type: Bug Components: Logging Reporter: Avinash Katika Assignee: Alan M. Carroll Priority: Minor Fix For: 5.1.0 When we are trying to log the fields(pqsi/shi) in access logs during TCP_HIT the value being displayed is *Not IP address [0]*.But we expect value displayed to be 0 as per the documentation. Version being used:4.2.1 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2912) HEAD transaction on stale entry deletes cache entry
[ https://issues.apache.org/jira/browse/TS-2912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2912: -- Labels: review (was: ) HEAD transaction on stale entry deletes cache entry --- Key: TS-2912 URL: https://issues.apache.org/jira/browse/TS-2912 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: William Bardwell Assignee: weijin Labels: review Fix For: 5.1.0 Attachments: ts-2912.try1.diff On a stale cache entry a HEAD gets tunneled to the origin, but when a 200 comes back HttpTransact::handle_cache_operation_on_forward_server_response(State* s) deletes the cache entry, it seems like it should just ignore it (or check ETag/Last-Modified and maybe delete if those don't match, but not unconditionally.) I am seeing this with 4.2.X with a plugin fiddling with stuff, but the code looks the same in trunk, line 4318 looks like the problem line. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2905) Logging Fields (pqsi/shi) displays *Not IP address [0]* during TCP_HIT
[ https://issues.apache.org/jira/browse/TS-2905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-2905: Fix Version/s: (was: 5.1.0) 5.2.0 Logging Fields (pqsi/shi) displays *Not IP address [0]* during TCP_HIT Key: TS-2905 URL: https://issues.apache.org/jira/browse/TS-2905 Project: Traffic Server Issue Type: Bug Components: Logging Reporter: Avinash Katika Priority: Minor Fix For: 5.1.0 When we are trying to log the fields(pqsi/shi) in access logs during TCP_HIT the value being displayed is *Not IP address [0]*.But we expect value displayed to be 0 as per the documentation. Version being used:4.2.1 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2914) LogField cquuh does not work for TSSkipRemappingSet
[ https://issues.apache.org/jira/browse/TS-2914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-2914: Fix Version/s: (was: 5.1.0) 5.2.0 LogField cquuh does not work for TSSkipRemappingSet --- Key: TS-2914 URL: https://issues.apache.org/jira/browse/TS-2914 Project: Traffic Server Issue Type: Bug Components: Logging, TS API Reporter: xiongzongtao Fix For: 5.2.0 if cquuh is set in logs_xml.config and TSSkipRemappingSet called in plugin log entry related to that plugin is not correct and not readable -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2917) luajit ignores --disable-silent-rules
[
https://issues.apache.org/jira/browse/TS-2917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll updated TS-2917:
Fix Version/s: (was: 5.1.0)
5.2.0
luajit ignores --disable-silent-rules
-
Key: TS-2917
URL: https://issues.apache.org/jira/browse/TS-2917
Project: Traffic Server
Issue Type: Bug
Components: Build
Reporter: Arno Toell
Assignee: Arno Toell
Priority: Minor
Fix For: 5.2.0
When compiling ATS with --disable-silent-rules the luajit tree ignores that
configure flag. Excerpt:
{code}
./configure --enable-layout=Debian --sysconfdir=/etc/trafficserver
--libdir=/usr/lib/trafficserver --with-user=root --with-group=root
--disable-silent-rules --enable-experimental-plugins
--enable-reclaimable-freelist CFLAGS=-g -O2 -fstack-protector
--param=ssp-buffer-size=4 -Wformat -Werror=format-security
CPPFLAGS=-D_FORTIFY_SOURCE=2 CXXFLAGS=-g -O2 -fstack-protector
--param=ssp-buffer-size=4 -Wformat -Werror=format-security FCFLAGS=-g -O2
-fstack-protector --param=ssp-buffer-size=4 FFLAGS=-g -O2 -fstack-protector
--param=ssp-buffer-size=4 GCJFLAGS=-g -O2 -fstack-protector
--param=ssp-buffer-size=4 LDFLAGS=-Wl,-z,relro OBJCFLAGS=-g -O2
-fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security
OBJCXXFLAGS=-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat
-Werror=format-security --enable-wccp --enable-linux-native-aio
...
make[3]: Entering directory
'/home/arno/trafficserver/trafficserver/iocore/eventsystem'
depbase=`echo EventSystem.o | sed 's|[^/]*$|.deps/|;s|\.o$||'`;\
c++ -DHAVE_CONFIG_H -I. -I../../lib/ts -I../../lib -I../../lib/records
-I../../lib/ts -D_FORTIFY_SOURCE=2 -Dlinux -D_LARGEFILE64_SOURCE=1
-D_COMPILE64BIT_SOURCE=1 -D_GNU_SOURCE -D_REENTRANT -I/usr/include/tcl8.6
-I/usr/include/libxml2 -Wunused-parameter -g -O2 -fstack-protector
--param=ssp-buffer-size=4 -Wformat -Werror=format-security -std=c++11 -pipe
-Wall -feliminate-unused-debug-symbols -fno-strict-aliasing
-Wno-invalid-offsetof -mcx16 -MT EventSystem.o -MD -MP -MF $depbase.Tpo -c -o
EventSystem.o EventSystem.cc \
mv -f $depbase.Tpo $depbase.Po
...
make[4]: Entering directory
'/home/arno/trafficserver/trafficserver/lib/luajit'
Building LuaJIT 2.0.3
make -C src
make[5]: Entering directory
'/home/arno/trafficserver/trafficserver/lib/luajit/src'
HOSTCChost/minilua.o
HOSTLINK host/minilua
DYNASMhost/buildvm_arch.h
...
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2916) combo_handler does not set the response headers properly
[ https://issues.apache.org/jira/browse/TS-2916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-2916: Fix Version/s: (was: 5.1.0) 5.2.0 combo_handler does not set the response headers properly Key: TS-2916 URL: https://issues.apache.org/jira/browse/TS-2916 Project: Traffic Server Issue Type: Bug Components: Plugins Reporter: Feifei Cai Assignee: Kit Chan Labels: review, yahoo Fix For: 5.2.0 Attachments: TS-2916.diff # Cache-Control: max-age=xxx combo_handler plugin should parse each url's max-age value in Cache-Control header, and use the minimal value in the response header. The hard-code 10 years max-age prevents cache from refresh, even though we have parsed the value in Expires headers. See [rfc2616-sec14.9.3|http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.3]: If a response includes both an Expires header and a max-age directive, the max-age directive overrides the Expires header, even if the Expires header is more restrictive. # Duplicated headers We add support for whitelist of headers in a recent [commit|https://github.com/apache/trafficserver/commit/f61b1b416f4bb99854c6b6c77b12f742b5af9ca8] When we have added headers specified in whitelist, we need to check for duplicated headers in the following response write actions. # Multiple values Some headers has multiple values, e.g. Cache-Control: max-age=3600, public. It has 2 values: max-age=3600 and public. We need to parse all the values for each header specified in whitelist. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2916) combo_handler does not set the response headers properly
[ https://issues.apache.org/jira/browse/TS-2916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14083087#comment-14083087 ] Alan M. Carroll commented on TS-2916: - Has there been any progress on the review? combo_handler does not set the response headers properly Key: TS-2916 URL: https://issues.apache.org/jira/browse/TS-2916 Project: Traffic Server Issue Type: Bug Components: Plugins Reporter: Feifei Cai Assignee: Kit Chan Labels: review, yahoo Fix For: 5.2.0 Attachments: TS-2916.diff # Cache-Control: max-age=xxx combo_handler plugin should parse each url's max-age value in Cache-Control header, and use the minimal value in the response header. The hard-code 10 years max-age prevents cache from refresh, even though we have parsed the value in Expires headers. See [rfc2616-sec14.9.3|http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.3]: If a response includes both an Expires header and a max-age directive, the max-age directive overrides the Expires header, even if the Expires header is more restrictive. # Duplicated headers We add support for whitelist of headers in a recent [commit|https://github.com/apache/trafficserver/commit/f61b1b416f4bb99854c6b6c77b12f742b5af9ca8] When we have added headers specified in whitelist, we need to check for duplicated headers in the following response write actions. # Multiple values Some headers has multiple values, e.g. Cache-Control: max-age=3600, public. It has 2 values: max-age=3600 and public. We need to parse all the values for each header specified in whitelist. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2917) luajit ignores --disable-silent-rules
[
https://issues.apache.org/jira/browse/TS-2917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14083090#comment-14083090
]
Alan M. Carroll commented on TS-2917:
-
Any progress on this fix?
luajit ignores --disable-silent-rules
-
Key: TS-2917
URL: https://issues.apache.org/jira/browse/TS-2917
Project: Traffic Server
Issue Type: Bug
Components: Build
Reporter: Arno Toell
Assignee: Arno Toell
Priority: Minor
Fix For: 5.2.0
When compiling ATS with --disable-silent-rules the luajit tree ignores that
configure flag. Excerpt:
{code}
./configure --enable-layout=Debian --sysconfdir=/etc/trafficserver
--libdir=/usr/lib/trafficserver --with-user=root --with-group=root
--disable-silent-rules --enable-experimental-plugins
--enable-reclaimable-freelist CFLAGS=-g -O2 -fstack-protector
--param=ssp-buffer-size=4 -Wformat -Werror=format-security
CPPFLAGS=-D_FORTIFY_SOURCE=2 CXXFLAGS=-g -O2 -fstack-protector
--param=ssp-buffer-size=4 -Wformat -Werror=format-security FCFLAGS=-g -O2
-fstack-protector --param=ssp-buffer-size=4 FFLAGS=-g -O2 -fstack-protector
--param=ssp-buffer-size=4 GCJFLAGS=-g -O2 -fstack-protector
--param=ssp-buffer-size=4 LDFLAGS=-Wl,-z,relro OBJCFLAGS=-g -O2
-fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security
OBJCXXFLAGS=-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat
-Werror=format-security --enable-wccp --enable-linux-native-aio
...
make[3]: Entering directory
'/home/arno/trafficserver/trafficserver/iocore/eventsystem'
depbase=`echo EventSystem.o | sed 's|[^/]*$|.deps/|;s|\.o$||'`;\
c++ -DHAVE_CONFIG_H -I. -I../../lib/ts -I../../lib -I../../lib/records
-I../../lib/ts -D_FORTIFY_SOURCE=2 -Dlinux -D_LARGEFILE64_SOURCE=1
-D_COMPILE64BIT_SOURCE=1 -D_GNU_SOURCE -D_REENTRANT -I/usr/include/tcl8.6
-I/usr/include/libxml2 -Wunused-parameter -g -O2 -fstack-protector
--param=ssp-buffer-size=4 -Wformat -Werror=format-security -std=c++11 -pipe
-Wall -feliminate-unused-debug-symbols -fno-strict-aliasing
-Wno-invalid-offsetof -mcx16 -MT EventSystem.o -MD -MP -MF $depbase.Tpo -c -o
EventSystem.o EventSystem.cc \
mv -f $depbase.Tpo $depbase.Po
...
make[4]: Entering directory
'/home/arno/trafficserver/trafficserver/lib/luajit'
Building LuaJIT 2.0.3
make -C src
make[5]: Entering directory
'/home/arno/trafficserver/trafficserver/lib/luajit/src'
HOSTCChost/minilua.o
HOSTLINK host/minilua
DYNASMhost/buildvm_arch.h
...
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2926) IP Clearance for ats_speed - PageSpeed Optimization plugin
[ https://issues.apache.org/jira/browse/TS-2926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-2926: Assignee: Otto van der Schaaf IP Clearance for ats_speed - PageSpeed Optimization plugin -- Key: TS-2926 URL: https://issues.apache.org/jira/browse/TS-2926 Project: Traffic Server Issue Type: Task Components: Plugins Reporter: Otto van der Schaaf Assignee: Otto van der Schaaf Fix For: 5.1.0 Attachments: ats_speed-master.zip Ats_speed is a plugin by We-Amp which enables easy and automatic web performance optimization powered by Google's PageSpeed optimization SDK (like mod_pagespeed). The donated code currently lives at https://github.com/We-Amp/ats_speed Also, See http://www.atsspeed.com/ for more information. Since this code was developed outside of the Apache process it is required to go through the IP Clearance procedure which is managed by the Incubator - https://incubator.apache.org/ip-clearance/index.html This issue will act as a tracking point for tasks related to carrying out the IP Clearance process: https://svn.apache.org/repos/asf/incubator/public/trunk/content/ip-clearance/ats-ats_speed.xml -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2927) SPDY should use the default ATS server header
[ https://issues.apache.org/jira/browse/TS-2927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14083098#comment-14083098 ] Alan M. Carroll commented on TS-2927: - Brian - do this next week (first week of August). SPDY should use the default ATS server header - Key: TS-2927 URL: https://issues.apache.org/jira/browse/TS-2927 Project: Traffic Server Issue Type: Bug Components: Core, SPDY Reporter: Brian Geffon Assignee: Brian Geffon Fix For: 5.1.0 The server header should be the normal ATS Version Server header. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2926) IP Clearance for ats_speed - PageSpeed Optimization plugin
[ https://issues.apache.org/jira/browse/TS-2926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14083094#comment-14083094 ] Alan M. Carroll commented on TS-2926: - Otto - can you commit this? Thanks. IP Clearance for ats_speed - PageSpeed Optimization plugin -- Key: TS-2926 URL: https://issues.apache.org/jira/browse/TS-2926 Project: Traffic Server Issue Type: Task Components: Plugins Reporter: Otto van der Schaaf Assignee: Otto van der Schaaf Fix For: 5.1.0 Attachments: ats_speed-master.zip Ats_speed is a plugin by We-Amp which enables easy and automatic web performance optimization powered by Google's PageSpeed optimization SDK (like mod_pagespeed). The donated code currently lives at https://github.com/We-Amp/ats_speed Also, See http://www.atsspeed.com/ for more information. Since this code was developed outside of the Apache process it is required to go through the IP Clearance procedure which is managed by the Incubator - https://incubator.apache.org/ip-clearance/index.html This issue will act as a tracking point for tasks related to carrying out the IP Clearance process: https://svn.apache.org/repos/asf/incubator/public/trunk/content/ip-clearance/ats-ats_speed.xml -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2928) SPDY should use the ATS atomic methods and not gcc atomic builtins directly
[ https://issues.apache.org/jira/browse/TS-2928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-2928: Assignee: Phil Sorber (was: Brian Geffon) SPDY should use the ATS atomic methods and not gcc atomic builtins directly --- Key: TS-2928 URL: https://issues.apache.org/jira/browse/TS-2928 Project: Traffic Server Issue Type: Bug Components: Core, SPDY Reporter: Brian Geffon Assignee: Phil Sorber Fix For: 5.2.0 SPDY should use the ATS atomic methods and gcc builtins directly -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2928) SPDY should use the ATS atomic methods and not gcc atomic builtins directly
[ https://issues.apache.org/jira/browse/TS-2928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-2928: Fix Version/s: (was: 5.1.0) 5.2.0 SPDY should use the ATS atomic methods and not gcc atomic builtins directly --- Key: TS-2928 URL: https://issues.apache.org/jira/browse/TS-2928 Project: Traffic Server Issue Type: Bug Components: Core, SPDY Reporter: Brian Geffon Assignee: Brian Geffon Fix For: 5.2.0 SPDY should use the ATS atomic methods and gcc builtins directly -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2936) Comments and line continuations in remap.config is bad mojo
[
https://issues.apache.org/jira/browse/TS-2936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll updated TS-2936:
Assignee: Leif Hedstrom
Comments and line continuations in remap.config is bad mojo
---
Key: TS-2936
URL: https://issues.apache.org/jira/browse/TS-2936
Project: Traffic Server
Issue Type: Bug
Components: Configuration, Core
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
Fix For: 5.2.0
If you do a line continuation on a commented out line in remap.config, it'll
still suck up the following line into the comment. This is less than ideal.
As an example, this does not work
{code}
map http://example.com http://real.example.com \
# @plugin=conf_remap.so @pparam= ... \
@plugin=header_rewrite.so @pparam= ...
{code}
The issue being that the second plugin line gets sucked into the comment.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2937) conf_remap plugin returns an error if the file is empty
[ https://issues.apache.org/jira/browse/TS-2937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-2937: Fix Version/s: (was: 5.1.0) 5.2.0 conf_remap plugin returns an error if the file is empty --- Key: TS-2937 URL: https://issues.apache.org/jira/browse/TS-2937 Project: Traffic Server Issue Type: Bug Components: Configuration, Plugins Reporter: Craig Forbes Assignee: Leif Hedstrom Fix For: 5.2.0 If the conf_remap plugin config file does not have at least one CONFIG line an error occurs and traffic_server exits with an error. For example if the config file is empty or has only comments. Also related, if the file does have at least one CONFIG line all other errors are reported but ignored and does not trigger an error and exit. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2936) Comments and line continuations in remap.config is bad mojo
[
https://issues.apache.org/jira/browse/TS-2936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll updated TS-2936:
Fix Version/s: (was: 5.1.0)
5.2.0
Comments and line continuations in remap.config is bad mojo
---
Key: TS-2936
URL: https://issues.apache.org/jira/browse/TS-2936
Project: Traffic Server
Issue Type: Bug
Components: Configuration, Core
Reporter: Leif Hedstrom
Fix For: 5.2.0
If you do a line continuation on a commented out line in remap.config, it'll
still suck up the following line into the comment. This is less than ideal.
As an example, this does not work
{code}
map http://example.com http://real.example.com \
# @plugin=conf_remap.so @pparam= ... \
@plugin=header_rewrite.so @pparam= ...
{code}
The issue being that the second plugin line gets sucked into the comment.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2947) Make the setting proxy.config.http.global_user_agent_header overrideable per remap
[ https://issues.apache.org/jira/browse/TS-2947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-2947: Assignee: Leif Hedstrom Make the setting proxy.config.http.global_user_agent_header overrideable per remap -- Key: TS-2947 URL: https://issues.apache.org/jira/browse/TS-2947 Project: Traffic Server Issue Type: Improvement Components: Core Reporter: Sudheer Vinukonda Assignee: Leif Hedstrom Labels: review Fix For: 5.1.0 Attachments: TS-2947.diff There's a requirement among some of our origins to see custom and different user_agent headers. This ticket adds the setting proxy.config.http.global_user_agent_header to the list of overrideable params. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2942) weird value on %fsiz field in log files
[
https://issues.apache.org/jira/browse/TS-2942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll updated TS-2942:
Fix Version/s: (was: 5.1.0)
5.2.0
weird value on %fsiz field in log files
-
Key: TS-2942
URL: https://issues.apache.org/jira/browse/TS-2942
Project: Traffic Server
Issue Type: Bug
Components: Logging, Metrics
Reporter: Daniel Picolli Biazus
Assignee: Leif Hedstrom
Fix For: 5.2.0
We've configured ATS as a reverse proxy, and We've been noticed a really
weird traffic value in our monitoring system. After spend some time digging
through log files, I could notice that, in some cases the field %fsiz
brings a huge value (20 characters) instead of the file size.
I found this closed issue regarding the fsiz implementation, and I think
there might be a issue when there is no Content-Length from the origin server.
https://issues.apache.org/jira/browse/TS-2212
Log format:
##
LogFormat
Name = myformat/
Format = %ttmsf%{Host}cqh%chi [%cqtn]
%cqhm %cquup %cqhv%pssc %cqhm %fsiz %cquup
%{User-Agent}cqh %{Referer}cqh %crc/
/LogFormat
##
Log result:
##
0.181 myhostname.com 123.123.123.123 [17/Jul/2014:15:50:33 -]GET
/foo/bar/file.jpg HTTP/1.1 200 GET 3904675161847313968
/foo/bar/file.jpg Mozilla/5.0 (Windows NT 6.2; WOW64)
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.153 Safari/537.36
http://myreferer.comTCP_MISS
###
In that case, the fsiz field has the value 3904675161847313968
instead the value of a few bytes.
I believe when there is no way to get the real content-length, we should
return 0 in order to avoid misinterpretation.
Thanks in advance,
Daniel
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2946) Core dump in snprintf
[
https://issues.apache.org/jira/browse/TS-2946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll updated TS-2946:
Fix Version/s: (was: 5.1.0)
5.2.0
Core dump in snprintf
-
Key: TS-2946
URL: https://issues.apache.org/jira/browse/TS-2946
Project: Traffic Server
Issue Type: Bug
Components: Core
Reporter: Sudheer Vinukonda
Labels: crash
Fix For: 5.2.0
While fixing TS-2938, ran into another core dump with the below stack trace.
server_request object seems corrupted even in this stack trace, just like
TS-2938. Investigating further.
{code}
(gdb) #0 0x003ca2044283 in vfprintf () from /lib64/libc.so.6
#1 0x003ca206f9d2 in vsnprintf () from /lib64/libc.so.6
#2 0x003ca204f4a3 in snprintf () from /lib64/libc.so.6
#3 0x00648724 in ink_fast_ltoa (heap=0x2b7682cd0010,
mh=0x2b7682cd00c8, field=0x2b7682cd0298, value=value optimized out) at
../../lib/ts/ink_string.h:449
#4 mime_format_int64 (heap=0x2b7682cd0010, mh=0x2b7682cd00c8,
field=0x2b7682cd0298, value=value optimized out) at MIME.cc:2810
#5 mime_field_value_set_int64 (heap=0x2b7682cd0010, mh=0x2b7682cd00c8,
field=0x2b7682cd0298, value=value optimized out) at MIME.cc:2064
#6 0x005de7f0 in value_set_int64 (request_sent_time=1405317978,
response_received_time=1405317978, now=1405663927, base=value optimized
out, outgoing=0x2b7679272418)
at ../../proxy/hdrs/MIME.h:817
#7 value_set_int64 (request_sent_time=1405317978,
response_received_time=1405317978, now=1405663927, base=value optimized
out, outgoing=0x2b7679272418) at ../../proxy/hdrs/MIME.h:1334
#8 set_age (request_sent_time=1405317978, response_received_time=1405317978,
now=1405663927, base=value optimized out, outgoing=0x2b7679272418) at
../../proxy/hdrs/MIME.h:1548
#9 HttpTransactHeaders::insert_time_and_age_headers_in_response
(request_sent_time=1405317978, response_received_time=1405317978,
now=1405663927, base=value optimized out,
outgoing=0x2b7679272418) at HttpTransactHeaders.cc:754
#10 0x005c0aca in HttpTransact::build_response (s=0x2b7679271d38,
base_response=0x2b777d8b90b8, outgoing_response=0x2b7679272418,
outgoing_version=value optimized out,
status_code=HTTP_STATUS_NONE, reason_phrase=0x755b4b None) at
HttpTransact.cc:7772
#11 0x005d4b84 in HttpTransact::build_response_from_cache
(s=0x2b7679271d38, warning_code=HTTP_WARNING_CODE_NONE) at
HttpTransact.cc:2869
#12 0x005d6858 in HttpTransact::HandleCacheOpenReadHit
(s=0x2b7679271d38) at HttpTransact.cc:2755
#13 0x005922a6 in HttpSM::call_transact_and_set_next_state
(this=0x2b7679271cd0, f=value optimized out) at HttpSM.cc:6788
#14 0x005ac562 in HttpSM::handle_api_return (this=0x2b7679271cd0) at
HttpSM.cc:1505
#15 0x005a49e0 in HttpSM::state_api_callout (this=0x2b7679271cd0,
event=0, data=0x0) at HttpSM.cc:1437
#16 0x005aa402 in HttpSM::set_next_state (this=0x2b7679271cd0) at
HttpSM.cc:6830
#17 0x005ac562 in HttpSM::handle_api_return (this=0x2b7679271cd0) at
HttpSM.cc:1505
#18 0x005a49e0 in HttpSM::state_api_callout (this=0x2b7679271cd0,
event=0, data=0x0) at HttpSM.cc:1437
#19 0x005aa402 in HttpSM::set_next_state (this=0x2b7679271cd0) at
HttpSM.cc:6830
#20 0x005ac562 in HttpSM::handle_api_return (this=0x2b7679271cd0) at
HttpSM.cc:1505
#21 0x005a49e0 in HttpSM::state_api_callout (this=0x2b7679271cd0,
event=0, data=0x0) at HttpSM.cc:1437
#22 0x005a7810 in do_api_callout (this=0x2b7679271cd0, event=value
optimized out, data=0xb050) at HttpSM.cc:444
#23 setup_cache_lookup_complete_api (this=0x2b7679271cd0, event=value
optimized out, data=0xb050) at HttpSM.cc:2403
#24 HttpSM::state_cache_open_read (this=0x2b7679271cd0, event=value
optimized out, data=0xb050) at HttpSM.cc:2459
#25 0x005a7518 in HttpSM::main_handler (this=0x2b7679271cd0,
event=1103, data=0xb050) at HttpSM.cc:2501
#26 0x00585882 in handleEvent (this=0x2b76792736a0, event=1103,
data=0xb050) at ../../iocore/eventsystem/I_Continuation.h:146
#27 HttpCacheSM::state_cache_open_read (this=0x2b76792736a0, event=1103,
data=0xb050) at HttpCacheSM.cc:137
#28 0x006dc0ee in Cache::open_read (this=value optimized out,
cont=0x2b76792736a0, key=value optimized out, request=0x2b76792723d8,
params=0x2b7679271db0,
type=value optimized out,
hostname=0x2b7659b96150
ads.unister-gmbh.denewsletter_img/aidude/template/countdown/stdblue/countdown63.gifin-den-urlaub-deals.de%2Ftime_2014-07-09_2014-07-16_H_stdblue.gift=1405663926ttl=4492800sig=DtpLmS6SPFs7BWU7bvb5IA...,
host_len=19) at CacheRead.cc:143
#29
[jira] [Commented] (TS-2947) Make the setting proxy.config.http.global_user_agent_header overrideable per remap
[ https://issues.apache.org/jira/browse/TS-2947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14083110#comment-14083110 ] James Peach commented on TS-2947: - Can't you just nuke the User-Agent header with a plugin? Make the setting proxy.config.http.global_user_agent_header overrideable per remap -- Key: TS-2947 URL: https://issues.apache.org/jira/browse/TS-2947 Project: Traffic Server Issue Type: Improvement Components: Core Reporter: Sudheer Vinukonda Assignee: Leif Hedstrom Labels: review Fix For: 5.1.0 Attachments: TS-2947.diff There's a requirement among some of our origins to see custom and different user_agent headers. This ticket adds the setting proxy.config.http.global_user_agent_header to the list of overrideable params. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2955) support variable expansion in set-redirect operator for header_rewrite
[
https://issues.apache.org/jira/browse/TS-2955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll updated TS-2955:
Assignee: Leif Hedstrom
support variable expansion in set-redirect operator for header_rewrite
--
Key: TS-2955
URL: https://issues.apache.org/jira/browse/TS-2955
Project: Traffic Server
Issue Type: Improvement
Components: Plugins
Reporter: Sudheer Vinukonda
Assignee: Leif Hedstrom
Labels: review
Fix For: 5.1.0
Attachments: TS-2955.diff
support variable expansion in set-redirect operator for header_rewrite to be
able to dynamically substitute variables in the Location header (currently,
only %{PATH} is supported).
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2950) Import libck to libts for atomics and concurrent data structures
[ https://issues.apache.org/jira/browse/TS-2950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-2950: Fix Version/s: (was: 5.1.0) 5.2.0 Import libck to libts for atomics and concurrent data structures Key: TS-2950 URL: https://issues.apache.org/jira/browse/TS-2950 Project: Traffic Server Issue Type: Improvement Components: Core Reporter: Phil Sorber Assignee: Phil Sorber Fix For: 5.2.0 We want to import libck to replace our atomics and concurrent data structures. We would preferably like to build against an OS supplied version, but will import ourselves until it is more ubiquitous. https://cwiki.apache.org/confluence/display/TS/Import+ConcurrecyKit+for+atomics+and+containers -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2959) Compiler warnings from gcc 4.9.1
[
https://issues.apache.org/jira/browse/TS-2959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll updated TS-2959:
Fix Version/s: (was: 5.1.0)
5.2.0
Compiler warnings from gcc 4.9.1
Key: TS-2959
URL: https://issues.apache.org/jira/browse/TS-2959
Project: Traffic Server
Issue Type: Bug
Components: Core, DNS
Reporter: Leif Hedstrom
Assignee: Alan M. Carroll
Fix For: 5.2.0
We get:
{code}
In file included from ../../iocore/hostdb/P_HostDB.h:47:0,
from ../../proxy/Main.cc:63:
../../iocore/hostdb/P_MultiCache.h: In member function ‘void
MultiCacheC::rebuild_element(int, char*, RebuildMC) [with C = HostDBInfo]’:
../../iocore/hostdb/P_MultiCache.h:468:23: error: array subscript is above
array bounds [-Werror=array-bounds]
char *offset = data + level_offset[level] + bucketsize[level] * bucket;
^
../../iocore/hostdb/P_MultiCache.h:468:65: error: array subscript is above
array bounds [-Werror=array-bounds]
char *offset = data + level_offset[level] + bucketsize[level] * bucket;
^
../../iocore/hostdb/P_MultiCache.h:487:29: error: array subscript is above
array bounds [-Werror=array-bounds]
for (block = b; block b + elements[level]; block++) {
^
../../iocore/hostdb/P_MultiCache.h:509:39: error: array subscript is above
array bounds [-Werror=array-bounds]
if (hits ((max_hits / 2) + 1) * elements[level])
^
../../iocore/hostdb/P_MultiCache.h:511:33: error: array subscript is above
array bounds [-Werror=array-bounds]
for (block = b; block b + elements[level]; block++) {
^
../../iocore/hostdb/P_MultiCache.h:468:23: error: array subscript is above
array bounds [-Werror=array-bounds]
char *offset = data + level_offset[level] + bucketsize[level] * bucket;
^
../../iocore/hostdb/P_MultiCache.h:468:65: error: array subscript is above
array bounds [-Werror=array-bounds]
char *offset = data + level_offset[level] + bucketsize[level] * bucket;
^
../../iocore/hostdb/P_MultiCache.h:487:29: error: array subscript is above
array bounds [-Werror=array-bounds]
for (block = b; block b + elements[level]; block++) {
^
../../iocore/hostdb/P_MultiCache.h:509:39: error: array subscript is above
array bounds [-Werror=array-bounds]
if (hits ((max_hits / 2) + 1) * elements[level])
^
../../iocore/hostdb/P_MultiCache.h:511:33: error: array subscript is above
array bounds [-Werror=array-bounds]
for (block = b; block b + elements[level]; block++) {
^
../../iocore/hostdb/P_MultiCache.h:552:31: error: array subscript is above
array bounds [-Werror=array-bounds]
for (block = b; block b + elements[level]; block++) {
^
../../iocore/hostdb/P_MultiCache.h:558:31: error: array subscript is above
array bounds [-Werror=array-bounds]
for (block = b; block b + elements[level]; block++)
^
../../iocore/hostdb/P_MultiCache.h:552:31: error: array subscript is above
array bounds [-Werror=array-bounds]
for (block = b; block b + elements[level]; block++) {
^
../../iocore/hostdb/P_MultiCache.h:558:31: error: array subscript is above
array bounds [-Werror=array-bounds]
for (block = b; block b + elements[level]; block++)
^
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2962) header_rewrite default exists matcher not working
[
https://issues.apache.org/jira/browse/TS-2962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll updated TS-2962:
Fix Version/s: (was: 5.1.0)
5.2.0
header_rewrite default exists matcher not working
---
Key: TS-2962
URL: https://issues.apache.org/jira/browse/TS-2962
Project: Traffic Server
Issue Type: Bug
Components: Plugins
Affects Versions: 5.0.1
Reporter: Nick Muerdter
Assignee: Leif Hedstrom
Priority: Minor
Fix For: 5.2.0
The
[documentation|https://docs.trafficserver.apache.org/en/latest/reference/plugins/header_rewrite.en.html#operands-to-conditions]
for the header_rewrite plugin indicates that if you don't specify a matcher
on a condition, then the matcher checks if a value exists. However, if I'm
understanding the intended behavior correctly, this is not the behavior I'm
seeing. If I don't specify an explicit matcher on the condition, then the
condition never seems to match (at least for http headers).
Here's a simplified example in a stock 5.0.1 installation that should add a
{{X-Testing}} header to the response if the {{Surrogate-Control}} header
exists on the response:
{code}
cond %{READ_RESPONSE_HDR_HOOK}
cond %{HEADER:Surrogate-Control}
add-header X-Testing Hello [L]
{code}
{code}
$ curl -I http://localhost:8081/test;
HTTP/1.1 200 OK
X-Powered-By: Express
Surrogate-Control: max-age=60
Date: Mon, 28 Jul 2014 06:19:43 GMT
Age: 0
Connection: keep-alive
Server: ATS/5.0.1
{code}
But as you can see from this response, no such header is added.
If I change the condition to a regex match for one or more characters, then
the header gets added as I expect:
{code}
cond %{READ_RESPONSE_HDR_HOOK}
cond %{HEADER:Surrogate-Control} /.+/
add-header X-Testing Hello [L]
{code}
{code}
$ curl -I http://localhost:8081/test;
HTTP/1.1 200 OK
X-Powered-By: Express
Surrogate-Control: max-age=60
Date: Mon, 28 Jul 2014 06:19:12 GMT
X-Testing: Hello
Age: 0
Connection: keep-alive
Server: ATS/5.0.1
{code}
The regex based approach works fine, but it took me a while to realize what
was going on and figure this out (the primary example in the documentation
also seems to be utilizing this exists logic so that also doesn't work for
me).
So if the condition without an explicit matcher should check for a variable's
existence, that doesn't seem to be working. Alternatively, if the current
behavior is working as intended, then I think the documentation and examples
might need to be updated (and if that's the case, I'd be happy to take a stab
at that).
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2955) support variable expansion in set-redirect operator for header_rewrite
[
https://issues.apache.org/jira/browse/TS-2955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll updated TS-2955:
Fix Version/s: (was: 5.1.0)
5.2.0
support variable expansion in set-redirect operator for header_rewrite
--
Key: TS-2955
URL: https://issues.apache.org/jira/browse/TS-2955
Project: Traffic Server
Issue Type: Improvement
Components: Plugins
Reporter: Sudheer Vinukonda
Assignee: Leif Hedstrom
Labels: review
Fix For: 5.2.0
Attachments: TS-2955.diff
support variable expansion in set-redirect operator for header_rewrite to be
able to dynamically substitute variables in the Location header (currently,
only %{PATH} is supported).
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2961) Expires: 0 and Expires: past date being temporarily cached
[
https://issues.apache.org/jira/browse/TS-2961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll updated TS-2961:
Fix Version/s: (was: 5.1.0)
5.2.0
Expires: 0 and Expires: past date being temporarily cached
--
Key: TS-2961
URL: https://issues.apache.org/jira/browse/TS-2961
Project: Traffic Server
Issue Type: Bug
Affects Versions: 5.0.1
Reporter: Nick Muerdter
Priority: Minor
Fix For: 5.2.0
While doing some integration testing with TrafficServer, I noticed some
seemingly odd behavior: If my origin server returns {{Expires: 0}} or
{{Expires: SOME_PAST_DATE}} headers, TrafficServer appears to cache these
responses for about 1 second. This would seem to run counter to the
[documentation|https://docs.trafficserver.apache.org/en/latest/admin/http-proxy-caching.en.html?highlight=expires#origin-server-directives]:
{quote}
By default, Traffic Server does not cache objects with the following response
headers:
- Expires: header with value of 0 (zero) or a past date
{quote}
I was able to reproduce this with a stock TrafficServer 5.0.1 installation
pointing at an origin server that returns a random, unique output on each
call. If the origin server returns a {{Expires: 0}} or {{Expires:
SOME_PAST_DATE}} header, then TrafficServer appears to cache the first
response briefly (around 1 second).
I do not experience this same temporary cache when testing the other
scenarios outlined in the documentation of what's not cached (for example,
when the origin server responds with {{Cache-Control: no-store}} or
{{Set-Cookie}}).
This isn't a huge deal for my use case personally, but the behavior I'm
seeing does seem to run counter to the documentation, so I thought it was a
bit odd.
Here's some details demonstrating the cached response when requests are made
in quick succession:
{code}
$ curl -v http://localhost:8081/cacheable-expires-0/1; curl -v
http://localhost:8081/cacheable-expires-0/1;
* About to connect() to localhost port 8081 (#0)
* Trying ::1... Connection refused
* Trying 127.0.0.1... connected
* Connected to localhost (127.0.0.1) port 8081 (#0)
GET /cacheable-expires-0/1 HTTP/1.1
User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7
NSS/3.14.0.0 zlib/1.2.3 libidn/1.18 libssh2/1.4.2
Host: localhost:8081
Accept: */*
HTTP/1.1 200 OK
X-Powered-By: Express
Expires: 0
Date: Mon, 28 Jul 2014 01:49:45 GMT
Age: 0
Transfer-Encoding: chunked
Connection: keep-alive
Server: ATS/5.0.1
* Connection #0 to host localhost left intact
* Closing connection #0
36780-926573328-0.49593452527187765
* About to connect() to localhost port 8081 (#0)
* Trying ::1... Connection refused
* Trying 127.0.0.1... connected
* Connected to localhost (127.0.0.1) port 8081 (#0)
GET /cacheable-expires-0/1 HTTP/1.1
User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7
NSS/3.14.0.0 zlib/1.2.3 libidn/1.18 libssh2/1.4.2
Host: localhost:8081
Accept: */*
HTTP/1.1 200 OK
X-Powered-By: Express
Expires: 0
Date: Mon, 28 Jul 2014 01:49:45 GMT
Age: 0
Content-Length: 35
Connection: keep-alive
Server: ATS/5.0.1
* Connection #0 to host localhost left intact
* Closing connection #0
36780-926573328-0.49593452527187765
{code}
In this case, the origin server only gets called once (note the response
bodies are identical, which should not be happening since the origin is
returning a unique response body on each call). If I add in a sleep of around
0.8 seconds between calls, then TrafficServer's cached copy appears to go
away:
{code}
$ curl -v http://localhost:8081/cacheable-expires-0/1; sleep 0.8 curl
-v http://localhost:8081/cacheable-expires-0/1;
* About to connect() to localhost port 8081 (#0)
* Trying ::1... Connection refused
* Trying 127.0.0.1... connected
* Connected to localhost (127.0.0.1) port 8081 (#0)
GET /cacheable-expires-0/1 HTTP/1.1
User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7
NSS/3.14.0.0 zlib/1.2.3 libidn/1.18 libssh2/1.4.2
Host: localhost:8081
Accept: */*
HTTP/1.1 200 OK
X-Powered-By: Express
Expires: 0
Date: Mon, 28 Jul 2014 01:51:16 GMT
Age: 0
Transfer-Encoding: chunked
Connection: keep-alive
Server: ATS/5.0.1
* Connection #0 to host localhost left intact
* Closing connection #0
36871-310090571-0.9994140579365194
* About to connect() to localhost port 8081 (#0)
* Trying ::1... Connection refused
* Trying 127.0.0.1... connected
* Connected to localhost (127.0.0.1) port 8081 (#0)
GET /cacheable-expires-0/1 HTTP/1.1
User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7
NSS/3.14.0.0 zlib/1.2.3 libidn/1.18 libssh2/1.4.2
Host: localhost:8081
[jira] [Commented] (TS-2916) combo_handler does not set the response headers properly
[ https://issues.apache.org/jira/browse/TS-2916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14083112#comment-14083112 ] Kit Chan commented on TS-2916: -- I will work on it this weekend. combo_handler does not set the response headers properly Key: TS-2916 URL: https://issues.apache.org/jira/browse/TS-2916 Project: Traffic Server Issue Type: Bug Components: Plugins Reporter: Feifei Cai Assignee: Kit Chan Labels: review, yahoo Fix For: 5.2.0 Attachments: TS-2916.diff # Cache-Control: max-age=xxx combo_handler plugin should parse each url's max-age value in Cache-Control header, and use the minimal value in the response header. The hard-code 10 years max-age prevents cache from refresh, even though we have parsed the value in Expires headers. See [rfc2616-sec14.9.3|http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.3]: If a response includes both an Expires header and a max-age directive, the max-age directive overrides the Expires header, even if the Expires header is more restrictive. # Duplicated headers We add support for whitelist of headers in a recent [commit|https://github.com/apache/trafficserver/commit/f61b1b416f4bb99854c6b6c77b12f742b5af9ca8] When we have added headers specified in whitelist, we need to check for duplicated headers in the following response write actions. # Multiple values Some headers has multiple values, e.g. Cache-Control: max-age=3600, public. It has 2 values: max-age=3600 and public. We need to parse all the values for each header specified in whitelist. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2950) Import libck to libts for atomics and concurrent data structures
[ https://issues.apache.org/jira/browse/TS-2950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14083116#comment-14083116 ] Leif Hedstrom commented on TS-2950: --- Fwiw, I really do not think that we should keep the encapsulation (ink_ / ats_). Just as with other libraries, we generally don't abstract / encapsulate. The reason for having the encapsulation before was to deal with different compilers / platforms, but CK takes care of that for us. We shouldn't encapsulate something that already encapsulates it :). Import libck to libts for atomics and concurrent data structures Key: TS-2950 URL: https://issues.apache.org/jira/browse/TS-2950 Project: Traffic Server Issue Type: Improvement Components: Core Reporter: Phil Sorber Assignee: Phil Sorber Fix For: 5.2.0 We want to import libck to replace our atomics and concurrent data structures. We would preferably like to build against an OS supplied version, but will import ourselves until it is more ubiquitous. https://cwiki.apache.org/confluence/display/TS/Import+ConcurrecyKit+for+atomics+and+containers -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2967) failed assert if ssl_multicert.config doesn't exist
[
https://issues.apache.org/jira/browse/TS-2967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14083119#comment-14083119
]
Alan M. Carroll commented on TS-2967:
-
Jack - land this first week of August for 5.1.0.
failed assert if ssl_multicert.config doesn't exist
---
Key: TS-2967
URL: https://issues.apache.org/jira/browse/TS-2967
Project: Traffic Server
Issue Type: Bug
Reporter: Jack Bates
Assignee: Jack Bates
Fix For: 5.1.0
If an ssl_multicert.config file doesn't exist then
SSLParseCertificateConfiguration() returns false (SSLUtils.cc line 1435)
and SSLCertificateConfig::reconfigure() doesn't initialize configid
(SSLConfig.cc line 333)
Then when SSLRecRawStatSyncCount() calls SSLCertificateConfig::acquire()
(SSLUtils.cc line 502)
it calls ConfigProcessor::get() with configid zero (SSLConfig.cc line 342)
and there's an ink_assert(id != 0) (ProxyConfig.cc line 175)
One way to avoid the failed assert is if SSLCertificateConfig::acquire() and
SSLCertificateConfig::release() only call ConfigProcessor::get/release() if
(configid !=0)
Another way might be if SSLCertificateConfig::reconfigure() initialized
configid with configProcessor.set(configid, NULL) if
SSLParseCertificateConfiguration() returns false?
Or SSLParseCertificateConfiguration() could treat a nonexistent
ssl_multicert.config the same as it treats a blank file? ({{touch
ssl_multicert.config}} makes the failed assert go away.)
Or maybe there's another better way to avoid the failed assert?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2978) Reorder member variables in HttpSM State
[ https://issues.apache.org/jira/browse/TS-2978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-2978: Fix Version/s: (was: 5.1.0) 6.0.0 Reorder member variables in HttpSM State Key: TS-2978 URL: https://issues.apache.org/jira/browse/TS-2978 Project: Traffic Server Issue Type: Improvement Components: HTTP Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 6.0.0 I think we can reduce its size by reordering for example the booleans such that we don't have to pad so much ? -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2947) Make the setting proxy.config.http.global_user_agent_header overrideable per remap
[ https://issues.apache.org/jira/browse/TS-2947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14083120#comment-14083120 ] Sudheer Vinukonda commented on TS-2947: --- Not sure to follow - the requirement is to basically retain the incoming UA, if conf_remap setting is set to NULL (that's how the global_user_agent setting in records.config works) - is there a way to do this with a plugin? Make the setting proxy.config.http.global_user_agent_header overrideable per remap -- Key: TS-2947 URL: https://issues.apache.org/jira/browse/TS-2947 Project: Traffic Server Issue Type: Improvement Components: Core Reporter: Sudheer Vinukonda Assignee: Leif Hedstrom Labels: review Fix For: 5.1.0 Attachments: TS-2947.diff There's a requirement among some of our origins to see custom and different user_agent headers. This ticket adds the setting proxy.config.http.global_user_agent_header to the list of overrideable params. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2449) I find INKUDPRecvFrom can not work .
[ https://issues.apache.org/jira/browse/TS-2449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-2449: Fix Version/s: (was: 5.1.0) sometime I find INKUDPRecvFrom can not work . - Key: TS-2449 URL: https://issues.apache.org/jira/browse/TS-2449 Project: Traffic Server Issue Type: Bug Components: Core Affects Versions: 4.1.2 Reporter: xinyuziran Labels: review Fix For: sometime Attachments: iocore.patch, main.patch, udp_patch.txt I find INKUDPBind can bind udp port, but INKUDPRecvFrom can't recive udp data. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (TS-2747) Segmentation fault,after update 4.1.2 to 4.2.0
[ https://issues.apache.org/jira/browse/TS-2747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll reassigned TS-2747: --- Assignee: Alan M. Carroll Segmentation fault,after update 4.1.2 to 4.2.0 --- Key: TS-2747 URL: https://issues.apache.org/jira/browse/TS-2747 Project: Traffic Server Issue Type: Bug Components: MIME Reporter: acache Assignee: Alan M. Carroll Labels: crash Fix For: 5.1.0 [TrafficServer] using root directory '/usr' NOTE: Traffic Server received Sig 11: Segmentation fault /usr/bin/traffic_server - STACK TRACE: /lib64/libpthread.so.0(+0xf500)[0x2ba44394a500] /usr/bin/traffic_server(HttpTransactHeaders::insert_via_header_in_response(HttpTransact::State*, HTTPHdr*)+0x1b3)[0x564c43] /usr/bin/traffic_server(HttpTransact::build_response(HttpTransact::State*, HTTPHdr*, HTTPHdr*, HTTPVersion, HTTPStatus, char const*)+0x21b)[0x544a9b] /usr/bin/traffic_server(HttpTransact::build_response_from_cache(HttpTransact::State*, HTTPWarningCode)+0x354)[0x558784] /usr/bin/traffic_server(HttpTransact::HandleCacheOpenReadHit(HttpTransact::State*)+0x448)[0x55a438] /usr/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void (*)(HttpTransact::State*))+0x66)[0x515eb6] /usr/bin/traffic_server(HttpSM::handle_api_return()+0x37a)[0x52ee7a] /usr/bin/traffic_server(HttpSM::set_next_state()+0x1f2)[0x52f412] /usr/bin/traffic_server(HttpSM::handle_api_return()+0x37a)[0x52ee7a] /usr/bin/traffic_server(HttpSM::set_next_state()+0x1f2)[0x52f412] /usr/bin/traffic_server(HttpSM::state_cache_open_read(int, void*)+0xfe)[0x5237ae] /usr/bin/traffic_server(HttpSM::main_handler(int, void*)+0xd8)[0x5262c8] /usr/bin/traffic_server(HttpCacheSM::state_cache_open_read(int, void*)+0x1b2)[0x509a02] /usr/bin/traffic_server(CacheVC::callcont(int)+0x53)[0x5ef183] /usr/bin/traffic_server(CacheVC::openReadStartEarliest(int, Event*)+0x69b)[0x658b4b] /usr/bin/traffic_server(CacheVC::handleReadDone(int, Event*)+0x1ed)[0x638d1d] /usr/bin/traffic_server(AIOCallbackInternal::io_complete(int, void*)+0x35)[0x5ef3e5] /usr/bin/traffic_server(EThread::process_event(Event*, int)+0x8f)[0x6ab21f] /usr/bin/traffic_server(EThread::execute()+0x58b)[0x6abb9b] /usr/bin/traffic_server[0x6aa5aa] /lib64/libpthread.so.0(+0x7851)[0x2ba443942851] /lib64/libc.so.6(clone+0x6d)[0x2ba44493894d] -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (TS-2933) Using TSHttpTxnEffectiveUrlStringGet() in a remap plugin can mess up destination port
[
https://issues.apache.org/jira/browse/TS-2933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll reassigned TS-2933:
---
Assignee: Alan M. Carroll
Using TSHttpTxnEffectiveUrlStringGet() in a remap plugin can mess up
destination port
-
Key: TS-2933
URL: https://issues.apache.org/jira/browse/TS-2933
Project: Traffic Server
Issue Type: Bug
Components: Core, TS API
Reporter: Leif Hedstrom
Assignee: Alan M. Carroll
Fix For: 5.1.0
With a remap rule like
{code}
map http://example.com https://real.example.com @plugin=cacheurl.so
@pparam=cachekey.config
{code}
(note the mapping from http - https), we'll end up with a request on port 80
to the origin server. I've verified that the offending API that causes this
rewrite is TSHttpTxnEffectiveUrlStringGet() (100% certain). So it's not a
bug in the cacheurl plugin IMO; it does the right thing and returns
TSREMAP_NO_REMAP to tell the rewrite engine to use the default mapping rule.
This mostly works, where the destination host and path are rewritten
properly, but the port gets set to 80 (presumably some default tripping).
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Assigned] (TS-2584) failed assert transforming and caching negative response
[
https://issues.apache.org/jira/browse/TS-2584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll reassigned TS-2584:
---
Assignee: Alan M. Carroll
failed assert transforming and caching negative response
Key: TS-2584
URL: https://issues.apache.org/jira/browse/TS-2584
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Reporter: Jack Bates
Assignee: Alan M. Carroll
Fix For: 5.1.0
If negative caching is enabled and you transform a negative response (for
example a null transform) there is a failed assert in
HttpTransact::set_headers_for_cache_write()
{noformat}
FATAL: HttpTransact.cc:4811: failed assert
`cache_info-response_get()-valid()`
proxy/.libs/lt-traffic_server - STACK TRACE:
lib/ts/.libs/libtsutil.so.5(ink_fatal_die+0x0)[0xb77a6445]
lib/ts/.libs/libtsutil.so.5(+0x22269)[0xb77a5269]
proxy/.libs/lt-traffic_server(_ZN12HttpTransact27set_headers_for_cache_writeEPNS_5StateEP8HTTPInfoP7HTTPHdrS5_+0x1da)[0x81c0ae6]
proxy/.libs/lt-traffic_server(_ZN12HttpTransact22handle_transform_readyEPNS_5StateE+0x272)[0x81c0576]
proxy/.libs/lt-traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x78)[0x81a4b3e]
proxy/.libs/lt-traffic_server(_ZN6HttpSM38state_response_wait_for_transform_readEiPv+0x196)[0x81926b0]
proxy/.libs/lt-traffic_server(_ZN6HttpSM12main_handlerEiPv+0x2df)[0x81969b5]
proxy/.libs/lt-traffic_server(_ZN12Continuation11handleEventEiPv+0x47)[0x811b427]
proxy/.libs/lt-traffic_server(_ZN17TransformTerminus12handle_eventEiPv+0x27f)[0x815d81b]
proxy/.libs/lt-traffic_server(_ZN12Continuation11handleEventEiPv+0x47)[0x811b427]
proxy/.libs/lt-traffic_server(_ZN7EThread13process_eventEP5Eventi+0x104)[0x8300692]
proxy/.libs/lt-traffic_server(_ZN7EThread7executeEv+0xd6)[0x8300916]
proxy/.libs/lt-traffic_server[0x82ff569]
/lib/i686/cmov/libpthread.so.0(+0x5955)[0xb7467955]
/lib/i686/cmov/libc.so.6(clone+0x5e)[0xb717f1de]
Aborted (core dumped)
{noformat}
HttpTransact::handle_transform_ready() passes s-cache_info.transform_store
to HttpTransact::set_headers_for_cache_write()
The -valid() test at the top of HttpTransact::set_headers_for_cache_write()
fails so -create() gets called.
{code}
if (!cache_info-valid()) {
cache_info-create();
}
{code}
(s-cache_info.transform_store-m_alt is NULL. I didn't look into why this
is, is it expected?)
Because s-negative_caching is true, cache_info-response_set(response)
doesn't get called, instead the assert fails.
{code}
if (!s-negative_caching)
cache_info-response_set(response);
else {
ink_assert(cache_info-response_get()-valid());
}
{code}
Assuming the cache_info-valid() test can fail and s-negative_caching can be
true at the same time, one possible solution is to fix the logic so
cache_info-response_set(response) gets called?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2912) HEAD transaction on stale entry deletes cache entry
[ https://issues.apache.org/jira/browse/TS-2912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14083252#comment-14083252 ] William Bardwell commented on TS-2912: -- Why did you want it to add If-Modified-Since or If-None-Match if the request is a HEAD request? The chnge to request_conditional seems reasonable, but not sure that it will fix it, it seems like handle_cache_operation_on_forward_server_response() needs to not delete things... HEAD transaction on stale entry deletes cache entry --- Key: TS-2912 URL: https://issues.apache.org/jira/browse/TS-2912 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: William Bardwell Assignee: weijin Labels: review Fix For: 5.1.0 Attachments: ts-2912.try1.diff On a stale cache entry a HEAD gets tunneled to the origin, but when a 200 comes back HttpTransact::handle_cache_operation_on_forward_server_response(State* s) deletes the cache entry, it seems like it should just ignore it (or check ETag/Last-Modified and maybe delete if those don't match, but not unconditionally.) I am seeing this with 4.2.X with a plugin fiddling with stuff, but the code looks the same in trunk, line 4318 looks like the problem line. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TS-2982) build error
bettydramit created TS-2982: --- Summary: build error Key: TS-2982 URL: https://issues.apache.org/jira/browse/TS-2982 Project: Traffic Server Issue Type: Bug Reporter: bettydramit git master In file included from ../../iocore/cache/P_Cache.h:43, from ../../iocore/cluster/P_Cluster.h:31, from P_HostDB.h:38, from MultiCache.cc:33: ../../iocore/cache/P_CacheVol.h: In member function 'void Vol::set_migrate_in_progress(MigrateToInterimCache*)': ../../iocore/cache/P_CacheVol.h:491: error: 'union INK_MD5' has no member named 'word' ../../iocore/cache/P_CacheVol.h: In member function 'void Vol::set_migrate_failed(MigrateToInterimCache*)': ../../iocore/cache/P_CacheVol.h:496: error: 'union INK_MD5' has no member named 'word' ../../iocore/cache/P_CacheVol.h: In member function 'void Vol::set_migrate_done(MigrateToInterimCache*)': ../../iocore/cache/P_CacheVol.h:501: error: 'union INK_MD5' has no member named 'word' In file included from ../../iocore/cache/P_Cache.h:43, from ../../iocore/cluster/P_Cluster.h:31, from P_HostDB.h:38, from HostDB.cc:26: ../../iocore/cache/P_CacheVol.h: In member function 'void Vol::set_migrate_in_progress(MigrateToInterimCache*)': ../../iocore/cache/P_CacheVol.h:491: error: 'union INK_MD5' has no member named 'word' ../../iocore/cache/P_CacheVol.h: In member function 'void Vol::set_migrate_failed(MigrateToInterimCache*)': ../../iocore/cache/P_CacheVol.h:496: error: 'union INK_MD5' has no member named 'word' ../../iocore/cache/P_CacheVol.h: In member function 'void Vol::set_migrate_done(MigrateToInterimCache*)': ../../iocore/cache/P_CacheVol.h:501: error: 'union INK_MD5' has no member named 'word' make[2]: *** [MultiCache.o] Error 1 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2982) build error from gitmaster
[ https://issues.apache.org/jira/browse/TS-2982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] bettydramit updated TS-2982: Summary: build error from gitmaster (was: build error) build error from gitmaster -- Key: TS-2982 URL: https://issues.apache.org/jira/browse/TS-2982 Project: Traffic Server Issue Type: Bug Reporter: bettydramit git master In file included from ../../iocore/cache/P_Cache.h:43, from ../../iocore/cluster/P_Cluster.h:31, from P_HostDB.h:38, from MultiCache.cc:33: ../../iocore/cache/P_CacheVol.h: In member function 'void Vol::set_migrate_in_progress(MigrateToInterimCache*)': ../../iocore/cache/P_CacheVol.h:491: error: 'union INK_MD5' has no member named 'word' ../../iocore/cache/P_CacheVol.h: In member function 'void Vol::set_migrate_failed(MigrateToInterimCache*)': ../../iocore/cache/P_CacheVol.h:496: error: 'union INK_MD5' has no member named 'word' ../../iocore/cache/P_CacheVol.h: In member function 'void Vol::set_migrate_done(MigrateToInterimCache*)': ../../iocore/cache/P_CacheVol.h:501: error: 'union INK_MD5' has no member named 'word' In file included from ../../iocore/cache/P_Cache.h:43, from ../../iocore/cluster/P_Cluster.h:31, from P_HostDB.h:38, from HostDB.cc:26: ../../iocore/cache/P_CacheVol.h: In member function 'void Vol::set_migrate_in_progress(MigrateToInterimCache*)': ../../iocore/cache/P_CacheVol.h:491: error: 'union INK_MD5' has no member named 'word' ../../iocore/cache/P_CacheVol.h: In member function 'void Vol::set_migrate_failed(MigrateToInterimCache*)': ../../iocore/cache/P_CacheVol.h:496: error: 'union INK_MD5' has no member named 'word' ../../iocore/cache/P_CacheVol.h: In member function 'void Vol::set_migrate_done(MigrateToInterimCache*)': ../../iocore/cache/P_CacheVol.h:501: error: 'union INK_MD5' has no member named 'word' make[2]: *** [MultiCache.o] Error 1 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2977) move traffic_manager under cmd subdirectory
[ https://issues.apache.org/jira/browse/TS-2977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14083306#comment-14083306 ] ASF subversion and git services commented on TS-2977: - Commit 9e6d233fe647863adb7b093cd6643739f73c7c8e in trafficserver's branch refs/heads/master from [~jpe...@apache.org] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=9e6d233 ] TS-2977: move the stats processor to traffic_manager move traffic_manager under cmd subdirectory --- Key: TS-2977 URL: https://issues.apache.org/jira/browse/TS-2977 Project: Traffic Server Issue Type: Improvement Components: Cleanup Reporter: James Peach Assignee: James Peach Fix For: 5.1.0 The management code is pretty complicated and hard to understand. Separating traffic_manager out under the cmd/ subdirectory will give a clearer separation between the management library code and the application, and make it consistent with the rest of the tooling. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2977) move traffic_manager under cmd subdirectory
[ https://issues.apache.org/jira/browse/TS-2977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14083307#comment-14083307 ] ASF subversion and git services commented on TS-2977: - Commit 1bba62b68cad0cfb5bba8d6d4c1b735f80408e88 in trafficserver's branch refs/heads/master from [~jpe...@apache.org] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=1bba62b ] TS-2977: incorporate libutils into libmgmt Simplify the link topology by incorporating libutils into libmgmt. Management clients don't need to know the gory details. move traffic_manager under cmd subdirectory --- Key: TS-2977 URL: https://issues.apache.org/jira/browse/TS-2977 Project: Traffic Server Issue Type: Improvement Components: Cleanup Reporter: James Peach Assignee: James Peach Fix For: 5.1.0 The management code is pretty complicated and hard to understand. Separating traffic_manager out under the cmd/ subdirectory will give a clearer separation between the management library code and the application, and make it consistent with the rest of the tooling. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2977) move traffic_manager under cmd subdirectory
[ https://issues.apache.org/jira/browse/TS-2977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14083310#comment-14083310 ] ASF subversion and git services commented on TS-2977: - Commit c936bc514500173bd2075888062eb8618899947e in trafficserver's branch refs/heads/master from [~jpe...@apache.org] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=c936bc5 ] TS-2977: CHANGES move traffic_manager under cmd subdirectory --- Key: TS-2977 URL: https://issues.apache.org/jira/browse/TS-2977 Project: Traffic Server Issue Type: Improvement Components: Cleanup Reporter: James Peach Assignee: James Peach Fix For: 5.1.0 The management code is pretty complicated and hard to understand. Separating traffic_manager out under the cmd/ subdirectory will give a clearer separation between the management library code and the application, and make it consistent with the rest of the tooling. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2977) move traffic_manager under cmd subdirectory
[ https://issues.apache.org/jira/browse/TS-2977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14083309#comment-14083309 ] ASF subversion and git services commented on TS-2977: - Commit ab8c0cd21a0ab6e832e969f006ace578661c4d47 in trafficserver's branch refs/heads/master from [~jpe...@apache.org] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=ab8c0cd ] TS-2977: rename traffic_manager Main.cc Rename traffic_manager's Main.cc to traffic_manager.cc. Remove Main.h, retaining just the 2 or 3 things from it that are used. move traffic_manager under cmd subdirectory --- Key: TS-2977 URL: https://issues.apache.org/jira/browse/TS-2977 Project: Traffic Server Issue Type: Improvement Components: Cleanup Reporter: James Peach Assignee: James Peach Fix For: 5.1.0 The management code is pretty complicated and hard to understand. Separating traffic_manager out under the cmd/ subdirectory will give a clearer separation between the management library code and the application, and make it consistent with the rest of the tooling. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2977) move traffic_manager under cmd subdirectory
[ https://issues.apache.org/jira/browse/TS-2977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14083308#comment-14083308 ] ASF subversion and git services commented on TS-2977: - Commit ff716f219a86284fb980ba2ed05c41105ce274ef in trafficserver's branch refs/heads/master from [~jpe...@apache.org] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=ff716f2 ] TS-2977: minimize web2 and cluster in the headers search path move traffic_manager under cmd subdirectory --- Key: TS-2977 URL: https://issues.apache.org/jira/browse/TS-2977 Project: Traffic Server Issue Type: Improvement Components: Cleanup Reporter: James Peach Assignee: James Peach Fix For: 5.1.0 The management code is pretty complicated and hard to understand. Separating traffic_manager out under the cmd/ subdirectory will give a clearer separation between the management library code and the application, and make it consistent with the rest of the tooling. -- This message was sent by Atlassian JIRA (v6.2#6252)
