date:20160407

[jira] [Updated] (TS-4329) Off-by-one error in NULL terminator for aname in hostdb

2016-04-07 Thread Leif Hedstrom (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-4329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-4329:
--
Fix Version/s: 6.2.0

> Off-by-one error in NULL terminator for aname in hostdb
> ---
>
> Key: TS-4329
> URL: https://issues.apache.org/jira/browse/TS-4329
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: 6.2.0
>
>
> This line 
> https://github.com/apache/trafficserver/blob/master/iocore/hostdb/HostDB.cc#L1373
> Is off by one, and ink_strlcpy takes care of it so we can just remove the 
> line.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4333) The CacheKey plugin cannot conditionally modify the cache key based on headers in the request.

2016-04-07 Thread Leif Hedstrom (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-4333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-4333:
--
Fix Version/s: 7.0.0

> The CacheKey plugin cannot conditionally modify the cache key based on 
> headers in the request.
> --
>
> Key: TS-4333
> URL: https://issues.apache.org/jira/browse/TS-4333
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: Nolan Astrein
> Fix For: 7.0.0
>
>
> A TrafficServer administrator should be able to supply a list of mandatory 
> headers as a parameter to the CacheKey plugin.  The CacheKey plugin should 
> only modify the cache key when the all of the mandatory headers are present 
> in the request.  If any of the mandatory headers are not present in the 
> request the cache key should not be modified by the CacheKey plugin.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4334) The cache_range_requests plugin always attempts to modify the cache key.

2016-04-07 Thread Leif Hedstrom (JIRA)


[ 
https://issues.apache.org/jira/browse/TS-4334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15231217#comment-15231217
 ] 

Leif Hedstrom commented on TS-4334:
---

[~gancho] Would you like to shepherd this as well? We can expect a PR on this 
soonish.

> The cache_range_requests plugin always attempts to modify the cache key.
> 
>
> Key: TS-4334
> URL: https://issues.apache.org/jira/browse/TS-4334
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: Nolan Astrein
> Fix For: 7.0.0
>
>
> A TrafficServer administrator should be able to specify whether or not the 
> cache_range_requests plugin should modify the cache key.  The cache key may 
> be modified by a previous plugin in a plugin chain and there is no way to 
> configure cache_range_requests not to do any further modifications to the 
> cache key.  Having multiple plugins responsible for cache key modifications 
> can cause unexpected behavior, especially when a plugin chain ordering is 
> changed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4334) The cache_range_requests plugin always attempts to modify the cache key.

2016-04-07 Thread Leif Hedstrom (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-4334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-4334:
--
Fix Version/s: 7.0.0

> The cache_range_requests plugin always attempts to modify the cache key.
> 
>
> Key: TS-4334
> URL: https://issues.apache.org/jira/browse/TS-4334
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: Nolan Astrein
> Fix For: 7.0.0
>
>
> A TrafficServer administrator should be able to specify whether or not the 
> cache_range_requests plugin should modify the cache key.  The cache key may 
> be modified by a previous plugin in a plugin chain and there is no way to 
> configure cache_range_requests not to do any further modifications to the 
> cache key.  Having multiple plugins responsible for cache key modifications 
> can cause unexpected behavior, especially when a plugin chain ordering is 
> changed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4333) The CacheKey plugin cannot conditionally modify the cache key based on headers in the request.

2016-04-07 Thread Leif Hedstrom (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-4333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-4333:
--
Assignee: Gancho Tenev

> The CacheKey plugin cannot conditionally modify the cache key based on 
> headers in the request.
> --
>
> Key: TS-4333
> URL: https://issues.apache.org/jira/browse/TS-4333
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: Nolan Astrein
>Assignee: Gancho Tenev
> Fix For: 7.0.0
>
>
> A TrafficServer administrator should be able to supply a list of mandatory 
> headers as a parameter to the CacheKey plugin.  The CacheKey plugin should 
> only modify the cache key when the all of the mandatory headers are present 
> in the request.  If any of the mandatory headers are not present in the 
> request the cache key should not be modified by the CacheKey plugin.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4333) The CacheKey plugin cannot conditionally modify the cache key based on headers in the request.

2016-04-07 Thread Leif Hedstrom (JIRA)


[ 
https://issues.apache.org/jira/browse/TS-4333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15231218#comment-15231218
 ] 

Leif Hedstrom commented on TS-4333:
---

[~gancho] Assigning this to you, to shepherd the PR when it arrives.

> The CacheKey plugin cannot conditionally modify the cache key based on 
> headers in the request.
> --
>
> Key: TS-4333
> URL: https://issues.apache.org/jira/browse/TS-4333
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: Nolan Astrein
>Assignee: Gancho Tenev
> Fix For: 7.0.0
>
>
> A TrafficServer administrator should be able to supply a list of mandatory 
> headers as a parameter to the CacheKey plugin.  The CacheKey plugin should 
> only modify the cache key when the all of the mandatory headers are present 
> in the request.  If any of the mandatory headers are not present in the 
> request the cache key should not be modified by the CacheKey plugin.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4207) Crash in HostDB, likely a regression from 5.x

2016-04-07 Thread Leif Hedstrom (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-4207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-4207:
--
Labels: crash  (was: backport crash)

> Crash in HostDB, likely a regression from 5.x
> -
>
> Key: TS-4207
> URL: https://issues.apache.org/jira/browse/TS-4207
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HostDB
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
>Priority: Blocker
>  Labels: crash
> Fix For: 6.2.0
>
>
> We're seeing a new crash in HostDB, which did not occur in 5.3.x:
> {code}
> (gdb) bt
> #0  0x2ac7b2bb in HttpSM::process_hostdb_info(HostDBInfo*) () at 
> ../../iocore/hostdb/P_HostDBProcessor.h:295
> #1  0x2ac88b16 in HttpSM::state_hostdb_lookup(int, void*) () at 
> HttpSM.cc:2126
> #2  0x2ac9713d in HttpSM::main_handler(int, void*) () at 
> HttpSM.cc:2561
> #3  0x2ad7803e in reply_to_cont(Continuation*, HostDBInfo*, bool) () 
> at ../../iocore/eventsystem/I_Continuation.h:153
> #4  0x2ad7eca5 in HostDBContinuation::dnsEvent(int, HostEnt*) () at 
> HostDB.cc:1685
> #5  0x2ad98faf in DNSEntry::postEvent(int, Event*) () at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #6  0x2ae7e420 in EThread::process_event(Event*, int) () at 
> I_Continuation.h:153
> #7  0x2ae7f2ab in EThread::execute() () at UnixEThread.cc:179
> #8  0x2ae7de06 in spawn_thread_internal(void*) () at Thread.cc:86
> #9  0x2d6ac9d1 in start_thread () from /lib64/libpthread.so.0
> #10 0x2e8b58fd in clone () from /lib64/libc.so.6
> {code}
> I think some inlining here complicates things, what it looks like the "r" is 
> NULL, but it somehow still ends up using r->rr ?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (TS-4332) proxy.config.net.connections_throttle should allow for immediate error return when accepts reach throttle limit

2016-04-07 Thread Susan Hinrichs (JIRA)

Susan Hinrichs created TS-4332:
--

 Summary: proxy.config.net.connections_throttle should allow for 
immediate error return when accepts reach throttle limit
 Key: TS-4332
 URL: https://issues.apache.org/jira/browse/TS-4332
 Project: Traffic Server
  Issue Type: Bug
  Components: Network
Reporter: Susan Hinrichs


When the throttling kicks in future connections to origins will cause a 502 to 
be returned to the user agent.

But when an accept happens during the throttling period, a message is only sent 
if the unix_netProcessor.throttle_error_message member variable is set.  In the 
current code, this member variable is never set.  If the variable is not set, 
the logic blocks for 100ms and tries again.

This spinning causes the ATS process to waste resources.  It would be better to 
immediately turn around and send an error response (probably 503 instead of 
502).

I tested a build that hard coded an error message and it seemed to recover much 
better.

I propose adding some config variables to control the throttling behavior.

proxy.config.connections_throttle.error_code  - HTTP response code to return 
(or just hard code this to 503)
proxy.config.connections_throttle.error_page - Reference to an error page to 
return.

If both are unset, the existing delaying logic is used.  If either is set, 
either a error header or a header and body are returned immediately.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (TS-4331) Hostdb consistency problems due to MultiCache

2016-04-07 Thread Thomas Jackson (JIRA)

Thomas Jackson created TS-4331:
--

 Summary: Hostdb consistency problems due to MultiCache
 Key: TS-4331
 URL: https://issues.apache.org/jira/browse/TS-4331
 Project: Traffic Server
  Issue Type: Bug
Reporter: Thomas Jackson


This ticket is for the correct long term fix to TS-4207

pulled from a comment, which wraps up the issue

{quote}
Leif Hedstrom I have spent a decent amount of time on this while I was OOO on 
vacation the last couple of weeks. It seems that the root cause of this issue 
has always existed, and that the addition of always doing hostname storing 
(https://github.com/apache/trafficserver/commit/0e703e1e) we are just causing 
the issue to happen all the time.
To understand the issue I'll give a little background in how hostdb is 
currently working. Basically hostdb is just a wrapper around this templated 
struct called MultiCache. MultiCache is "multi" not because it is templated, 
but because it has two types of storage (static-- blocks and dynamic-- alloc). 
The static side of the cache can hold N HostDBInfo structs (the results of DNS 
queries). The dynamic side is used to store the round robin records and various 
strings associated with the record. The size of this dynamic space is defined 
as (N x [estimated_heap_bytes_per_entry. The basic problem we are running into 
is that we are putting too much preassure on the dynamic heap-- such that the 
heap is getting re-used while people still have references to items in that 
space.
So, I've actually been working on re-writing MultiCache to allocate the entire 
required block at once (so we don't have this problem where the parent exists 
but not the children), but I'm not certain if we want such a change to go into 
the 6.x branch (I'm willing to discuss if we want). If we aren't comfortable 
with such a large change I suggest just accounting for the hostname size in the 
estimated_heap_bytes_per_entry as a stopgap solution. The maximum allowable 
size is 253 (so 254 with null terminator), but we could pick a smaller number 
(~120 or so seems to be more reasonable). Alternatively you can increase the 
number of records in hostdb (and the size accordingly) to increase the dynamic 
heap size.
TLDR; almost done with the long term solution, but I'm not sure if we want to 
merge that into 6.x-- alternatively we can do a simple workaround in 6.x 
(https://github.com/apache/trafficserver/pull/553)
{quote}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (TS-4331) Hostdb consistency problems due to MultiCache

2016-04-07 Thread Thomas Jackson (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-4331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Jackson reassigned TS-4331:
--

Assignee: Thomas Jackson

> Hostdb consistency problems due to MultiCache
> -
>
> Key: TS-4331
> URL: https://issues.apache.org/jira/browse/TS-4331
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
>
> This ticket is for the correct long term fix to TS-4207
> pulled from a comment, which wraps up the issue
> {quote}
> Leif Hedstrom I have spent a decent amount of time on this while I was OOO on 
> vacation the last couple of weeks. It seems that the root cause of this issue 
> has always existed, and that the addition of always doing hostname storing 
> (https://github.com/apache/trafficserver/commit/0e703e1e) we are just causing 
> the issue to happen all the time.
> To understand the issue I'll give a little background in how hostdb is 
> currently working. Basically hostdb is just a wrapper around this templated 
> struct called MultiCache. MultiCache is "multi" not because it is templated, 
> but because it has two types of storage (static-- blocks and dynamic-- 
> alloc). The static side of the cache can hold N HostDBInfo structs (the 
> results of DNS queries). The dynamic side is used to store the round robin 
> records and various strings associated with the record. The size of this 
> dynamic space is defined as (N x [estimated_heap_bytes_per_entry. The basic 
> problem we are running into is that we are putting too much preassure on the 
> dynamic heap-- such that the heap is getting re-used while people still have 
> references to items in that space.
> So, I've actually been working on re-writing MultiCache to allocate the 
> entire required block at once (so we don't have this problem where the parent 
> exists but not the children), but I'm not certain if we want such a change to 
> go into the 6.x branch (I'm willing to discuss if we want). If we aren't 
> comfortable with such a large change I suggest just accounting for the 
> hostname size in the estimated_heap_bytes_per_entry as a stopgap solution. 
> The maximum allowable size is 253 (so 254 with null terminator), but we could 
> pick a smaller number (~120 or so seems to be more reasonable). Alternatively 
> you can increase the number of records in hostdb (and the size accordingly) 
> to increase the dynamic heap size.
> TLDR; almost done with the long term solution, but I'm not sure if we want to 
> merge that into 6.x-- alternatively we can do a simple workaround in 6.x 
> (https://github.com/apache/trafficserver/pull/553)
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Build failed in Jenkins: clang-format #680

2016-04-07 Thread jenkins

See 

Changes:

[Thomas Jackson] Workaround for TS-4207

--
[...truncated 1604 lines...]
./proxy/logging/LogFormat.h
./proxy/logging/LogFormat.cc
./proxy/logging/LogFile.cc
./proxy/logging/LogCollationHostSM.h
./proxy/logging/LogFieldAliasMap.cc
./proxy/logging/LogHost.h
./proxy/logging/LogAccessHttp.h
./proxy/logging/LogCollationAccept.h
./proxy/logging/LogBuffer.h
./proxy/logging/LogLimits.h
./proxy/logging/LogAccessTest.cc
./proxy/logging/LogAccess.cc
./proxy/logging/LogCollationHostSM.cc
./proxy/logging/Log.h
./proxy/logging/LogAccess.h
./proxy/logging/LogAccessTest.h
./proxy/logging/LogStandalone.cc
./proxy/logging/LogField.cc
./proxy/logging/LogConfig.h
./proxy/logging/LogCollationClientSM.h
./proxy/ParentConsistentHash.cc
./proxy/StufferUdpReceiver.cc
./proxy/ICPevents.h
./proxy/logstats.cc
./proxy/UDPAPITest.cc
./proxy/api/ts/InkAPIPrivateIOCore.h
./proxy/api/ts/ts.h
./proxy/api/ts/experimental.h
./proxy/api/ts/TsException.h
./proxy/api/ts/remap.h
./proxy/Milestones.h
./proxy/Transform.cc
./proxy/test_xml_parser.cc
./proxy/AbstractBuffer.h
./proxy/CoreUtils.h
./proxy/ControlMatcher.cc
./proxy/ICPStats.cc
./proxy/TransformInternal.h
./proxy/Main.h
./proxy/ICPlog.h
./proxy/StatPages.cc
./proxy/ProtocolProbeSessionAccept.cc
./proxy/logcat.cc
./proxy/AbstractBuffer.cc
./proxy/TestDNS.cc
./proxy/Plugin.h
./proxy/congest/Congestion.h
./proxy/congest/CongestionTest.cc
./proxy/congest/CongestionStats.h
./proxy/congest/CongestionDB.h
./proxy/congest/CongestionStats.cc
./proxy/congest/CongestionDB.cc
./proxy/congest/Congestion.cc
./proxy/congest/MT_hashtable.h
./proxy/TestPreProc.cc
./proxy/ProtocolProbeSessionAccept.h
./proxy/FetchSM.h
./proxy/Crash.cc
./proxy/ParentRoundRobin.h
./proxy/InkAPIInternal.h
./proxy/Show.h
./proxy/spdy/SpdyDefs.h
./proxy/spdy/SpdySessionAccept.h
./proxy/spdy/SpdySessionAccept.cc
./proxy/spdy/SpdyClientSession.h
./proxy/spdy/SpdyClientSession.cc
./proxy/spdy/SpdyCallbacks.cc
./proxy/spdy/SpdyCommon.h
./proxy/spdy/SpdyCommon.cc
./proxy/spdy/SpdyCallbacks.h
./proxy/PluginVC.h
./proxy/RegressionSM.cc
./proxy/FetchSM.cc
./proxy/TestClusterHash.cc
./proxy/ParentRoundRobin.cc
./proxy/TimeTrace.h
./proxy/ParentSelection.h
./proxy/InkIOCoreAPI.cc
./proxy/Transform.h
./proxy/InkAPI.cc
./proxy/RegressionSM.h
./proxy/ProxyClientSession.cc
./proxy/CoreUtils.cc
./proxy/shared/Error.h
./proxy/shared/UglyLogStubs.cc
./proxy/shared/DiagsConfig.h
./proxy/shared/InkXml.cc
./proxy/shared/DiagsConfig.cc
./proxy/shared/InkXml.h
./proxy/shared/Error.cc
./proxy/UnixCompletionUtil.h
./proxy/ICPConfig.cc
./proxy/IPAllow.h
./proxy/TestProxy.cc
./proxy/ParentSelection.cc
./proxy/HttpTransStats.h
./proxy/PluginVC.cc
./proxy/EventName.h
./proxy/TestSimpleProxy.cc
./proxy/ConfigParse.h
./proxy/Prefetch.h
./proxy/http/TestUrl.cc
./proxy/http/HttpBodyFactory.h
./proxy/http/HttpClientSession.h
./proxy/http/HttpTransactHeaders.cc
./proxy/http/HttpTransact.cc
./proxy/http/HttpPages.h
./proxy/http/HttpProxyServerMain.cc
./proxy/http/HttpServerSession.h
./proxy/http/HttpPages.cc
./proxy/http/HttpTunnel.cc
./proxy/http/TestHttpTransact.cc
./proxy/http/test_socket_close.cc
./proxy/http/HttpSM.cc
./proxy/http/HttpConfig.h
./proxy/http/HttpUpdateTester.cc
./proxy/http/HttpSessionManager.h
./proxy/http/HttpProxyAPIEnums.h
./proxy/http/HttpCacheSM.cc
./proxy/http/HttpTransactHeaders.h
./proxy/http/HttpTransactCache.h
./proxy/http/HttpTransactCache.cc
./proxy/http/HttpProxyServerMain.h
./proxy/http/HttpTunnel.h
./proxy/http/HttpUpdateSM.h
./proxy/http/HttpDebugNames.h
./proxy/http/HttpBodyFactory.cc
./proxy/http/HttpClientSession.cc
./proxy/http/HttpTransact.h
./proxy/http/HttpConfig.cc
./proxy/http/HttpServerSession.cc
./proxy/http/HttpUpdateSM.cc
./proxy/http/HttpConnectionCount.h
./proxy/http/testheaders.cc
./proxy/http/HttpConnectionCount.cc
./proxy/http/HttpSessionAccept.h
./proxy/http/HttpDebugNames.cc
./proxy/http/RegressionHttpTransact.cc
./proxy/http/HttpSessionAccept.cc
./proxy/http/remap/RemapConfig.cc
./proxy/http/remap/UrlMapping.h
./proxy/http/remap/RemapProcessor.h
./proxy/http/remap/UrlRewrite.h
./proxy/http/remap/RemapPlugins.cc
./proxy/http/remap/UrlMapping.cc
./proxy/http/remap/AclFiltering.h
./proxy/http/remap/RemapPluginInfo.h
./proxy/http/remap/UrlMappingPathIndex.h
./proxy/http/remap/RemapProcessor.cc
./proxy/http/remap/RemapPlugins.h
./proxy/http/remap/UrlRewrite.cc
./proxy/http/remap/RemapPluginInfo.cc
./proxy/http/remap/RemapConfig.h
./proxy/http/remap/AclFiltering.cc
./proxy/http/remap/UrlMappingPathIndex.cc
./proxy/http/HttpSessionManager.cc
./proxy/http/HttpCacheSM.h
./proxy/http/HttpSM.h
./proxy/TestRegex.cc
./proxy/IPAllow.cc
./proxy/ICPProcessor.cc
./proxy/ReverseProxy.cc
./proxy/ControlMatcher.h
./proxy/SocksProxy.cc
./proxy/UDPAPITest.h
./proxy/UserNameCacheTest.h
./proxy/ICP.h
./proxy/ProxyClientSession.h
./proxy/ParentConsistentHash.h
./proxy/CacheControl.h
./proxy/InkAPITestTool.cc

[jira] [Commented] (TS-4090) CID 1343359, 1343358: Coverity issues in new memcached plugin

2016-04-07 Thread John Rushford (JIRA)


[ 
https://issues.apache.org/jira/browse/TS-4090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15230699#comment-15230699
 ] 

John Rushford commented on TS-4090:
---

okay, I'll fix them.

> CID 1343359, 1343358: Coverity issues in new memcached plugin
> -
>
> Key: TS-4090
> URL: https://issues.apache.org/jira/browse/TS-4090
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: Leif Hedstrom
>Assignee: John Rushford
>  Labels: coverity
> Fix For: 6.2.0
>
>
> Hi [~jplevyak],
> can you please take a look at this? I'm merging this new plugin into 6.1.x as 
> well, so it'd be great to have these fixed.
> {code}
> *** CID 1343359:(DEADCODE)
> /plugins/experimental/memcache/tsmemcache.cc: 483 in 
> MC::binary_get_event(int, void *)()
> 477   if (event != TSMEMCACHE_EVENT_GOT_ITEM) {
> 478 CHECK_READ_AVAIL(binary_header.request.keylen, ::binary_get);
> 479 key = binary_get_key(this);
> 480 header.nkey = binary_header.request.keylen;
> 481 return get_item();
> 482   } else if (event == CACHE_EVENT_OPEN_READ_FAILED) {
>CID 1343359:(DEADCODE)
>Execution cannot reach this statement: "if ((*this).f.noreply)
>  re...".
> 483 if (f.noreply)
> 484   return read_from_client();
> 485 if (binary_header.request.opcode == PROTOCOL_BINARY_CMD_GETK) {
> 486   add_binary_header(PROTOCOL_BINARY_RESPONSE_KEY_ENOENT, 0, 
> header.nkey, header.nkey);
> 487   wbuf->write(key, header.nkey);
> 488   return write_then_read_from_client();
> /plugins/experimental/memcache/tsmemcache.cc: 492 in 
> MC::binary_get_event(int, void *)()
> 486   add_binary_header(PROTOCOL_BINARY_RESPONSE_KEY_ENOENT, 0, 
> header.nkey, header.nkey);
> 487   wbuf->write(key, header.nkey);
> 488   return write_then_read_from_client();
> 489 } else
> 490   return write_binary_error(PROTOCOL_BINARY_RESPONSE_KEY_ENOENT, 
> 0);
> 491   } else if (event == CACHE_EVENT_OPEN_READ) {
>CID 1343359:(DEADCODE)
>Execution cannot reach this statement: "rsp = >res.get;".
> 492 protocol_binary_response_get *rsp = 
> 493 uint16_t keylen = 0;
> 494 uint32_t bodylen = sizeof(rsp->message.body) + 
> (rcache_header->nbytes - 2);
> 495 bool getk =
> 496   (binary_header.request.opcode == PROTOCOL_BINARY_CMD_GETK || 
> binary_header.request.opcode == PROTOCOL_BINARY_CMD_GETKQ);
> 497 if (getk) {
> ** CID 1343358:  Uninitialized members  (UNINIT_CTOR)
> /plugins/experimental/memcache/tsmemcache.h: 95 in MCAccept::MCAccept()()
> 
> *** CID 1343358:  Uninitialized members  (UNINIT_CTOR)
> /plugins/experimental/memcache/tsmemcache.h: 95 in MCAccept::MCAccept()()
> 89   MCAccept()
> 90 #ifndef HAVE_TLS
> 91 : theMCThreadAllocator(NULL)
> 92 #endif
> 93   {
> 94 SET_HANDLER(::main_event);
>CID 1343358:  Uninitialized members  (UNINIT_CTOR)
>Non-static class member "accept_port" is not initialized in this 
> constructor nor in any functions that it calls.
> 95   }
> 96 };
> 97 
> 98 #define TS_PUSH_HANDLER(_h)\
> 99   do { \
> 100 handler_stack[ihandler_stack++] = handler; \
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4207) Crash in HostDB, likely a regression from 5.x

2016-04-07 Thread Thomas Jackson (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-4207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Jackson updated TS-4207:
---
Labels: backport crash  (was: back backport crash)

> Crash in HostDB, likely a regression from 5.x
> -
>
> Key: TS-4207
> URL: https://issues.apache.org/jira/browse/TS-4207
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HostDB
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
>Priority: Blocker
>  Labels: backport, crash
> Fix For: 6.2.0
>
>
> We're seeing a new crash in HostDB, which did not occur in 5.3.x:
> {code}
> (gdb) bt
> #0  0x2ac7b2bb in HttpSM::process_hostdb_info(HostDBInfo*) () at 
> ../../iocore/hostdb/P_HostDBProcessor.h:295
> #1  0x2ac88b16 in HttpSM::state_hostdb_lookup(int, void*) () at 
> HttpSM.cc:2126
> #2  0x2ac9713d in HttpSM::main_handler(int, void*) () at 
> HttpSM.cc:2561
> #3  0x2ad7803e in reply_to_cont(Continuation*, HostDBInfo*, bool) () 
> at ../../iocore/eventsystem/I_Continuation.h:153
> #4  0x2ad7eca5 in HostDBContinuation::dnsEvent(int, HostEnt*) () at 
> HostDB.cc:1685
> #5  0x2ad98faf in DNSEntry::postEvent(int, Event*) () at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #6  0x2ae7e420 in EThread::process_event(Event*, int) () at 
> I_Continuation.h:153
> #7  0x2ae7f2ab in EThread::execute() () at UnixEThread.cc:179
> #8  0x2ae7de06 in spawn_thread_internal(void*) () at Thread.cc:86
> #9  0x2d6ac9d1 in start_thread () from /lib64/libpthread.so.0
> #10 0x2e8b58fd in clone () from /lib64/libc.so.6
> {code}
> I think some inlining here complicates things, what it looks like the "r" is 
> NULL, but it somehow still ends up using r->rr ?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4299) FetchSM / H2 streams can hang if e.g. a plugin adds a Connection: close header

2016-04-07 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/TS-4299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15230689#comment-15230689
 ] 

ASF GitHub Bot commented on TS-4299:


Github user asfgit closed the pull request at:

https://github.com/apache/trafficserver/pull/549


> FetchSM / H2 streams can hang if e.g. a plugin adds a Connection: close header
> --
>
> Key: TS-4299
> URL: https://issues.apache.org/jira/browse/TS-4299
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, HTTP/2
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 6.2.0
>
>
> We use header_rewrite to inject Connection: close under certain conditions 
> (to prevent KA connections from lingering forever during e.g. server 
> maintenance). However, this interacts poorly with the FetchSM, and therefore, 
> poorly with H2. Basically, the connection "hangs" because the FetchSM thinks 
> there's more body data (when there really isn't).
> The issue comes from this code:
> {code}
> bool
> FetchSM::has_body()
> {
>   int status_code;
>   HTTPHdr *hdr;
>   if (!header_done)
> return false;
>   if (is_method_head)
> return false;
>   //
>   // The following code comply with HTTP/1.1:
>   // http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.4
>   //
>   hdr = _response_hdr;
>   status_code = hdr->status_get();
>   if (status_code < 200 || status_code == 204 || status_code == 304)
> return false;
>   if (check_chunked())
> return true;
>   if (check_connection_close())
> return true;
>   resp_content_length = hdr->value_get_int64(MIME_FIELD_CONTENT_LENGTH, 
> MIME_LEN_CONTENT_LENGTH);
>   if (!resp_content_length)
> return false;
>   return true;
> }
> {code}
> The issue is that it returns "true" if there is a Connection: close header. 
> I'm not 100% sure what the best solution here, simply removing this doesn't 
> seem right since it's obviously there to deal with some cases of FetchSM 
> which are not H2. A couple of unscientific options are
> 1) Make sure the H2 code assures that the Connection header is removed in all 
> cases. I know it deals with it in a few cases, except in this case we add the 
> Connection: close in the response header object, which therefore enters into 
> the FetchSM as well.
> 2) Have additional state / information in the FetchSM, indicating if 
> "connection" has semantics or not for this particular FetchSM. E.g. 
> fetch_sm->set_connection_aware(false);



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4299) FetchSM / H2 streams can hang if e.g. a plugin adds a Connection: close header

2016-04-07 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/TS-4299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15230688#comment-15230688
 ] 

ASF subversion and git services commented on TS-4299:
-

Commit f0ce965e3ded41ad55e199f4eb9f883c08446d96 in trafficserver's branch 
refs/heads/master from [~zwoop]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=f0ce965 ]

TS-4299 Allows for the content length to be processed even with C: close

This closes #549


> FetchSM / H2 streams can hang if e.g. a plugin adds a Connection: close header
> --
>
> Key: TS-4299
> URL: https://issues.apache.org/jira/browse/TS-4299
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, HTTP/2
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 6.2.0
>
>
> We use header_rewrite to inject Connection: close under certain conditions 
> (to prevent KA connections from lingering forever during e.g. server 
> maintenance). However, this interacts poorly with the FetchSM, and therefore, 
> poorly with H2. Basically, the connection "hangs" because the FetchSM thinks 
> there's more body data (when there really isn't).
> The issue comes from this code:
> {code}
> bool
> FetchSM::has_body()
> {
>   int status_code;
>   HTTPHdr *hdr;
>   if (!header_done)
> return false;
>   if (is_method_head)
> return false;
>   //
>   // The following code comply with HTTP/1.1:
>   // http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.4
>   //
>   hdr = _response_hdr;
>   status_code = hdr->status_get();
>   if (status_code < 200 || status_code == 204 || status_code == 304)
> return false;
>   if (check_chunked())
> return true;
>   if (check_connection_close())
> return true;
>   resp_content_length = hdr->value_get_int64(MIME_FIELD_CONTENT_LENGTH, 
> MIME_LEN_CONTENT_LENGTH);
>   if (!resp_content_length)
> return false;
>   return true;
> }
> {code}
> The issue is that it returns "true" if there is a Connection: close header. 
> I'm not 100% sure what the best solution here, simply removing this doesn't 
> seem right since it's obviously there to deal with some cases of FetchSM 
> which are not H2. A couple of unscientific options are
> 1) Make sure the H2 code assures that the Connection header is removed in all 
> cases. I know it deals with it in a few cases, except in this case we add the 
> Connection: close in the response header object, which therefore enters into 
> the FetchSM as well.
> 2) Have additional state / information in the FetchSM, indicating if 
> "connection" has semantics or not for this particular FetchSM. E.g. 
> fetch_sm->set_connection_aware(false);



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4207) Crash in HostDB, likely a regression from 5.x

2016-04-07 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/TS-4207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15230829#comment-15230829
 ] 

ASF GitHub Bot commented on TS-4207:


Github user asfgit closed the pull request at:

https://github.com/apache/trafficserver/pull/553


> Crash in HostDB, likely a regression from 5.x
> -
>
> Key: TS-4207
> URL: https://issues.apache.org/jira/browse/TS-4207
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HostDB
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
>Priority: Blocker
>  Labels: crash
> Fix For: 6.2.0
>
>
> We're seeing a new crash in HostDB, which did not occur in 5.3.x:
> {code}
> (gdb) bt
> #0  0x2ac7b2bb in HttpSM::process_hostdb_info(HostDBInfo*) () at 
> ../../iocore/hostdb/P_HostDBProcessor.h:295
> #1  0x2ac88b16 in HttpSM::state_hostdb_lookup(int, void*) () at 
> HttpSM.cc:2126
> #2  0x2ac9713d in HttpSM::main_handler(int, void*) () at 
> HttpSM.cc:2561
> #3  0x2ad7803e in reply_to_cont(Continuation*, HostDBInfo*, bool) () 
> at ../../iocore/eventsystem/I_Continuation.h:153
> #4  0x2ad7eca5 in HostDBContinuation::dnsEvent(int, HostEnt*) () at 
> HostDB.cc:1685
> #5  0x2ad98faf in DNSEntry::postEvent(int, Event*) () at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #6  0x2ae7e420 in EThread::process_event(Event*, int) () at 
> I_Continuation.h:153
> #7  0x2ae7f2ab in EThread::execute() () at UnixEThread.cc:179
> #8  0x2ae7de06 in spawn_thread_internal(void*) () at Thread.cc:86
> #9  0x2d6ac9d1 in start_thread () from /lib64/libpthread.so.0
> #10 0x2e8b58fd in clone () from /lib64/libc.so.6
> {code}
> I think some inlining here complicates things, what it looks like the "r" is 
> NULL, but it somehow still ends up using r->rr ?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4207) Crash in HostDB, likely a regression from 5.x

2016-04-07 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/TS-4207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15230828#comment-15230828
 ] 

ASF subversion and git services commented on TS-4207:
-

Commit 4561dc5a6098d45b8d536df8bfb282b120b17181 in trafficserver's branch 
refs/heads/master from [~jacksontj]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=4561dc5 ]

Workaround for TS-4207

Bump the default hostdb size in records config (and add better error logging on 
hostdb)

Since adding an additional 120 to each entry requires a larger cache, we'll 
bump the default size in the config. In addition I've added the required size 
to the error log instead of making the user guess

this closes #553


> Crash in HostDB, likely a regression from 5.x
> -
>
> Key: TS-4207
> URL: https://issues.apache.org/jira/browse/TS-4207
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HostDB
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
>Priority: Blocker
>  Labels: crash
> Fix For: 6.2.0
>
>
> We're seeing a new crash in HostDB, which did not occur in 5.3.x:
> {code}
> (gdb) bt
> #0  0x2ac7b2bb in HttpSM::process_hostdb_info(HostDBInfo*) () at 
> ../../iocore/hostdb/P_HostDBProcessor.h:295
> #1  0x2ac88b16 in HttpSM::state_hostdb_lookup(int, void*) () at 
> HttpSM.cc:2126
> #2  0x2ac9713d in HttpSM::main_handler(int, void*) () at 
> HttpSM.cc:2561
> #3  0x2ad7803e in reply_to_cont(Continuation*, HostDBInfo*, bool) () 
> at ../../iocore/eventsystem/I_Continuation.h:153
> #4  0x2ad7eca5 in HostDBContinuation::dnsEvent(int, HostEnt*) () at 
> HostDB.cc:1685
> #5  0x2ad98faf in DNSEntry::postEvent(int, Event*) () at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #6  0x2ae7e420 in EThread::process_event(Event*, int) () at 
> I_Continuation.h:153
> #7  0x2ae7f2ab in EThread::execute() () at UnixEThread.cc:179
> #8  0x2ae7de06 in spawn_thread_internal(void*) () at Thread.cc:86
> #9  0x2d6ac9d1 in start_thread () from /lib64/libpthread.so.0
> #10 0x2e8b58fd in clone () from /lib64/libc.so.6
> {code}
> I think some inlining here complicates things, what it looks like the "r" is 
> NULL, but it somehow still ends up using r->rr ?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (TS-4299) FetchSM / H2 streams can hang if e.g. a plugin adds a Connection: close header

2016-04-07 Thread Leif Hedstrom (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-4299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom resolved TS-4299.
---
Resolution: Fixed

> FetchSM / H2 streams can hang if e.g. a plugin adds a Connection: close header
> --
>
> Key: TS-4299
> URL: https://issues.apache.org/jira/browse/TS-4299
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, HTTP/2
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 6.2.0
>
>
> We use header_rewrite to inject Connection: close under certain conditions 
> (to prevent KA connections from lingering forever during e.g. server 
> maintenance). However, this interacts poorly with the FetchSM, and therefore, 
> poorly with H2. Basically, the connection "hangs" because the FetchSM thinks 
> there's more body data (when there really isn't).
> The issue comes from this code:
> {code}
> bool
> FetchSM::has_body()
> {
>   int status_code;
>   HTTPHdr *hdr;
>   if (!header_done)
> return false;
>   if (is_method_head)
> return false;
>   //
>   // The following code comply with HTTP/1.1:
>   // http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.4
>   //
>   hdr = _response_hdr;
>   status_code = hdr->status_get();
>   if (status_code < 200 || status_code == 204 || status_code == 304)
> return false;
>   if (check_chunked())
> return true;
>   if (check_connection_close())
> return true;
>   resp_content_length = hdr->value_get_int64(MIME_FIELD_CONTENT_LENGTH, 
> MIME_LEN_CONTENT_LENGTH);
>   if (!resp_content_length)
> return false;
>   return true;
> }
> {code}
> The issue is that it returns "true" if there is a Connection: close header. 
> I'm not 100% sure what the best solution here, simply removing this doesn't 
> seem right since it's obviously there to deal with some cases of FetchSM 
> which are not H2. A couple of unscientific options are
> 1) Make sure the H2 code assures that the Connection header is removed in all 
> cases. I know it deals with it in a few cases, except in this case we add the 
> Connection: close in the response header object, which therefore enters into 
> the FetchSM as well.
> 2) Have additional state / information in the FetchSM, indicating if 
> "connection" has semantics or not for this particular FetchSM. E.g. 
> fetch_sm->set_connection_aware(false);



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4329) Off-by-one error in NULL terminator for aname in hostdb

2016-04-07 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/TS-4329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15230853#comment-15230853
 ] 

ASF subversion and git services commented on TS-4329:
-

Commit 0926cf698fe804dd83bcf44fbe594a164d3aaf1f in trafficserver's branch 
refs/heads/master from [~jacksontj]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=0926cf6 ]

TS-4329 Off-by-one error in NULL terminator for aname in hostdb

This closes #555


> Off-by-one error in NULL terminator for aname in hostdb
> ---
>
> Key: TS-4329
> URL: https://issues.apache.org/jira/browse/TS-4329
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: 6.2.0
>
>
> This line 
> https://github.com/apache/trafficserver/blob/master/iocore/hostdb/HostDB.cc#L1373
> Is off by one, and ink_strlcpy takes care of it so we can just remove the 
> line.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4207) Crash in HostDB, likely a regression from 5.x

2016-04-07 Thread Thomas Jackson (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-4207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Jackson updated TS-4207:
---
Labels: back backport crash  (was: crash)

> Crash in HostDB, likely a regression from 5.x
> -
>
> Key: TS-4207
> URL: https://issues.apache.org/jira/browse/TS-4207
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HostDB
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
>Priority: Blocker
>  Labels: backport, crash
> Fix For: 6.2.0
>
>
> We're seeing a new crash in HostDB, which did not occur in 5.3.x:
> {code}
> (gdb) bt
> #0  0x2ac7b2bb in HttpSM::process_hostdb_info(HostDBInfo*) () at 
> ../../iocore/hostdb/P_HostDBProcessor.h:295
> #1  0x2ac88b16 in HttpSM::state_hostdb_lookup(int, void*) () at 
> HttpSM.cc:2126
> #2  0x2ac9713d in HttpSM::main_handler(int, void*) () at 
> HttpSM.cc:2561
> #3  0x2ad7803e in reply_to_cont(Continuation*, HostDBInfo*, bool) () 
> at ../../iocore/eventsystem/I_Continuation.h:153
> #4  0x2ad7eca5 in HostDBContinuation::dnsEvent(int, HostEnt*) () at 
> HostDB.cc:1685
> #5  0x2ad98faf in DNSEntry::postEvent(int, Event*) () at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #6  0x2ae7e420 in EThread::process_event(Event*, int) () at 
> I_Continuation.h:153
> #7  0x2ae7f2ab in EThread::execute() () at UnixEThread.cc:179
> #8  0x2ae7de06 in spawn_thread_internal(void*) () at Thread.cc:86
> #9  0x2d6ac9d1 in start_thread () from /lib64/libpthread.so.0
> #10 0x2e8b58fd in clone () from /lib64/libc.so.6
> {code}
> I think some inlining here complicates things, what it looks like the "r" is 
> NULL, but it somehow still ends up using r->rr ?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4329) Off-by-one error in NULL terminator for aname in hostdb

2016-04-07 Thread Thomas Jackson (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-4329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Jackson updated TS-4329:
---
Backport to Version: 6.1.2

> Off-by-one error in NULL terminator for aname in hostdb
> ---
>
> Key: TS-4329
> URL: https://issues.apache.org/jira/browse/TS-4329
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: 6.2.0
>
>
> This line 
> https://github.com/apache/trafficserver/blob/master/iocore/hostdb/HostDB.cc#L1373
> Is off by one, and ink_strlcpy takes care of it so we can just remove the 
> line.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4329) Off-by-one error in NULL terminator for aname in hostdb

2016-04-07 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/TS-4329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15230854#comment-15230854
 ] 

ASF GitHub Bot commented on TS-4329:


Github user asfgit closed the pull request at:

https://github.com/apache/trafficserver/pull/555


> Off-by-one error in NULL terminator for aname in hostdb
> ---
>
> Key: TS-4329
> URL: https://issues.apache.org/jira/browse/TS-4329
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: 6.2.0
>
>
> This line 
> https://github.com/apache/trafficserver/blob/master/iocore/hostdb/HostDB.cc#L1373
> Is off by one, and ink_strlcpy takes care of it so we can just remove the 
> line.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (TS-4207) Crash in HostDB, likely a regression from 5.x

2016-04-07 Thread Thomas Jackson (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-4207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Jackson resolved TS-4207.

Resolution: Fixed

> Crash in HostDB, likely a regression from 5.x
> -
>
> Key: TS-4207
> URL: https://issues.apache.org/jira/browse/TS-4207
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HostDB
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
>Priority: Blocker
>  Labels: crash
> Fix For: 6.2.0
>
>
> We're seeing a new crash in HostDB, which did not occur in 5.3.x:
> {code}
> (gdb) bt
> #0  0x2ac7b2bb in HttpSM::process_hostdb_info(HostDBInfo*) () at 
> ../../iocore/hostdb/P_HostDBProcessor.h:295
> #1  0x2ac88b16 in HttpSM::state_hostdb_lookup(int, void*) () at 
> HttpSM.cc:2126
> #2  0x2ac9713d in HttpSM::main_handler(int, void*) () at 
> HttpSM.cc:2561
> #3  0x2ad7803e in reply_to_cont(Continuation*, HostDBInfo*, bool) () 
> at ../../iocore/eventsystem/I_Continuation.h:153
> #4  0x2ad7eca5 in HostDBContinuation::dnsEvent(int, HostEnt*) () at 
> HostDB.cc:1685
> #5  0x2ad98faf in DNSEntry::postEvent(int, Event*) () at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #6  0x2ae7e420 in EThread::process_event(Event*, int) () at 
> I_Continuation.h:153
> #7  0x2ae7f2ab in EThread::execute() () at UnixEThread.cc:179
> #8  0x2ae7de06 in spawn_thread_internal(void*) () at Thread.cc:86
> #9  0x2d6ac9d1 in start_thread () from /lib64/libpthread.so.0
> #10 0x2e8b58fd in clone () from /lib64/libc.so.6
> {code}
> I think some inlining here complicates things, what it looks like the "r" is 
> NULL, but it somehow still ends up using r->rr ?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (TS-4329) Off-by-one error in NULL terminator for aname in hostdb

2016-04-07 Thread Thomas Jackson (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-4329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Jackson resolved TS-4329.

Resolution: Fixed

> Off-by-one error in NULL terminator for aname in hostdb
> ---
>
> Key: TS-4329
> URL: https://issues.apache.org/jira/browse/TS-4329
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: 6.2.0
>
>
> This line 
> https://github.com/apache/trafficserver/blob/master/iocore/hostdb/HostDB.cc#L1373
> Is off by one, and ink_strlcpy takes care of it so we can just remove the 
> line.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (TS-4330) Real or statistical differences in response time between 5.3 and 6.1

2016-04-07 Thread Susan Hinrichs (JIRA)

Susan Hinrichs created TS-4330:
--

 Summary: Real or statistical differences in response time between 
5.3 and 6.1
 Key: TS-4330
 URL: https://issues.apache.org/jira/browse/TS-4330
 Project: Traffic Server
  Issue Type: Bug
  Components: Performance
Reporter: Susan Hinrichs


We are evaluating 6.1 in our production caching environment and verifying it 
against a 5.3.x box in the same pod.

Our performance reporter (ysar) shows that the response time for 6.1 is higher 
than it is on the 5.3 box.  The difference is in the range of 10ms.

We also noticed that the error statistics difference.  In 6.1 the reported 
client aborts are higher.  Also the number of connection failures is low and 
the number of "other" errors is higher.  In 5.3, the number of connection 
failures is higher and the number of "other" errors is low.

Finally, I set the slow log on both machines.  On the 6.1 machine, I see every 
second or two an entry with ua_begin set to 0, all other fields set to -1 
except for sm_finish which is 120 seconds.  I do not see these slow logs on the 
5.3 machine.   It is as if the TCP deferred accept path is not being used on 
the 6.1 build.

We are continuing to investigate, but wanted to share in case others have seem 
similar issues.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4207) Crash in HostDB, likely a regression from 5.x

2016-04-07 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/TS-4207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15230563#comment-15230563
 ] 

ASF GitHub Bot commented on TS-4207:


Github user SolidWallOfCode commented on the pull request:

https://github.com/apache/trafficserver/pull/553#issuecomment-206993375
  
This seems reasonable. I'm not sure about the 120 for host name size but I 
am unable to offer a number with a better pedigree.


> Crash in HostDB, likely a regression from 5.x
> -
>
> Key: TS-4207
> URL: https://issues.apache.org/jira/browse/TS-4207
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HostDB
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
>Priority: Blocker
>  Labels: crash
> Fix For: 6.2.0
>
>
> We're seeing a new crash in HostDB, which did not occur in 5.3.x:
> {code}
> (gdb) bt
> #0  0x2ac7b2bb in HttpSM::process_hostdb_info(HostDBInfo*) () at 
> ../../iocore/hostdb/P_HostDBProcessor.h:295
> #1  0x2ac88b16 in HttpSM::state_hostdb_lookup(int, void*) () at 
> HttpSM.cc:2126
> #2  0x2ac9713d in HttpSM::main_handler(int, void*) () at 
> HttpSM.cc:2561
> #3  0x2ad7803e in reply_to_cont(Continuation*, HostDBInfo*, bool) () 
> at ../../iocore/eventsystem/I_Continuation.h:153
> #4  0x2ad7eca5 in HostDBContinuation::dnsEvent(int, HostEnt*) () at 
> HostDB.cc:1685
> #5  0x2ad98faf in DNSEntry::postEvent(int, Event*) () at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #6  0x2ae7e420 in EThread::process_event(Event*, int) () at 
> I_Continuation.h:153
> #7  0x2ae7f2ab in EThread::execute() () at UnixEThread.cc:179
> #8  0x2ae7de06 in spawn_thread_internal(void*) () at Thread.cc:86
> #9  0x2d6ac9d1 in start_thread () from /lib64/libpthread.so.0
> #10 0x2e8b58fd in clone () from /lib64/libc.so.6
> {code}
> I think some inlining here complicates things, what it looks like the "r" is 
> NULL, but it somehow still ends up using r->rr ?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4207) Crash in HostDB, likely a regression from 5.x

2016-04-07 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/TS-4207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15231026#comment-15231026
 ] 

ASF subversion and git services commented on TS-4207:
-

Commit ea1691ba527d6b7847589c2dc5a876c5aabfa42f in trafficserver's branch 
refs/heads/master from [~zwoop]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=ea1691b ]

TS-4207 Run clang format on the code...


> Crash in HostDB, likely a regression from 5.x
> -
>
> Key: TS-4207
> URL: https://issues.apache.org/jira/browse/TS-4207
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HostDB
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
>Priority: Blocker
>  Labels: crash
> Fix For: 6.2.0
>
>
> We're seeing a new crash in HostDB, which did not occur in 5.3.x:
> {code}
> (gdb) bt
> #0  0x2ac7b2bb in HttpSM::process_hostdb_info(HostDBInfo*) () at 
> ../../iocore/hostdb/P_HostDBProcessor.h:295
> #1  0x2ac88b16 in HttpSM::state_hostdb_lookup(int, void*) () at 
> HttpSM.cc:2126
> #2  0x2ac9713d in HttpSM::main_handler(int, void*) () at 
> HttpSM.cc:2561
> #3  0x2ad7803e in reply_to_cont(Continuation*, HostDBInfo*, bool) () 
> at ../../iocore/eventsystem/I_Continuation.h:153
> #4  0x2ad7eca5 in HostDBContinuation::dnsEvent(int, HostEnt*) () at 
> HostDB.cc:1685
> #5  0x2ad98faf in DNSEntry::postEvent(int, Event*) () at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #6  0x2ae7e420 in EThread::process_event(Event*, int) () at 
> I_Continuation.h:153
> #7  0x2ae7f2ab in EThread::execute() () at UnixEThread.cc:179
> #8  0x2ae7de06 in spawn_thread_internal(void*) () at Thread.cc:86
> #9  0x2d6ac9d1 in start_thread () from /lib64/libpthread.so.0
> #10 0x2e8b58fd in clone () from /lib64/libc.so.6
> {code}
> I think some inlining here complicates things, what it looks like the "r" is 
> NULL, but it somehow still ends up using r->rr ?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (TS-4332) proxy.config.net.connections_throttle should allow for immediate error return when accepts reach throttle limit

2016-04-07 Thread Susan Hinrichs (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-4332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Susan Hinrichs reassigned TS-4332:
--

Assignee: Susan Hinrichs

> proxy.config.net.connections_throttle should allow for immediate error return 
> when accepts reach throttle limit
> ---
>
> Key: TS-4332
> URL: https://issues.apache.org/jira/browse/TS-4332
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Network
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
>
> When the throttling kicks in future connections to origins will cause a 502 
> to be returned to the user agent.
> But when an accept happens during the throttling period, a message is only 
> sent if the unix_netProcessor.throttle_error_message member variable is set.  
> In the current code, this member variable is never set.  If the variable is 
> not set, the logic blocks for 100ms and tries again.
> This spinning causes the ATS process to waste resources.  It would be better 
> to immediately turn around and send an error response (probably 503 instead 
> of 502).
> I tested a build that hard coded an error message and it seemed to recover 
> much better.
> I propose adding some config variables to control the throttling behavior.
> proxy.config.connections_throttle.error_code  - HTTP response code to return 
> (or just hard code this to 503)
> proxy.config.connections_throttle.error_page - Reference to an error page to 
> return.
> If both are unset, the existing delaying logic is used.  If either is set, 
> either a error header or a header and body are returned immediately.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4207) Crash in HostDB, likely a regression from 5.x

2016-04-07 Thread Leif Hedstrom (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-4207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-4207:
--
Backport to Version: 6.1.2

> Crash in HostDB, likely a regression from 5.x
> -
>
> Key: TS-4207
> URL: https://issues.apache.org/jira/browse/TS-4207
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HostDB
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
>Priority: Blocker
>  Labels: crash
> Fix For: 6.2.0
>
>
> We're seeing a new crash in HostDB, which did not occur in 5.3.x:
> {code}
> (gdb) bt
> #0  0x2ac7b2bb in HttpSM::process_hostdb_info(HostDBInfo*) () at 
> ../../iocore/hostdb/P_HostDBProcessor.h:295
> #1  0x2ac88b16 in HttpSM::state_hostdb_lookup(int, void*) () at 
> HttpSM.cc:2126
> #2  0x2ac9713d in HttpSM::main_handler(int, void*) () at 
> HttpSM.cc:2561
> #3  0x2ad7803e in reply_to_cont(Continuation*, HostDBInfo*, bool) () 
> at ../../iocore/eventsystem/I_Continuation.h:153
> #4  0x2ad7eca5 in HostDBContinuation::dnsEvent(int, HostEnt*) () at 
> HostDB.cc:1685
> #5  0x2ad98faf in DNSEntry::postEvent(int, Event*) () at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #6  0x2ae7e420 in EThread::process_event(Event*, int) () at 
> I_Continuation.h:153
> #7  0x2ae7f2ab in EThread::execute() () at UnixEThread.cc:179
> #8  0x2ae7de06 in spawn_thread_internal(void*) () at Thread.cc:86
> #9  0x2d6ac9d1 in start_thread () from /lib64/libpthread.so.0
> #10 0x2e8b58fd in clone () from /lib64/libc.so.6
> {code}
> I think some inlining here complicates things, what it looks like the "r" is 
> NULL, but it somehow still ends up using r->rr ?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (TS-4333) The CacheKey plugin cannot conditionally modify the cache key based on headers in the request.

2016-04-07 Thread Nolan Astrein (JIRA)

Nolan Astrein created TS-4333:
-

 Summary: The CacheKey plugin cannot conditionally modify the cache 
key based on headers in the request.
 Key: TS-4333
 URL: https://issues.apache.org/jira/browse/TS-4333
 Project: Traffic Server
  Issue Type: Improvement
  Components: Plugins
Reporter: Nolan Astrein


A TrafficServer administrator should be able to supply a list of mandatory 
headers as a parameter to the CacheKey plugin.  The CacheKey plugin should only 
modify the cache key when the all of the mandatory headers are present in the 
request.  If any of the mandatory headers are not present in the request the 
cache key should not be modified by the CacheKey plugin.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (TS-4334) The cache_range_requests plugin always attempts to modify the cache key.

2016-04-07 Thread Nolan Astrein (JIRA)

Nolan Astrein created TS-4334:
-

 Summary: The cache_range_requests plugin always attempts to modify 
the cache key.
 Key: TS-4334
 URL: https://issues.apache.org/jira/browse/TS-4334
 Project: Traffic Server
  Issue Type: Improvement
  Components: Plugins
Reporter: Nolan Astrein


A TrafficServer administrator should be able to specify whether or not the 
cache_range_requests plugin should modify the cache key.  The cache key may be 
modified by a previous plugin in a plugin chain and there is no way to 
configure cache_range_requests not to do any further modifications to the cache 
key.  Having multiple plugins responsible for cache key modifications can cause 
unexpected behavior, especially when a plugin chain ordering is changed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4334) The cache_range_requests plugin always attempts to modify the cache key.

2016-04-07 Thread Gancho Tenev (JIRA)


[ 
https://issues.apache.org/jira/browse/TS-4334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15231444#comment-15231444
 ] 

Gancho Tenev commented on TS-4334:
--

Sure, please assign it to me.

> The cache_range_requests plugin always attempts to modify the cache key.
> 
>
> Key: TS-4334
> URL: https://issues.apache.org/jira/browse/TS-4334
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: Nolan Astrein
> Fix For: 7.0.0
>
>
> A TrafficServer administrator should be able to specify whether or not the 
> cache_range_requests plugin should modify the cache key.  The cache key may 
> be modified by a previous plugin in a plugin chain and there is no way to 
> configure cache_range_requests not to do any further modifications to the 
> cache key.  Having multiple plugins responsible for cache key modifications 
> can cause unexpected behavior, especially when a plugin chain ordering is 
> changed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Reopened] (TS-4313) MIMEHdr fails to find header fields

2016-04-07 Thread Masakazu Kitajo (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-4313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Masakazu Kitajo reopened TS-4313:
-

I reverted the commits, since there was a build issue.

> MIMEHdr fails to find header fields
> ---
>
> Key: TS-4313
> URL: https://issues.apache.org/jira/browse/TS-4313
> Project: Traffic Server
>  Issue Type: Bug
>  Components: MIME
>Reporter: Masakazu Kitajo
>Assignee: Masakazu Kitajo
> Fix For: 6.2.0
>
>
> MIMEHdr fails to find a MIMEField occasionally due to improper type 
> conversion.
> It happens if the lower 32 bits of addresses of m_field_slots are the same. 
> The logic below picks up wrong block.
> mime_hdr_field_slotnum(): 
> {code}
> for (fblock = &(mh->m_first_fblock); fblock != NULL; fblock = fblock->m_next) 
> {
> MIMEField *first = &(fblock->m_field_slots[0]);
> int block_slot = (int)(field - first); // in units of MIMEField
> if ((block_slot >= 0) && (block_slot < MIME_FIELD_BLOCK_SLOTS))
> {code}
> The type of block_slot should be intptr_t.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4334) The cache_range_requests plugin always attempts to modify the cache key.

2016-04-07 Thread Leif Hedstrom (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-4334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-4334:
--
Assignee: Gancho Tenev

> The cache_range_requests plugin always attempts to modify the cache key.
> 
>
> Key: TS-4334
> URL: https://issues.apache.org/jira/browse/TS-4334
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: Nolan Astrein
>Assignee: Gancho Tenev
> Fix For: 7.0.0
>
>
> A TrafficServer administrator should be able to specify whether or not the 
> cache_range_requests plugin should modify the cache key.  The cache key may 
> be modified by a previous plugin in a plugin chain and there is no way to 
> configure cache_range_requests not to do any further modifications to the 
> cache key.  Having multiple plugins responsible for cache key modifications 
> can cause unexpected behavior, especially when a plugin chain ordering is 
> changed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4313) MIMEHdr fails to find header fields

2016-04-07 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/TS-4313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15229992#comment-15229992
 ] 

ASF subversion and git services commented on TS-4313:
-

Commit d1557bf5222bb6abf6966dacdee889edd15b4fc2 in trafficserver's branch 
refs/heads/master from [~maskit]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=d1557bf ]

Revert "TS-4313: Fix a bug in MIME caused by improper type conversion"

This reverts commit caafcbbe0cad5525b337f99514a4bc0e8c71a7ae.


> MIMEHdr fails to find header fields
> ---
>
> Key: TS-4313
> URL: https://issues.apache.org/jira/browse/TS-4313
> Project: Traffic Server
>  Issue Type: Bug
>  Components: MIME
>Reporter: Masakazu Kitajo
>Assignee: Masakazu Kitajo
> Fix For: 6.2.0
>
>
> MIMEHdr fails to find a MIMEField occasionally due to improper type 
> conversion.
> It happens if the lower 32 bits of addresses of m_field_slots are the same. 
> The logic below picks up wrong block.
> mime_hdr_field_slotnum(): 
> {code}
> for (fblock = &(mh->m_first_fblock); fblock != NULL; fblock = fblock->m_next) 
> {
> MIMEField *first = &(fblock->m_field_slots[0]);
> int block_slot = (int)(field - first); // in units of MIMEField
> if ((block_slot >= 0) && (block_slot < MIME_FIELD_BLOCK_SLOTS))
> {code}
> The type of block_slot should be intptr_t.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4328) Connect_retries re-connects even if request made it to origin (TS-3440 repeat)

2016-04-07 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/TS-4328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15231669#comment-15231669
 ] 

ASF GitHub Bot commented on TS-4328:


Github user jpeach commented on the pull request:

https://github.com/apache/trafficserver/pull/554#issuecomment-207223148
  
I looked at this for a while and I'm not convinced that it doesn't have 
unindented side-effects. ``is_request_retryable`` is only set once POST data is 
getting sent. Checking the milestone makes more request types non-retryable.

The use of milestones is fairly unfortunate as well; I'd really like to 
avoid that.


> Connect_retries re-connects even if request made it to origin (TS-3440 repeat)
> --
>
> Key: TS-4328
> URL: https://issues.apache.org/jira/browse/TS-4328
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
>
> I'm creating another issue as the root bug for TS-3440 can still be 
> reproduced if the origin is extremely slow (but no returns no error response).
> I've opened a PR (https://github.com/apache/trafficserver/pull/554) which 
> reverts the original patch and instead checks if any bytes where sent.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4329) Off-by-one error in NULL terminator for aname in hostdb

[jira] [Updated] (TS-4333) The CacheKey plugin cannot conditionally modify the cache key based on headers in the request.

[jira] [Commented] (TS-4334) The cache_range_requests plugin always attempts to modify the cache key.

[jira] [Updated] (TS-4334) The cache_range_requests plugin always attempts to modify the cache key.

[jira] [Updated] (TS-4333) The CacheKey plugin cannot conditionally modify the cache key based on headers in the request.

[jira] [Commented] (TS-4333) The CacheKey plugin cannot conditionally modify the cache key based on headers in the request.

[jira] [Updated] (TS-4207) Crash in HostDB, likely a regression from 5.x

[jira] [Created] (TS-4332) proxy.config.net.connections_throttle should allow for immediate error return when accepts reach throttle limit

[jira] [Created] (TS-4331) Hostdb consistency problems due to MultiCache

[jira] [Assigned] (TS-4331) Hostdb consistency problems due to MultiCache

Build failed in Jenkins: clang-format #680

[jira] [Commented] (TS-4090) CID 1343359, 1343358: Coverity issues in new memcached plugin

[jira] [Updated] (TS-4207) Crash in HostDB, likely a regression from 5.x

[jira] [Commented] (TS-4299) FetchSM / H2 streams can hang if e.g. a plugin adds a Connection: close header

[jira] [Commented] (TS-4299) FetchSM / H2 streams can hang if e.g. a plugin adds a Connection: close header

[jira] [Commented] (TS-4207) Crash in HostDB, likely a regression from 5.x

[jira] [Commented] (TS-4207) Crash in HostDB, likely a regression from 5.x

[jira] [Resolved] (TS-4299) FetchSM / H2 streams can hang if e.g. a plugin adds a Connection: close header

[jira] [Commented] (TS-4329) Off-by-one error in NULL terminator for aname in hostdb

[jira] [Updated] (TS-4207) Crash in HostDB, likely a regression from 5.x

[jira] [Updated] (TS-4329) Off-by-one error in NULL terminator for aname in hostdb

[jira] [Commented] (TS-4329) Off-by-one error in NULL terminator for aname in hostdb

[jira] [Resolved] (TS-4207) Crash in HostDB, likely a regression from 5.x

[jira] [Resolved] (TS-4329) Off-by-one error in NULL terminator for aname in hostdb

[jira] [Created] (TS-4330) Real or statistical differences in response time between 5.3 and 6.1

[jira] [Commented] (TS-4207) Crash in HostDB, likely a regression from 5.x

[jira] [Commented] (TS-4207) Crash in HostDB, likely a regression from 5.x

[jira] [Assigned] (TS-4332) proxy.config.net.connections_throttle should allow for immediate error return when accepts reach throttle limit

[jira] [Updated] (TS-4207) Crash in HostDB, likely a regression from 5.x

[jira] [Created] (TS-4333) The CacheKey plugin cannot conditionally modify the cache key based on headers in the request.

[jira] [Created] (TS-4334) The cache_range_requests plugin always attempts to modify the cache key.

[jira] [Commented] (TS-4334) The cache_range_requests plugin always attempts to modify the cache key.

[jira] [Reopened] (TS-4313) MIMEHdr fails to find header fields

[jira] [Updated] (TS-4334) The cache_range_requests plugin always attempts to modify the cache key.

[jira] [Commented] (TS-4313) MIMEHdr fails to find header fields

[jira] [Commented] (TS-4328) Connect_retries re-connects even if request made it to origin (TS-3440 repeat)

36 matches

Site Navigation

Mail list logo

Footer information