[jira] [Work logged] (TS-4509) Dropped keep-alive connections not being re-established (TS-3959 continued)

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4509?focusedWorklogId=30288=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30288
 ]

ASF GitHub Bot logged work on TS-4509:
--

Author: ASF GitHub Bot
Created on: 08/Oct/16 04:32
Start Date: 08/Oct/16 04:32
Worklog Time Spent: 10m 
  Work Description: Github user jpeach commented on the issue:

https://github.com/apache/trafficserver/pull/1070
  
+1, assuming you are going to squash :)


Issue Time Tracking
---

Worklog Id: (was: 30288)
Time Spent: 4h 10m  (was: 4h)

> Dropped keep-alive connections not being re-established (TS-3959 continued)
> ---
>
> Key: TS-4509
> URL: https://issues.apache.org/jira/browse/TS-4509
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, Network
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
>Priority: Blocker
> Fix For: 7.1.0
>
>  Time Spent: 4h 10m
>  Remaining Estimate: 0h
>
> I've observed some differences in how TrafficServer 6.0.0 behaves with 
> connection retrying and outgoing keep-alive connections. I believe the 
> changes in behavior might be related to this issue: 
> https://issues.apache.org/jira/browse/TS-3440
> I originally wasn't sure if this was a bug, but James Peach indicated it 
> sounded more like a regression on the mailing list 
> (http://mail-archives.apache.org/mod_mbox/trafficserver-users/201510.mbox/%3cba85d5a2-8b29-44a9-acdc-e7fa8d21f...@apache.org%3e).
> What I'm seeing in 6.0.0 is that if TrafficServer has some backend keep-alive 
> connections already opened, but then one of the keep-alive connections is 
> closed, the next request to TrafficServer may generate a 502 Server Hangup 
> response when attempting to reuse that connection. Previously, I think 
> TrafficServer was retrying when it encountered a closed keep-alive 
> connection, but that is no longer the case. So if you have a backend that 
> might unexpectedly close its open keep-alive connections, the only way I've 
> found to completely prevent these 502 errors in 6.0.0 is to disable outgoing 
> keepalive (proxy.config.http.keep_alive_enabled_out and 
> proxy.config.http.keep_alive_post_out settings).
> For a slightly more concrete example of what can trigger this, this is fairly 
> easy to reproduce with the following setup:
> - TrafficServer is proxying to nginx with outgoing keep-alive connections 
> enabled (the default).
> - Throw a constant stream of requests at TrafficServer.
> - While that constant stream of requests is happening, also send a regular 
> stream of SIGHUP commands to nginx to reload nginx.
> - Eventually you'll get some 502 Server Hangup responses from TrafficServer 
> among your stream of requests.
> SIGHUPs in nginx should result in zero downtime for new requests, but I think 
> what's happening is that TrafficServer may fail when an old keep-alived 
> connection is reused (it's not common, so it depends on the timing of things 
> and if the connection is from an old nginx worker that has since been shut 
> down). In TrafficServer 5.3.1 these connection failures were retried, but in 
> 6.0.0, no retries occur in this case.
> Here's some debug logs that show the difference in behavior between 6.0.0 and 
> 5.3.1. Note that differences seem to stem from how each version eventually 
> handles the "VC_EVENT_EOS" event following 
> "::state_send_server_request_header, VC_EVENT_WRITE_COMPLETE".
> 5.3.1: 
> https://gist.github.com/GUI/0c53a6c4fdc2782b14aa#file-trafficserver_5-3-1-log-L316
> 6.0.0: 
> https://gist.github.com/GUI/0c53a6c4fdc2782b14aa#file-trafficserver_6-0-0-log-L314
> Interestingly, if I'm understand the log files correctly, it looks like 
> TraffficServer is reporting an odd empty response from these connections 
> ("HTTP/0.9 0" in 5.3.1 and "HTTP/1.0 0" in 6.0.0). However, as far as I can 
> tell from TCP dumps on the system, nginx is not actually sending any form of 
> response.
> In these example cases the backend server isn't sending back any data (at 
> least as far as I can tell), so from what I understand (and the logic 
> outlined in https://issues.apache.org/jira/browse/TS-3440), it should be safe 
> to retry.
> Let me know if I can provide any other details. Or if exact scripts to 
> reproduce the issues against the example nginx backend I described above 
> would be useful, I could get that together.



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

[GitHub] trafficserver issue #1070: TS-4509: Add `outstanding_bytes` to VConnection

[jpeach]

Github user jpeach commented on the issue:

https://github.com/apache/trafficserver/pull/1070
  
+1, assuming you are going to squash :)


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Build failed in Jenkins: clang-format #1154

[jenkins]

See 

Changes:

[James Peach] Make clang-format executable after downloading it.

[James Peach] Minor formatting cleanups.

--
[...truncated 1610 lines...]
./proxy/logging/LogObject.h
./proxy/logging/LogHost.cc
./proxy/logging/LogFieldAliasMap.h
./proxy/logging/LogFormat.h
./proxy/logging/LogFormat.cc
./proxy/logging/LogFile.cc
./proxy/logging/LogBindings.h
./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/LogBindings.cc
./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/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/ProxyClientTransaction.h
./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/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/UglyLogStubs.cc
./proxy/shared/DiagsConfig.h
./proxy/shared/DiagsConfig.cc
./proxy/UnixCompletionUtil.h
./proxy/ICPConfig.cc
./proxy/IPAllow.h
./proxy/TestProxy.cc
./proxy/ParentSelection.cc
./proxy/PluginVC.cc
./proxy/EventName.h
./proxy/TestSimpleProxy.cc
./proxy/Prefetch.h
./proxy/http/TestUrl.cc
./proxy/http/HttpBodyFactory.h
./proxy/http/Http1ClientSession.h
./proxy/http/Http1ClientTransaction.cc
./proxy/http/Http1ClientTransaction.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/HttpTransact.h
./proxy/http/Http1ClientSession.cc
./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/ICP.h
./proxy/ProxyClientSession.h
./proxy/ParentConsistentHash.h
./proxy/CacheControl.h
./proxy/InkAPITestTool.cc
./proxy/ControlBase.cc
./proxy/http2/Http2DebugNames.cc
./proxy/http2/Http2ClientSession.cc
./proxy/http2/RegressionHPACK.cc

[GitHub] trafficserver issue #712: TS-4523 - Add pause functionality to the Transform...

[ushachar]

Github user ushachar commented on the issue:

https://github.com/apache/trafficserver/pull/712
  
@jpeach / @SolidWallOfCode  - Since there were a couple of concerns about 
this API in the beginning could one of you ack this as well?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4523) Add the ability to pause/resume data consumption in the CPP API

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4523?focusedWorklogId=30285=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30285
 ]

ASF GitHub Bot logged work on TS-4523:
--

Author: ASF GitHub Bot
Created on: 07/Oct/16 23:44
Start Date: 07/Oct/16 23:44
Worklog Time Spent: 10m 
  Work Description: Github user ushachar commented on the issue:

https://github.com/apache/trafficserver/pull/712
  
@jpeach / @SolidWallOfCode  - Since there were a couple of concerns about 
this API in the beginning could one of you ack this as well?


Issue Time Tracking
---

Worklog Id: (was: 30285)
Time Spent: 1h 20m  (was: 1h 10m)

> Add the ability to pause/resume data consumption in the CPP API
> ---
>
> Key: TS-4523
> URL: https://issues.apache.org/jira/browse/TS-4523
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: David Ben Zakai
>Assignee: Uri Shachar
> Fix For: 7.1.0
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> I'd like to suggest an API change in the CPP API Transformation interface.
> My own use case is that I'd like to be able to pause the transformation, 
> handle what I can from the file and release the buffered content before 
> resuming and releasing the rest of the data.
> Basically what I'm trying to achieve:
> Write data to file (up to a certain amount)
> File analysis
> Produce file data (and any leftovers) downstream
> When the file size reaches a certain size limit I'd like to be able to pause 
> the transformation and produce all of its content downstream and then resume 
> the transformation.
> API Changes:
> TransformationPlugin.h:
> /**
> * Call this method if you wish to pause the transformation.
> * Schedule the return value continuation to resume the transforamtion.
> * If the continuation is scheduled and called after the transform is 
> destroyed it will 
> * won't do anything beyond cleanups.
> * Note: You must schedule the continuation or destroy it (using 
> TSContDestroy) yourself, 
> * otherwise it will leak.
> */
> TSCont pause();
> Internally, the continuation wraps the "resumeCallback" static function:
> static int resumeCallback(TSCont cont, TSEvent event, void *edata); /** 
> Resume callback*/
> Thank you!



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

[jira] [Work logged] (TS-4523) Add the ability to pause/resume data consumption in the CPP API

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4523?focusedWorklogId=30281=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30281
 ]

ASF GitHub Bot logged work on TS-4523:
--

Author: ASF GitHub Bot
Created on: 07/Oct/16 23:09
Start Date: 07/Oct/16 23:09
Worklog Time Spent: 10m 
  Work Description: Github user davidbz commented on the issue:

https://github.com/apache/trafficserver/pull/712
  
@ushachar Done. Thanks


Issue Time Tracking
---

Worklog Id: (was: 30281)
Time Spent: 1h 10m  (was: 1h)

> Add the ability to pause/resume data consumption in the CPP API
> ---
>
> Key: TS-4523
> URL: https://issues.apache.org/jira/browse/TS-4523
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: David Ben Zakai
>Assignee: Uri Shachar
> Fix For: 7.1.0
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> I'd like to suggest an API change in the CPP API Transformation interface.
> My own use case is that I'd like to be able to pause the transformation, 
> handle what I can from the file and release the buffered content before 
> resuming and releasing the rest of the data.
> Basically what I'm trying to achieve:
> Write data to file (up to a certain amount)
> File analysis
> Produce file data (and any leftovers) downstream
> When the file size reaches a certain size limit I'd like to be able to pause 
> the transformation and produce all of its content downstream and then resume 
> the transformation.
> API Changes:
> TransformationPlugin.h:
> /**
> * Call this method if you wish to pause the transformation.
> * Schedule the return value continuation to resume the transforamtion.
> * If the continuation is scheduled and called after the transform is 
> destroyed it will 
> * won't do anything beyond cleanups.
> * Note: You must schedule the continuation or destroy it (using 
> TSContDestroy) yourself, 
> * otherwise it will leak.
> */
> TSCont pause();
> Internally, the continuation wraps the "resumeCallback" static function:
> static int resumeCallback(TSCont cont, TSEvent event, void *edata); /** 
> Resume callback*/
> Thank you!



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

[GitHub] trafficserver issue #712: TS-4523 - Add pause functionality to the Transform...

[davidbz]

Github user davidbz commented on the issue:

https://github.com/apache/trafficserver/pull/712
  
@ushachar Done. Thanks


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (TS-4942) simple retry is not working correctly.

[James Peach (JIRA)]

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

James Peach commented on TS-4942:
-

[~jrushford] please file another jira for parent proxy integration tests.

> simple retry is not working correctly.
> --
>
> Key: TS-4942
> URL: https://issues.apache.org/jira/browse/TS-4942
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Parent Proxy
>Reporter: John Rushford
>Assignee: John Rushford
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> While regression testing, I found that when enabling simple retry in 
> parent.config that a transaction would not retry the request when a 404 was 
> received from the parent.



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

[jira] [Created] (TS-4943) Remove ink_defs.h from the plugins

[Bryan Call (JIRA)]

Bryan Call created TS-4943:
--

 Summary: Remove ink_defs.h from the plugins
 Key: TS-4943
 URL: https://issues.apache.org/jira/browse/TS-4943
 Project: Traffic Server
  Issue Type: Improvement
  Components: Plugins
Reporter: Bryan Call


ink_defs.h doesn't get installed and is part of the internal APIs.  It should 
be removed from plugins, since plugins should only be using the external APIs.



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

[jira] [Work logged] (TS-4942) simple retry is not working correctly.

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4942?focusedWorklogId=30277=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30277
 ]

ASF GitHub Bot logged work on TS-4942:
--

Author: ASF GitHub Bot
Created on: 07/Oct/16 21:24
Start Date: 07/Oct/16 21:24
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1085
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/950/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 30277)
Time Spent: 1h  (was: 50m)

> simple retry is not working correctly.
> --
>
> Key: TS-4942
> URL: https://issues.apache.org/jira/browse/TS-4942
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Parent Proxy
>Reporter: John Rushford
>Assignee: John Rushford
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> While regression testing, I found that when enabling simple retry in 
> parent.config that a transaction would not retry the request when a 404 was 
> received from the parent.



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

[GitHub] trafficserver issue #1085: TS-4942: simple retry is not working correctly.

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1085
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/842/ for details.
 



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4942) simple retry is not working correctly.

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4942?focusedWorklogId=30278=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30278
 ]

ASF GitHub Bot logged work on TS-4942:
--

Author: ASF GitHub Bot
Created on: 07/Oct/16 21:25
Start Date: 07/Oct/16 21:25
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1085
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/842/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 30278)
Time Spent: 1h 10m  (was: 1h)

> simple retry is not working correctly.
> --
>
> Key: TS-4942
> URL: https://issues.apache.org/jira/browse/TS-4942
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Parent Proxy
>Reporter: John Rushford
>Assignee: John Rushford
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> While regression testing, I found that when enabling simple retry in 
> parent.config that a transaction would not retry the request when a 404 was 
> received from the parent.



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

[GitHub] trafficserver issue #1085: TS-4942: simple retry is not working correctly.

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1085
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/950/ for details.
 



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4942) simple retry is not working correctly.

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4942?focusedWorklogId=30276=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30276
 ]

ASF GitHub Bot logged work on TS-4942:
--

Author: ASF GitHub Bot
Created on: 07/Oct/16 21:19
Start Date: 07/Oct/16 21:19
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1085
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/841/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 30276)
Time Spent: 50m  (was: 40m)

> simple retry is not working correctly.
> --
>
> Key: TS-4942
> URL: https://issues.apache.org/jira/browse/TS-4942
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Parent Proxy
>Reporter: John Rushford
>Assignee: John Rushford
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> While regression testing, I found that when enabling simple retry in 
> parent.config that a transaction would not retry the request when a 404 was 
> received from the parent.



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

[GitHub] trafficserver issue #1085: TS-4942: simple retry is not working correctly.

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1085
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/841/ for details.
 



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] trafficserver issue #1085: TS-4942: simple retry is not working correctly.

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1085
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/949/ for details.
 



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4942) simple retry is not working correctly.

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4942?focusedWorklogId=30275=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30275
 ]

ASF GitHub Bot logged work on TS-4942:
--

Author: ASF GitHub Bot
Created on: 07/Oct/16 21:15
Start Date: 07/Oct/16 21:15
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1085
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/949/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 30275)
Time Spent: 40m  (was: 0.5h)

> simple retry is not working correctly.
> --
>
> Key: TS-4942
> URL: https://issues.apache.org/jira/browse/TS-4942
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Parent Proxy
>Reporter: John Rushford
>Assignee: John Rushford
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> While regression testing, I found that when enabling simple retry in 
> parent.config that a transaction would not retry the request when a 404 was 
> received from the parent.



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

[jira] [Work logged] (TS-4942) simple retry is not working correctly.

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4942?focusedWorklogId=30274=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30274
 ]

ASF GitHub Bot logged work on TS-4942:
--

Author: ASF GitHub Bot
Created on: 07/Oct/16 20:49
Start Date: 07/Oct/16 20:49
Worklog Time Spent: 10m 
  Work Description: Github user jpeach commented on the issue:

https://github.com/apache/trafficserver/pull/1085
  
Can you fix the jira number in the commit?


Issue Time Tracking
---

Worklog Id: (was: 30274)
Time Spent: 0.5h  (was: 20m)

> simple retry is not working correctly.
> --
>
> Key: TS-4942
> URL: https://issues.apache.org/jira/browse/TS-4942
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Parent Proxy
>Reporter: John Rushford
>Assignee: John Rushford
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> While regression testing, I found that when enabling simple retry in 
> parent.config that a transaction would not retry the request when a 404 was 
> received from the parent.



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

[GitHub] trafficserver issue #1085: TS-4942: simple retry is not working correctly.

[jpeach]

Github user jpeach commented on the issue:

https://github.com/apache/trafficserver/pull/1085
  
Can you fix the jira number in the commit?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4942) simple retry is not working correctly.

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4942?focusedWorklogId=30273=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30273
 ]

ASF GitHub Bot logged work on TS-4942:
--

Author: ASF GitHub Bot
Created on: 07/Oct/16 20:39
Start Date: 07/Oct/16 20:39
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1085
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/840/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 30273)
Time Spent: 20m  (was: 10m)

> simple retry is not working correctly.
> --
>
> Key: TS-4942
> URL: https://issues.apache.org/jira/browse/TS-4942
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Parent Proxy
>Reporter: John Rushford
>Assignee: John Rushford
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> While regression testing, I found that when enabling simple retry in 
> parent.config that a transaction would not retry the request when a 404 was 
> received from the parent.



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

[GitHub] trafficserver issue #1085: TS-4942: simple retry is not working correctly.

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1085
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/840/ for details.
 



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4942) simple retry is not working correctly.

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4942?focusedWorklogId=30272=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30272
 ]

ASF GitHub Bot logged work on TS-4942:
--

Author: ASF GitHub Bot
Created on: 07/Oct/16 20:36
Start Date: 07/Oct/16 20:36
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1085
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/948/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 30272)
Time Spent: 10m
Remaining Estimate: 0h

> simple retry is not working correctly.
> --
>
> Key: TS-4942
> URL: https://issues.apache.org/jira/browse/TS-4942
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Parent Proxy
>Reporter: John Rushford
>Assignee: John Rushford
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> While regression testing, I found that when enabling simple retry in 
> parent.config that a transaction would not retry the request when a 404 was 
> received from the parent.



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

[GitHub] trafficserver issue #1085: TS-4942: simple retry is not working correctly.

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1085
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/948/ for details.
 



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] trafficserver pull request #1085: TS-44942: simple retry is not working corr...

[jrushford]

GitHub user jrushford opened a pull request:

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

TS-44942: simple retry is not working correctly.

Fix for simple retry.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/jrushford/trafficserver TS-4942

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/trafficserver/pull/1085.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1085


commit 2dadaf59c6d72e41f99b2b6b0d3d269d2cd754ec
Author: John J. Rushford 
Date:   2016-10-07T17:29:20Z

TS-44942: simple retry is not working correctly.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Assigned] (TS-4942) simple retry is not working correctly.

[John Rushford (JIRA)]

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

John Rushford reassigned TS-4942:
-

Assignee: John Rushford

> simple retry is not working correctly.
> --
>
> Key: TS-4942
> URL: https://issues.apache.org/jira/browse/TS-4942
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Parent Proxy
>Reporter: John Rushford
>Assignee: John Rushford
>
> While regression testing, I found that when enabling simple retry in 
> parent.config that a transaction would not retry the request when a 404 was 
> received from the parent.



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

[jira] [Work started] (TS-4942) simple retry is not working correctly.

[John Rushford (JIRA)]

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

Work on TS-4942 started by John Rushford.
-
> simple retry is not working correctly.
> --
>
> Key: TS-4942
> URL: https://issues.apache.org/jira/browse/TS-4942
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Parent Proxy
>Reporter: John Rushford
>Assignee: John Rushford
>
> While regression testing, I found that when enabling simple retry in 
> parent.config that a transaction would not retry the request when a 404 was 
> received from the parent.



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

[jira] [Created] (TS-4942) simple retry is not working correctly.

[John Rushford (JIRA)]

John Rushford created TS-4942:
-

 Summary: simple retry is not working correctly.
 Key: TS-4942
 URL: https://issues.apache.org/jira/browse/TS-4942
 Project: Traffic Server
  Issue Type: Bug
  Components: Parent Proxy
Reporter: John Rushford


While regression testing, I found that when enabling simple retry in 
parent.config that a transaction would not retry the request when a 404 was 
received from the parent.



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

[jira] [Updated] (TS-3863) Add support for ASAN leak detection

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-3863:
--
Backport to Version:   (was: 6.1.2)

> Add support for ASAN leak detection
> ---
>
> Key: TS-3863
> URL: https://issues.apache.org/jira/browse/TS-3863
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: Bryan Call
>Assignee: Bryan Call
>  Labels: yahoo
> Fix For: 6.2.0
>
>
> We will need to call exit() instead of _exit() and fix all the coredumps that 
> happen when objects are being cleaned up.



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

[jira] [Updated] (TS-4461) Not closing client connections

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4461:
--
Backport to Version:   (was: 6.1.2)

> Not closing client connections
> --
>
> Key: TS-4461
> URL: https://issues.apache.org/jira/browse/TS-4461
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 6.2.0
>Reporter: Bryan Call
>Assignee: Susan Hinrichs
>Priority: Blocker
> Fix For: 6.2.0, 7.0.0
>
>
> Looks like we are not closing client connections correctly on the 6.2.x 
> branch.  After taking a server our of rotation for awhile.
> {code}
> [bcall@l28 ~]$ ss -s
> Total: 18212 (kernel 18329)
> TCP:   18122 (estab 17141, closed 123, orphaned 4, synrecv 0, timewait 
> 123/0), ports 152
> {code}
> in traffic top:
> {code}
>  CLIENTORIGIN SERVER
> Requests 1.8 Head Bytes 492.0Requests 1.8 Head Bytes 345.7
> Req/Conn 1.0 Body Bytes   0.0Req/Conn 1.0 Body Bytes   0.0
> New Conn 1.8 Avg Size   269.0New Conn 1.8 Avg Size   189.0
> Curr Conn0.0 Net (bits)   3.9K   Curr Conn0.0 Net (bits)   
> 2.8K
> Active Con   6.6MResp (ms)0.8
> Dynamic KA   0.0
> {code}
> Looks like it is happening on the client connections to TLS ports (ip of the 
> server removed):
> {code}
> [bcall@l28 ~]$ ss -tn | grep 'XXX:44[3-4]' | wc -l
> 12434
> {code}
> And not on the non-TLS ports
> {code}
> [bcall@l28 ~]$ ss -tn | grep 'XXX:8' | wc -l
> 0
> {code}
> Count of the fd for the traffic_server process:
> {code}
> [bcall@l28 ~]$ sudo ls -l /proc/$(pidof traffic_server)/fd | wc -l
> 18127
> {code}



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

[jira] [Updated] (TS-3917) Sending only SETTINGS_INITIAL_WINDOW_SIZE in SETTINGS Frame

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-3917:
--
Backport to Version:   (was: 6.1.2)

> Sending only SETTINGS_INITIAL_WINDOW_SIZE in SETTINGS Frame
> ---
>
> Key: TS-3917
> URL: https://issues.apache.org/jira/browse/TS-3917
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Masaori Koshiba
>Assignee: Bryan Call
>Priority: Critical
> Fix For: 6.2.0
>
>
> After fix for TS-3492, ATS sends only {{SETTINGS_INITIAL_WINDOW_SIZE}} in 
> first SETTINGS Frame.
> ATS should send SETTINGS Parameters when values in records.config is 
> different from default value of RFC7540 (6.5.2 Defined SETTINGS Parameters).
> For example, {{SETTINGS_MAX_CONCURRENT_STREAMS}} is unlimited in RFC7540, but 
> default value in records.config is 100. ATS should send this value in first 
> SETTINGS Frame but not.



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

[jira] [Updated] (TS-4187) connections_currently_open stat not accurate with global server session pools

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4187:
--
Backport to Version:   (was: 6.1.2)

> connections_currently_open stat not accurate with global server session pools
> -
>
> Key: TS-4187
> URL: https://issues.apache.org/jira/browse/TS-4187
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 6.2.0, 7.0.0
>
>
> When global server session pools are used, sockets may be moved to new VCs 
> associated with different threads.  The connections_currently_open stat was 
> not being correctly incremented in that case meaning the 
> connections_currently_open stat would go negative.
> This means that the connection throttling logic would likely not trigger. 



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

[jira] [Updated] (TS-4931) Add process limits to crash logs.

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4931:
--
Backport to Version: 7.0.0

> Add process limits to crash logs.
> -
>
> Key: TS-4931
> URL: https://issues.apache.org/jira/browse/TS-4931
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Tools
>Reporter: James Peach
>Assignee: James Peach
>Priority: Minor
> Fix For: 7.1.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Add {{/proc/$PID/limits}} to the crash log. This helps give context to malloc 
> failures because we can get a reliable snapshot of any process limits in 
> effect at the time.



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

[jira] [Updated] (TS-4929) Should we avoid loading HostDB disk file if sync_frequency is '0' (disabled)

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4929:
--
Labels: 7.0.0  (was: )

> Should we avoid loading HostDB disk file if sync_frequency is '0' (disabled)
> 
>
> Key: TS-4929
> URL: https://issues.apache.org/jira/browse/TS-4929
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HostDB
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
>  Labels: 7.0.0
> Fix For: 7.1.0
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> This addresses two issues:
> 1) We get warnings trying to load a non-existent HostDB (since we don't sync 
> it).
> 2) Worse, if someone has an old HostDB, that is no longer synced / updated, 
> we load the old, possibly stale, data on every startup.
> #2 seems inconsistent with the other changes to HostDB, where now the sync 
> frequency =0 truly turns off disk syncing.



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

[jira] [Updated] (TS-4929) Should we avoid loading HostDB disk file if sync_frequency is '0' (disabled)

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4929:
--
Summary: Should we avoid loading HostDB disk file if sync_frequency is '0' 
(disabled)  (was: Should we avoid loading HostDB disk file is sync_frequency is 
'0' (disabled))

> Should we avoid loading HostDB disk file if sync_frequency is '0' (disabled)
> 
>
> Key: TS-4929
> URL: https://issues.apache.org/jira/browse/TS-4929
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HostDB
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.1.0
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> This addresses two issues:
> 1) We get warnings trying to load a non-existent HostDB (since we don't sync 
> it).
> 2) Worse, if someone has an old HostDB, that is no longer synced / updated, 
> we load the old, possibly stale, data on every startup.
> #2 seems inconsistent with the other changes to HostDB, where now the sync 
> frequency =0 truly turns off disk syncing.



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

[jira] [Reopened] (TS-4913) Crash with active timeout

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom reopened TS-4913:
---

> Crash with active timeout
> -
>
> Key: TS-4913
> URL: https://issues.apache.org/jira/browse/TS-4913
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: Masaori Koshiba
>Priority: Blocker
>
> {noformat}
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x70859700 (LWP 5234)]
> 0x005c3c98 in ProxyClientTransaction::get_netvc (this=0x60ae0001c4e0) 
> at http/../ProxyClientTransaction.h:43
> 43  return (parent) ? parent->get_netvc() : NULL;
> Missing separate debuginfos, use: debuginfo-install 
> glibc-2.17-106.el7_2.4.x86_64 libasan-4.8.3-9.el7.x86_64 
> libgcc-4.8.3-9.el7.x86_64 libstdc++-4.8.3-9.el7.x86_64 
> nss-softokn-freebl-3.16.2.3-14.2.el7_2.x86_64 pcre-8.32-15.el7_2.1.x86_64 
> tcl-8.5.13-4.el7.x86_64 xz-libs-5.1.2-9alpha.el7.x86_64 
> zlib-1.2.7-13.el7.x86_64
> (gdb) bt
> #0  0x005c3c98 in ProxyClientTransaction::get_netvc 
> (this=0x60ae0001c4e0) at http/../ProxyClientTransaction.h:43
> #1  0x006b7376 in HttpSM::update_stats (this=0x7fffe69c71e0) at 
> HttpSM.cc:6967
> #2  0x006b5d6c in HttpSM::kill_this (this=0x7fffe69c71e0) at 
> HttpSM.cc:6833
> #3  0x0068f7d2 in HttpSM::main_handler (this=0x7fffe69c71e0, 
> event=105, data=0x60aa00017e48) at HttpSM.cc:2671
> #4  0x00535fac in Continuation::handleEvent (this=0x7fffe69c71e0, 
> event=105, data=0x60aa00017e48) at ../iocore/eventsystem/I_Continuation.h:153
> #5  0x00a1dc60 in read_signal_and_update (event=105, 
> vc=0x60aa00017d20) at UnixNetVConnection.cc:143
> #6  0x00a25c8b in UnixNetVConnection::mainEvent (this=0x60aa00017d20, 
> event=1, e=0x708588f0) at UnixNetVConnection.cc:1241
> #7  0x00535fac in Continuation::handleEvent (this=0x60aa00017d20, 
> event=1, data=0x708588f0) at ../iocore/eventsystem/I_Continuation.h:153
> #8  0x00a0df73 in NetHandler::_close_vc (this=0x716874e0, 
> vc=0x60aa00017d20, now=1475220689249441376, handle_event=@0x70858a50: 0,
> closed=@0x70858a10: 0, total_idle_time=@0x70858a90: 1, 
> total_idle_count=@0x70858ad0: 1) at UnixNet.cc:668
> #9  0x00a0ccd2 in NetHandler::manage_active_queue 
> (this=0x716874e0, ignore_queue_size=true) at UnixNet.cc:577
> #10 0x00a0f53c in InactivityCop::check_inactivity 
> (this=0x600c0001d2a0, event=2, e=0x608e6ca0) at UnixNet.cc:93
> #11 0x00535fac in Continuation::handleEvent (this=0x600c0001d2a0, 
> event=2, data=0x608e6ca0) at ../iocore/eventsystem/I_Continuation.h:153
> #12 0x00a69c85 in EThread::process_event (this=0x71683800, 
> e=0x608e6ca0, calling_code=2) at UnixEThread.cc:143
> #13 0x00a6a4d5 in EThread::execute (this=0x71683800) at 
> UnixEThread.cc:225
> #14 0x00a685d0 in spawn_thread_internal (a=0x600800015950) at 
> Thread.cc:84
> #15 0x74e64ac8 in ?? () from /lib64/libasan.so.0
> #16 0x7349ddc5 in start_thread () from /lib64/libpthread.so.0
> #17 0x727a828d in clone () from /lib64/libc.so.6
> (gdb) p parent
> $1 = (ProxyClientSession *) 0x60ae0001c200
> (gdb) p parent->get_netvc()
> Cannot access memory at address 0x88
> {noformat}
> h3. Conditions
> - TS with debug and ASan
> - records.config
> {noformat}
> CONFIG proxy.config.http.transaction_active_timeout_in INT 1
> {noformat}
> - Using httpbin as origin server and remap to it
> - access to 'http://localhost:8080/httpbin/delay/2' via curl



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

[jira] [Resolved] (TS-4913) Crash with active timeout

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom resolved TS-4913.
---
   Resolution: Duplicate
Fix Version/s: (was: 7.1.0)

> Crash with active timeout
> -
>
> Key: TS-4913
> URL: https://issues.apache.org/jira/browse/TS-4913
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: Masaori Koshiba
>Priority: Blocker
>
> {noformat}
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x70859700 (LWP 5234)]
> 0x005c3c98 in ProxyClientTransaction::get_netvc (this=0x60ae0001c4e0) 
> at http/../ProxyClientTransaction.h:43
> 43  return (parent) ? parent->get_netvc() : NULL;
> Missing separate debuginfos, use: debuginfo-install 
> glibc-2.17-106.el7_2.4.x86_64 libasan-4.8.3-9.el7.x86_64 
> libgcc-4.8.3-9.el7.x86_64 libstdc++-4.8.3-9.el7.x86_64 
> nss-softokn-freebl-3.16.2.3-14.2.el7_2.x86_64 pcre-8.32-15.el7_2.1.x86_64 
> tcl-8.5.13-4.el7.x86_64 xz-libs-5.1.2-9alpha.el7.x86_64 
> zlib-1.2.7-13.el7.x86_64
> (gdb) bt
> #0  0x005c3c98 in ProxyClientTransaction::get_netvc 
> (this=0x60ae0001c4e0) at http/../ProxyClientTransaction.h:43
> #1  0x006b7376 in HttpSM::update_stats (this=0x7fffe69c71e0) at 
> HttpSM.cc:6967
> #2  0x006b5d6c in HttpSM::kill_this (this=0x7fffe69c71e0) at 
> HttpSM.cc:6833
> #3  0x0068f7d2 in HttpSM::main_handler (this=0x7fffe69c71e0, 
> event=105, data=0x60aa00017e48) at HttpSM.cc:2671
> #4  0x00535fac in Continuation::handleEvent (this=0x7fffe69c71e0, 
> event=105, data=0x60aa00017e48) at ../iocore/eventsystem/I_Continuation.h:153
> #5  0x00a1dc60 in read_signal_and_update (event=105, 
> vc=0x60aa00017d20) at UnixNetVConnection.cc:143
> #6  0x00a25c8b in UnixNetVConnection::mainEvent (this=0x60aa00017d20, 
> event=1, e=0x708588f0) at UnixNetVConnection.cc:1241
> #7  0x00535fac in Continuation::handleEvent (this=0x60aa00017d20, 
> event=1, data=0x708588f0) at ../iocore/eventsystem/I_Continuation.h:153
> #8  0x00a0df73 in NetHandler::_close_vc (this=0x716874e0, 
> vc=0x60aa00017d20, now=1475220689249441376, handle_event=@0x70858a50: 0,
> closed=@0x70858a10: 0, total_idle_time=@0x70858a90: 1, 
> total_idle_count=@0x70858ad0: 1) at UnixNet.cc:668
> #9  0x00a0ccd2 in NetHandler::manage_active_queue 
> (this=0x716874e0, ignore_queue_size=true) at UnixNet.cc:577
> #10 0x00a0f53c in InactivityCop::check_inactivity 
> (this=0x600c0001d2a0, event=2, e=0x608e6ca0) at UnixNet.cc:93
> #11 0x00535fac in Continuation::handleEvent (this=0x600c0001d2a0, 
> event=2, data=0x608e6ca0) at ../iocore/eventsystem/I_Continuation.h:153
> #12 0x00a69c85 in EThread::process_event (this=0x71683800, 
> e=0x608e6ca0, calling_code=2) at UnixEThread.cc:143
> #13 0x00a6a4d5 in EThread::execute (this=0x71683800) at 
> UnixEThread.cc:225
> #14 0x00a685d0 in spawn_thread_internal (a=0x600800015950) at 
> Thread.cc:84
> #15 0x74e64ac8 in ?? () from /lib64/libasan.so.0
> #16 0x7349ddc5 in start_thread () from /lib64/libpthread.so.0
> #17 0x727a828d in clone () from /lib64/libc.so.6
> (gdb) p parent
> $1 = (ProxyClientSession *) 0x60ae0001c200
> (gdb) p parent->get_netvc()
> Cannot access memory at address 0x88
> {noformat}
> h3. Conditions
> - TS with debug and ASan
> - records.config
> {noformat}
> CONFIG proxy.config.http.transaction_active_timeout_in INT 1
> {noformat}
> - Using httpbin as origin server and remap to it
> - access to 'http://localhost:8080/httpbin/delay/2' via curl



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

[jira] [Updated] (TS-4911) ATS restarts when ts_lua plugin is used with collapsed_forwarding plugin and write lock error was encountered (thundering herd problem)

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4911:
--
Backport to Version: 6.2.1, 7.0.0  (was: 7.0.0)

> ATS restarts when ts_lua plugin is used with collapsed_forwarding plugin and 
> write lock error was encountered (thundering herd problem)
> ---
>
> Key: TS-4911
> URL: https://issues.apache.org/jira/browse/TS-4911
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Lua, Plugins
>Affects Versions: 6.2.1, 7.0.0, 7.1.0
>Reporter: Rajendra Kishore Bonumahanti
>Assignee: Kit Chan
> Fix For: 7.1.0
>
>  Time Spent: 3h
>  Remaining Estimate: 0h
>
> ATS (ts_lua plugin is used along with collapsed_forwarding plugin) got 
> restarted due to “FATAL: InkAPI.cc:3800: failed assert 
> `sdk_sanity_check_http_hdr_handle(obj) == TS_SUCCESS`” when write lock error 
> was encountered (thundering herd problem). The ATS restart is due to 
> ts.client_response.get_status() function call in 
> TS_LUA_HOOK_SEND_RESPONSE_HDR hook function when re-direct is enabled on 502 
> error.
> == error when ts_lua plugin is used with collapsed_forwarding plugin ==
> map http://testurl.com/ http://origin.com/ @plugin=tslua.so 
> @pparam=/opt/trafficserver/etc/trafficserver/lua/test.lua 
> @plugin=collapsed_forwarding.so @pparam=--delay=10 @pparam=--retries=5
> test.lua:
> ===
> function __init__()
>local FUNCTION = '__init__(): '
> ts.debug(FUNCTION .. 'Entering..')
> return 0
> end
> function responseHook()
> local FUNCTION = 'responseHook(): '
> ts.debug(FUNCTION .. 'Entering..')
> local c_code = tostring(ts.client_response.get_status())
> ts.debug(FUNCTION .. 'Original client_response_code: ' .. c_code)
> if string.find(c_code, "^[45]") then
> ts.debug(FUNCTION .. 'client response code is now set to 500')
> ts.client_response.set_status(500)
> end
> return 0
> end
> function do_remap()
> local FUNCTION = 'do_remap(): '
> ts.debug(FUNCTION .. 'Entering..')
> ts.hook(TS_LUA_HOOK_SEND_RESPONSE_HDR, responseHook)
> return 0
> end
> 
> The log…
> [Sep 20 19:53:43.746] Server {0x2ad69673e700} DEBUG: (http) [148] State 
> Transition: SM_ACTION_AP_CACHE_LOOKUP_COMPLETE -> SM_ACTION_SERVE_FROM_CACHE
> [Sep 20 19:53:43.746] Server {0x2ad69673e700} DEBUG: (http) [148] 
> perform_cache_write_action CACE_DO_SERVE
> [Sep 20 19:53:43.746] Server {0x2ad69673e700} DEBUG: (http_redirect) 
> is_redirect_required 1
> [Sep 20 19:53:43.746] Server {0x2ad69673e700} DEBUG: (http) [148] calling 
> plugin on hook TS_HTTPSEND_RESPONSE_HDR_HOOK at hook 0x1832bc0
> [Sep 20 19:53:43.746] Server {0x2ad69673e700} DIAG: (ts_lua) responseHook(): 
> Entering..
> FATAL: InkAPI.cc:3800: failed assert `sdk_sanity_check_http_hdr_handle(obj) 
> == TS_SUCCESS`
> traffic_server: using root directory '/opt/trafficserver'
> validate_filter_args: "action=deny"
> -
> Filter "" status: allow_flag=false, src_ip_valid=false, 
> in_ip_valid=false, internal=false active_queue_flag=0
> standard methods=nonstandard methods=
> src_ip_cnt=0
> in_ip_cnt=0
> URL Rewrite table with 3 entries
>   Reverse Proxy is On
>   Forward Mapping Table with 3 entries
>  http:/// => http://127.0.0.1/  <> [plugins not enabled; running with 
> 0 plugins]
>  http://xx.xx.xx.xx/ => http://xx.xx.xx.xx/  <> [plugins are enabled; 
> running with  plugins]
>  http://testurl.com/ => http://origin.com//  <> [plugins are enabled; 
> running with 2 plugins]
>   Reverse Mapping Table with 0 entries
>   Permanent Redirect Mapping Table with 0 entries
>   Temporary Redirect Mapping Table with 0 entries
>   Forward Mapping With Recv Port Table with 0 entries
>   Referer filter default redirect URL: "http://www.example.com/;
> traffic_server: Aborted (Signal sent by tkill() 129399 99)
> traffic_server - STACK TRACE:
> /opt/trafficserver/bin/traffic_server(_Z19crash_logger_invokeiP9siginfo_tPv+0x8e)[0x4ab5ee]
> /lib64/libpthread.so.0(+0xf100)[0x2ad67f3eb100]
> /lib64/libc.so.6(gsignal+0x37)[0x2ad6803bb5f7]
> /lib64/libc.so.6(abort+0x148)[0x2ad6803bcce8]
> /opt/trafficserver/lib/libtsutil.so.6(+0x28668)[0x2ad67d927668]
> /opt/trafficserver/lib/libtsutil.so.6(+0x286fc)[0x2ad67d9276fc]
> /opt/trafficserver/lib/libtsutil.so.6(+0x269e5)[0x2ad67d9259e5]
> /opt/trafficserver/bin/traffic_server[0x4c7973]
> /opt/trafficserver/libexec/trafficserver/tslua.so(+0x9aeb)[0x2ad695821aeb]
> /opt/trafficserver/bin/traffic_server[0x5834e6]
> 
> It appears, the following 

[jira] [Updated] (TS-4911) ATS restarts when ts_lua plugin is used with collapsed_forwarding plugin and write lock error was encountered (thundering herd problem)

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4911:
--
Backport to Version: 7.0.0  (was: 6.2.0)

> ATS restarts when ts_lua plugin is used with collapsed_forwarding plugin and 
> write lock error was encountered (thundering herd problem)
> ---
>
> Key: TS-4911
> URL: https://issues.apache.org/jira/browse/TS-4911
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Lua, Plugins
>Affects Versions: 6.2.1, 7.0.0, 7.1.0
>Reporter: Rajendra Kishore Bonumahanti
>Assignee: Kit Chan
> Fix For: 7.1.0
>
>  Time Spent: 3h
>  Remaining Estimate: 0h
>
> ATS (ts_lua plugin is used along with collapsed_forwarding plugin) got 
> restarted due to “FATAL: InkAPI.cc:3800: failed assert 
> `sdk_sanity_check_http_hdr_handle(obj) == TS_SUCCESS`” when write lock error 
> was encountered (thundering herd problem). The ATS restart is due to 
> ts.client_response.get_status() function call in 
> TS_LUA_HOOK_SEND_RESPONSE_HDR hook function when re-direct is enabled on 502 
> error.
> == error when ts_lua plugin is used with collapsed_forwarding plugin ==
> map http://testurl.com/ http://origin.com/ @plugin=tslua.so 
> @pparam=/opt/trafficserver/etc/trafficserver/lua/test.lua 
> @plugin=collapsed_forwarding.so @pparam=--delay=10 @pparam=--retries=5
> test.lua:
> ===
> function __init__()
>local FUNCTION = '__init__(): '
> ts.debug(FUNCTION .. 'Entering..')
> return 0
> end
> function responseHook()
> local FUNCTION = 'responseHook(): '
> ts.debug(FUNCTION .. 'Entering..')
> local c_code = tostring(ts.client_response.get_status())
> ts.debug(FUNCTION .. 'Original client_response_code: ' .. c_code)
> if string.find(c_code, "^[45]") then
> ts.debug(FUNCTION .. 'client response code is now set to 500')
> ts.client_response.set_status(500)
> end
> return 0
> end
> function do_remap()
> local FUNCTION = 'do_remap(): '
> ts.debug(FUNCTION .. 'Entering..')
> ts.hook(TS_LUA_HOOK_SEND_RESPONSE_HDR, responseHook)
> return 0
> end
> 
> The log…
> [Sep 20 19:53:43.746] Server {0x2ad69673e700} DEBUG: (http) [148] State 
> Transition: SM_ACTION_AP_CACHE_LOOKUP_COMPLETE -> SM_ACTION_SERVE_FROM_CACHE
> [Sep 20 19:53:43.746] Server {0x2ad69673e700} DEBUG: (http) [148] 
> perform_cache_write_action CACE_DO_SERVE
> [Sep 20 19:53:43.746] Server {0x2ad69673e700} DEBUG: (http_redirect) 
> is_redirect_required 1
> [Sep 20 19:53:43.746] Server {0x2ad69673e700} DEBUG: (http) [148] calling 
> plugin on hook TS_HTTPSEND_RESPONSE_HDR_HOOK at hook 0x1832bc0
> [Sep 20 19:53:43.746] Server {0x2ad69673e700} DIAG: (ts_lua) responseHook(): 
> Entering..
> FATAL: InkAPI.cc:3800: failed assert `sdk_sanity_check_http_hdr_handle(obj) 
> == TS_SUCCESS`
> traffic_server: using root directory '/opt/trafficserver'
> validate_filter_args: "action=deny"
> -
> Filter "" status: allow_flag=false, src_ip_valid=false, 
> in_ip_valid=false, internal=false active_queue_flag=0
> standard methods=nonstandard methods=
> src_ip_cnt=0
> in_ip_cnt=0
> URL Rewrite table with 3 entries
>   Reverse Proxy is On
>   Forward Mapping Table with 3 entries
>  http:/// => http://127.0.0.1/  <> [plugins not enabled; running with 
> 0 plugins]
>  http://xx.xx.xx.xx/ => http://xx.xx.xx.xx/  <> [plugins are enabled; 
> running with  plugins]
>  http://testurl.com/ => http://origin.com//  <> [plugins are enabled; 
> running with 2 plugins]
>   Reverse Mapping Table with 0 entries
>   Permanent Redirect Mapping Table with 0 entries
>   Temporary Redirect Mapping Table with 0 entries
>   Forward Mapping With Recv Port Table with 0 entries
>   Referer filter default redirect URL: "http://www.example.com/;
> traffic_server: Aborted (Signal sent by tkill() 129399 99)
> traffic_server - STACK TRACE:
> /opt/trafficserver/bin/traffic_server(_Z19crash_logger_invokeiP9siginfo_tPv+0x8e)[0x4ab5ee]
> /lib64/libpthread.so.0(+0xf100)[0x2ad67f3eb100]
> /lib64/libc.so.6(gsignal+0x37)[0x2ad6803bb5f7]
> /lib64/libc.so.6(abort+0x148)[0x2ad6803bcce8]
> /opt/trafficserver/lib/libtsutil.so.6(+0x28668)[0x2ad67d927668]
> /opt/trafficserver/lib/libtsutil.so.6(+0x286fc)[0x2ad67d9276fc]
> /opt/trafficserver/lib/libtsutil.so.6(+0x269e5)[0x2ad67d9259e5]
> /opt/trafficserver/bin/traffic_server[0x4c7973]
> /opt/trafficserver/libexec/trafficserver/tslua.so(+0x9aeb)[0x2ad695821aeb]
> /opt/trafficserver/bin/traffic_server[0x5834e6]
> 
> It appears, the following code 

[jira] [Updated] (TS-4895) CID 1021743: Uninitialized members in iocore/net/UnixNet.cc

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4895:
--
Backport to Version: 7.0.0

> CID 1021743:  Uninitialized members in iocore/net/UnixNet.cc
> 
>
> Key: TS-4895
> URL: https://issues.apache.org/jira/browse/TS-4895
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Network
>Reporter: Leif Hedstrom
>Assignee: Oknet Xu
>  Labels: coverity
> Fix For: 7.1.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> {code}
> *** CID 1021743:  Uninitialized members  (UNINIT_CTOR)
> /iocore/net/UnixNet.cc: 269 in NetHandler::NetHandler()()
> 263 max_connections_active_in(0),
> 264 inactive_threashold_in(0),
> 265 transaction_no_activity_timeout_in(0),
> 266 keep_alive_no_activity_timeout_in(0)
> 267 {
> 268   SET_HANDLER((NetContHandler)::startNetEvent);
>CID 1021743:  Uninitialized members  (UNINIT_CTOR)
>Non-static class member "default_inactivity_timeout" is not initialized in 
> this constructor nor in any functions that it calls.
> 269 }
> 270 
> 271 int
> 272 update_nethandler_config(const char *name, RecDataT data_type 
> ATS_UNUSED, RecData data, void *cookie)
> 273 {
> 274   NetHandler *nh = static_cast(cookie);
> {code}



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

[jira] [Reopened] (TS-4893) Leaking H2 connections

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom reopened TS-4893:
---

> Leaking H2 connections
> --
>
> Key: TS-4893
> URL: https://issues.apache.org/jira/browse/TS-4893
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2, Network
>Reporter: Leif Hedstrom
>
> On Docs, I'm seeing e.g. this:
> {code}
> [TS_MAIN] 1728 nobody   52u IPv4 1548184130  0t0TCP 
> qa1:https->unknown.servercentral.net:60107 (ESTABLISHED)
> [TS_MAIN] 1728 nobody   53u IPv4 1517137327  0t0TCP 
> qa1:https->msnbot-157-55-39-245.search.msn.com:18649 (ESTABLISHED)
> [TS_MAIN] 1728 nobody   54u IPv4 1547299121  0t0TCP 
> qa1:https->unknown.servercentral.net:54210 (ESTABLISHED)
> [TS_MAIN] 1728 nobody   55u IPv4 1546653567  0t0TCP 
> qa1:https->unknown.servercentral.net:38563 (ESTABLISHED)
> [TS_MAIN] 1728 nobody   56u  REG  202,1 29071711981 
> /opt/ats/var/log/trafficserver/error.log
> [TS_MAIN] 1728 nobody   57u IPv4 1547305120  0t0TCP 
> qa1:https->unknown.servercentral.net:54558 (ESTABLISHED)
> [TS_MAIN] 1728 nobody   58u IPv4 1546341443  0t0TCP 
> qa1:https->unknown.servercentral.net:45169 (ESTABLISHED)
> [TS_MAIN] 1728 nobody   59u IPv4 1548496071  0t0TCP 
> qa1:https->unknown.servercentral.net:45723 (ESTABLISHED)
> [TS_MAIN] 1728 nobody   60u IPv4 1585632811  0t0TCP 
> qa1:https->183.240.202.49:31756 (ESTABLISHED)
> [TS_MAIN] 1728 nobody   61u IPv4 1565899597  0t0TCP 
> qa1:https->unknown.servercentral.net:56875 (ESTABLISHED)
> [TS_MAIN] 1728 nobody   62u IPv4 1566772178  0t0TCP 
> qa1:https->unknown.servercentral.net:52435 (ESTABLISHED)
> [TS_MAIN] 1728 nobody   63u IPv4 1567423730  0t0TCP 
> qa1:https->unknown.servercentral.net:44075 (ESTABLISHED)
> [TS_MAIN] 1728 nobody   64u IPv4 1585491833  0t0TCP 
> qa1:https->c-73-181-14-238.hsd1.co.comcast.net:62420 (ESTABLISHED)
> [TS_MAIN] 1728 nobody   65u IPv4 1566460810  0t0TCP 
> qa1:https->unknown.servercentral.net:39178 (ESTABLISHED)
> [TS_MAIN] 1728 nobody   66u IPv4 1585625076  0t0TCP 
> qa1:https->143.37.120.106.static.bjtelecom.net:61392 (ESTABLISHED)
> [TS_MAIN] 1728 nobody   68u IPv4 1585680362  0t0TCP 
> qa1:52297->192.168.3.1:acmsoda (ESTABLISHED)
> [TS_MAIN] 1728 nobody   73u IPv4 1585595085  0t0TCP 
> qa1:https->89.25.14.226:36281 (ESTABLISHED)
> {code}
> These do generally not seem to clear. At the same time as this was captured, 
> I checked the metrics for client connections, and there were none reported by 
> ATS. This might be related to TS-4833, and perhaps TS-4892.



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

[jira] [Updated] (TS-4888) collapsed_forwarding plugin returns TSREMAP_DID_REMAP though it did not perform remap

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4888:
--
Backport to Version: 6.2.1, 7.0.0  (was: 7.0.0)

> collapsed_forwarding plugin returns TSREMAP_DID_REMAP though it did not 
> perform remap
> -
>
> Key: TS-4888
> URL: https://issues.apache.org/jira/browse/TS-4888
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Affects Versions: 6.2.1, 7.1.0
>Reporter: Rajendra Kishore Bonumahanti
>Assignee: Phil Sorber
> Fix For: 7.1.0
>
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> Collapsed_forwarding plugin returns TSREMAP_DID_REMAP as a return value 
> though it did not perform any remap. This causes ATS not to perform remap and 
> makes the transaction failed due to DNS lookup error on "from url".
> For more details..
> Hi,
> I am testing collapsed_forwarding plugin 
> (https://docs.trafficserver.apache.org/en/latest/admin-guide/plugins/collapsed_forwarding.en.html?highlight=collapsed_forwarding)
>  via ATS 6.2.x branch.
> We observed an error "DNS error 2 for [testurl.com]" for cache-miss, when 
> remap.config is configured with "collapsed_forwarding" to work alone as a 
> remap plugin. We must modify TSRemapDoRemap() in the plugin to "return 
> TSREMAP_NO_REMAP" to allow DNS lookup successful. It does not seem right for 
> the plugin to do "return TSREMAP_NO_REMAP" when it did not.
> Can someone help me to understand how this plugin needs to be used? Or does 
> it require the fix I mentioned above?
> Regards,
> Kishore
> == Sample remap.config entry and cach miss error when used 
> "collapsed_forwarding" by itself == map http://testurl.com/ 
> http://origin.com/ @plugin=collapsed_forwarding.so @pparam=--delay=10 
> @pparam=--retries=5
> I observed that during cache-miss, DNS query happens on the 'from' url 
> (hostname) in the remap and it gets failed.
> 
> [Sep  9 19:39:16.355] Server {0x2b170ea6c940} DEBUG: (dns) send query 
> (qtype=1) for testurl.com to fd 43 [Sep  9 19:39:16.355] Server 
> {0x2b170ea6c940} DEBUG: (dns) sent qname = testurl.com, id = 9287, nameserver 
> = 1 [Sep  9 19:39:16.355] Server {0x2b170ea6c940} DEBUG: (dns) sent_one: 
> failover_number for resolve 1 is 1 [Sep  9 19:39:16.628] Server 
> {0x2b170ea6c940} DEBUG: (dns) received packet size = 52 [Sep  9 19:39:16.628] 
> Server {0x2b170ea6c940} DEBUG: (dns) round-robin: nameserver 1 DNS respons 
> code = 0 [Sep  9 19:39:16.628] Server {0x2b170ea6c940} DEBUG: (dns) received 
> rcode = 2 [Sep  9 19:39:16.628] Server {0x2b170ea6c940} DEBUG: (dns) DNS 
> error 2 for [testurl.com] [Sep  9 19:39:16.628] Server {0x2b170ea6c940} 
> DEBUG: (dns) doing retry for testurl.com
> I further looked in to the code and found that it is due to return code from 
> the plugin is TSREMAP_DID_REMAP in TSRemapDoRemap(). It makes ATS not to 
> perform remap.



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

[jira] [Resolved] (TS-4893) Leaking H2 connections

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom resolved TS-4893.
---
Resolution: Duplicate

> Leaking H2 connections
> --
>
> Key: TS-4893
> URL: https://issues.apache.org/jira/browse/TS-4893
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2, Network
>Reporter: Leif Hedstrom
>
> On Docs, I'm seeing e.g. this:
> {code}
> [TS_MAIN] 1728 nobody   52u IPv4 1548184130  0t0TCP 
> qa1:https->unknown.servercentral.net:60107 (ESTABLISHED)
> [TS_MAIN] 1728 nobody   53u IPv4 1517137327  0t0TCP 
> qa1:https->msnbot-157-55-39-245.search.msn.com:18649 (ESTABLISHED)
> [TS_MAIN] 1728 nobody   54u IPv4 1547299121  0t0TCP 
> qa1:https->unknown.servercentral.net:54210 (ESTABLISHED)
> [TS_MAIN] 1728 nobody   55u IPv4 1546653567  0t0TCP 
> qa1:https->unknown.servercentral.net:38563 (ESTABLISHED)
> [TS_MAIN] 1728 nobody   56u  REG  202,1 29071711981 
> /opt/ats/var/log/trafficserver/error.log
> [TS_MAIN] 1728 nobody   57u IPv4 1547305120  0t0TCP 
> qa1:https->unknown.servercentral.net:54558 (ESTABLISHED)
> [TS_MAIN] 1728 nobody   58u IPv4 1546341443  0t0TCP 
> qa1:https->unknown.servercentral.net:45169 (ESTABLISHED)
> [TS_MAIN] 1728 nobody   59u IPv4 1548496071  0t0TCP 
> qa1:https->unknown.servercentral.net:45723 (ESTABLISHED)
> [TS_MAIN] 1728 nobody   60u IPv4 1585632811  0t0TCP 
> qa1:https->183.240.202.49:31756 (ESTABLISHED)
> [TS_MAIN] 1728 nobody   61u IPv4 1565899597  0t0TCP 
> qa1:https->unknown.servercentral.net:56875 (ESTABLISHED)
> [TS_MAIN] 1728 nobody   62u IPv4 1566772178  0t0TCP 
> qa1:https->unknown.servercentral.net:52435 (ESTABLISHED)
> [TS_MAIN] 1728 nobody   63u IPv4 1567423730  0t0TCP 
> qa1:https->unknown.servercentral.net:44075 (ESTABLISHED)
> [TS_MAIN] 1728 nobody   64u IPv4 1585491833  0t0TCP 
> qa1:https->c-73-181-14-238.hsd1.co.comcast.net:62420 (ESTABLISHED)
> [TS_MAIN] 1728 nobody   65u IPv4 1566460810  0t0TCP 
> qa1:https->unknown.servercentral.net:39178 (ESTABLISHED)
> [TS_MAIN] 1728 nobody   66u IPv4 1585625076  0t0TCP 
> qa1:https->143.37.120.106.static.bjtelecom.net:61392 (ESTABLISHED)
> [TS_MAIN] 1728 nobody   68u IPv4 1585680362  0t0TCP 
> qa1:52297->192.168.3.1:acmsoda (ESTABLISHED)
> [TS_MAIN] 1728 nobody   73u IPv4 1585595085  0t0TCP 
> qa1:https->89.25.14.226:36281 (ESTABLISHED)
> {code}
> These do generally not seem to clear. At the same time as this was captured, 
> I checked the metrics for client connections, and there were none reported by 
> ATS. This might be related to TS-4833, and perhaps TS-4892.



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

[jira] [Updated] (TS-4893) Leaking H2 connections

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4893:
--
Fix Version/s: (was: 7.1.0)

> Leaking H2 connections
> --
>
> Key: TS-4893
> URL: https://issues.apache.org/jira/browse/TS-4893
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2, Network
>Reporter: Leif Hedstrom
>
> On Docs, I'm seeing e.g. this:
> {code}
> [TS_MAIN] 1728 nobody   52u IPv4 1548184130  0t0TCP 
> qa1:https->unknown.servercentral.net:60107 (ESTABLISHED)
> [TS_MAIN] 1728 nobody   53u IPv4 1517137327  0t0TCP 
> qa1:https->msnbot-157-55-39-245.search.msn.com:18649 (ESTABLISHED)
> [TS_MAIN] 1728 nobody   54u IPv4 1547299121  0t0TCP 
> qa1:https->unknown.servercentral.net:54210 (ESTABLISHED)
> [TS_MAIN] 1728 nobody   55u IPv4 1546653567  0t0TCP 
> qa1:https->unknown.servercentral.net:38563 (ESTABLISHED)
> [TS_MAIN] 1728 nobody   56u  REG  202,1 29071711981 
> /opt/ats/var/log/trafficserver/error.log
> [TS_MAIN] 1728 nobody   57u IPv4 1547305120  0t0TCP 
> qa1:https->unknown.servercentral.net:54558 (ESTABLISHED)
> [TS_MAIN] 1728 nobody   58u IPv4 1546341443  0t0TCP 
> qa1:https->unknown.servercentral.net:45169 (ESTABLISHED)
> [TS_MAIN] 1728 nobody   59u IPv4 1548496071  0t0TCP 
> qa1:https->unknown.servercentral.net:45723 (ESTABLISHED)
> [TS_MAIN] 1728 nobody   60u IPv4 1585632811  0t0TCP 
> qa1:https->183.240.202.49:31756 (ESTABLISHED)
> [TS_MAIN] 1728 nobody   61u IPv4 1565899597  0t0TCP 
> qa1:https->unknown.servercentral.net:56875 (ESTABLISHED)
> [TS_MAIN] 1728 nobody   62u IPv4 1566772178  0t0TCP 
> qa1:https->unknown.servercentral.net:52435 (ESTABLISHED)
> [TS_MAIN] 1728 nobody   63u IPv4 1567423730  0t0TCP 
> qa1:https->unknown.servercentral.net:44075 (ESTABLISHED)
> [TS_MAIN] 1728 nobody   64u IPv4 1585491833  0t0TCP 
> qa1:https->c-73-181-14-238.hsd1.co.comcast.net:62420 (ESTABLISHED)
> [TS_MAIN] 1728 nobody   65u IPv4 1566460810  0t0TCP 
> qa1:https->unknown.servercentral.net:39178 (ESTABLISHED)
> [TS_MAIN] 1728 nobody   66u IPv4 1585625076  0t0TCP 
> qa1:https->143.37.120.106.static.bjtelecom.net:61392 (ESTABLISHED)
> [TS_MAIN] 1728 nobody   68u IPv4 1585680362  0t0TCP 
> qa1:52297->192.168.3.1:acmsoda (ESTABLISHED)
> [TS_MAIN] 1728 nobody   73u IPv4 1585595085  0t0TCP 
> qa1:https->89.25.14.226:36281 (ESTABLISHED)
> {code}
> These do generally not seem to clear. At the same time as this was captured, 
> I checked the metrics for client connections, and there were none reported by 
> ATS. This might be related to TS-4833, and perhaps TS-4892.



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

[jira] [Updated] (TS-4888) collapsed_forwarding plugin returns TSREMAP_DID_REMAP though it did not perform remap

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4888:
--
Backport to Version: 7.0.0  (was: 6.2.1, 7.0.0)

> collapsed_forwarding plugin returns TSREMAP_DID_REMAP though it did not 
> perform remap
> -
>
> Key: TS-4888
> URL: https://issues.apache.org/jira/browse/TS-4888
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Affects Versions: 6.2.1, 7.1.0
>Reporter: Rajendra Kishore Bonumahanti
>Assignee: Phil Sorber
> Fix For: 7.1.0
>
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> Collapsed_forwarding plugin returns TSREMAP_DID_REMAP as a return value 
> though it did not perform any remap. This causes ATS not to perform remap and 
> makes the transaction failed due to DNS lookup error on "from url".
> For more details..
> Hi,
> I am testing collapsed_forwarding plugin 
> (https://docs.trafficserver.apache.org/en/latest/admin-guide/plugins/collapsed_forwarding.en.html?highlight=collapsed_forwarding)
>  via ATS 6.2.x branch.
> We observed an error "DNS error 2 for [testurl.com]" for cache-miss, when 
> remap.config is configured with "collapsed_forwarding" to work alone as a 
> remap plugin. We must modify TSRemapDoRemap() in the plugin to "return 
> TSREMAP_NO_REMAP" to allow DNS lookup successful. It does not seem right for 
> the plugin to do "return TSREMAP_NO_REMAP" when it did not.
> Can someone help me to understand how this plugin needs to be used? Or does 
> it require the fix I mentioned above?
> Regards,
> Kishore
> == Sample remap.config entry and cach miss error when used 
> "collapsed_forwarding" by itself == map http://testurl.com/ 
> http://origin.com/ @plugin=collapsed_forwarding.so @pparam=--delay=10 
> @pparam=--retries=5
> I observed that during cache-miss, DNS query happens on the 'from' url 
> (hostname) in the remap and it gets failed.
> 
> [Sep  9 19:39:16.355] Server {0x2b170ea6c940} DEBUG: (dns) send query 
> (qtype=1) for testurl.com to fd 43 [Sep  9 19:39:16.355] Server 
> {0x2b170ea6c940} DEBUG: (dns) sent qname = testurl.com, id = 9287, nameserver 
> = 1 [Sep  9 19:39:16.355] Server {0x2b170ea6c940} DEBUG: (dns) sent_one: 
> failover_number for resolve 1 is 1 [Sep  9 19:39:16.628] Server 
> {0x2b170ea6c940} DEBUG: (dns) received packet size = 52 [Sep  9 19:39:16.628] 
> Server {0x2b170ea6c940} DEBUG: (dns) round-robin: nameserver 1 DNS respons 
> code = 0 [Sep  9 19:39:16.628] Server {0x2b170ea6c940} DEBUG: (dns) received 
> rcode = 2 [Sep  9 19:39:16.628] Server {0x2b170ea6c940} DEBUG: (dns) DNS 
> error 2 for [testurl.com] [Sep  9 19:39:16.628] Server {0x2b170ea6c940} 
> DEBUG: (dns) doing retry for testurl.com
> I further looked in to the code and found that it is due to return code from 
> the plugin is TSREMAP_DID_REMAP in TSRemapDoRemap(). It makes ATS not to 
> perform remap.



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

[jira] [Updated] (TS-4885) Incorrect checking of fds_throttle and fds_limit

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4885:
--
Backport to Version: 7.0.0

> Incorrect checking of fds_throttle and fds_limit
> 
>
> Key: TS-4885
> URL: https://issues.apache.org/jira/browse/TS-4885
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Oknet Xu
>Assignee: Oknet Xu
> Fix For: 7.1.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> {code}
>  902 static void
>  903 check_fd_limit()
>  904 {
>  905   int fds_throttle = -1;
>  906   REC_ReadConfigInteger(fds_throttle, 
> "proxy.config.net.connections_throttle");
>  907   if (fds_throttle > fds_limit + THROTTLE_FD_HEADROOM) {  // 
> ---> Incorrect
>  908 int new_fds_throttle = fds_limit - THROTTLE_FD_HEADROOM;
>  909 if (new_fds_throttle < 1) {
>  910   ink_abort("too few file descriptors (%d) available", fds_limit);
>  911 }
>  912 char msg[256];
>  913 snprintf(msg, sizeof(msg), "connection throttle too high, "
>  914"%d (throttle) + %d (internal use) > %d 
> (file descriptor limit), "
>  915"using throttle of %d",
>  916  fds_throttle, THROTTLE_FD_HEADROOM, fds_limit, 
> new_fds_throttle);
>  917 SignalWarning(MGMT_SIGNAL_SYSTEM_ERROR, msg);
>  918   }
>  919 }
> {code}
> {code}
> 1001 static void
> 1002 adjust_sys_settings(void)
> 1003 {
> ...
> 1024   REC_ReadConfigInteger(fds_throttle, 
> "proxy.config.net.connections_throttle");
> 1025 
> 1026   if (getrlimit(RLIMIT_NOFILE, ) == 0) {
> 1027 if (fds_throttle > (int)(lim.rlim_cur + THROTTLE_FD_HEADROOM)) {  // 
> --> Incorrect
> 1028   lim.rlim_cur = (lim.rlim_max = (rlim_t)fds_throttle);
> 1029   if (setrlimit(RLIMIT_NOFILE, ) == 0 && 
> getrlimit(RLIMIT_NOFILE, ) == 0) {
> 1030 fds_limit = (int)lim.rlim_cur;
> 1031 syslog(LOG_NOTICE, "NOTE: RLIMIT_NOFILE(%d):cur(%d),max(%d)", 
> RLIMIT_NOFILE, (int)lim.rlim_cur, (int)lim.rlim_max);
> 1032   }
> 1033 }
> 1034   }
> ...
> 1043 }
> {code}



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

[jira] [Updated] (TS-4884) Remove a few unused variables/define in EThread

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4884:
--
Backport to Version: 7.0.0

> Remove a few unused variables/define in EThread
> ---
>
> Key: TS-4884
> URL: https://issues.apache.org/jira/browse/TS-4884
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: Masato Gosui
>Assignee: Phil Sorber
> Fix For: 7.1.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> EThread has variable accept_event and main_accept_index, which are unused.
> Also MAX_ACCEPT_EVENTS is not used other than the declaration of accept_event.
> We should be able to remove them without any side effects.
> Looks like these are remnants of old code cleanup.
> https://github.com/apache/trafficserver/commit/0a0c90dd94fd53a0cf9617f945e4e7d9fe42c7a9



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

[jira] [Commented] (TS-4883) Argument mismatch of the Thread::start call in EventProcessor::start

[Phil Sorber (JIRA)]

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

Phil Sorber commented on TS-4883:
-

#1037 should be backported and #1048 is at your discretion.

> Argument mismatch of the Thread::start call in EventProcessor::start
> 
>
> Key: TS-4883
> URL: https://issues.apache.org/jira/browse/TS-4883
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Masato Gosui
>Assignee: Phil Sorber
> Fix For: 7.1.0
>
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> EventProcessor::start() calls Thread::start(), which takes 5 arguments: 
> # name
> # stacksize
> # f(function pointer to be executed by the thread)
> # a(argument for f)
> # stack(pointer to stack used by the thread)
> However the call to Thread::start() takes the pointer to stack as 4th 
> argument.



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

[jira] [Updated] (TS-4883) Argument mismatch of the Thread::start call in EventProcessor::start

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4883:
--
Backport to Version: 7.0.0

> Argument mismatch of the Thread::start call in EventProcessor::start
> 
>
> Key: TS-4883
> URL: https://issues.apache.org/jira/browse/TS-4883
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Masato Gosui
>Assignee: Phil Sorber
> Fix For: 7.1.0
>
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> EventProcessor::start() calls Thread::start(), which takes 5 arguments: 
> # name
> # stacksize
> # f(function pointer to be executed by the thread)
> # a(argument for f)
> # stack(pointer to stack used by the thread)
> However the call to Thread::start() takes the pointer to stack as 4th 
> argument.



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

[jira] [Updated] (TS-4879) NetVC leaks while hyper emergency occur on check_emergency_throttle()

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4879:
--
Backport to Version: 7.0.0

> NetVC leaks while hyper emergency occur on check_emergency_throttle()
> -
>
> Key: TS-4879
> URL: https://issues.apache.org/jira/browse/TS-4879
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Oknet Xu
>Assignee: Oknet Xu
> Fix For: 7.1.0
>
>  Time Spent: 4.5h
>  Remaining Estimate: 0h
>
> The con could be closed if hyper emergency occur on 
> check_emergency_throttle().
> But we did not check the con.fd while we get return from 
> check_emergency_throttle().
> For hyper emergency:
> - The socket fd is removed from epoll while it is closed.
> - A NetVC with a closed socket fd is created and callback NET_EVENT_OPEN to 
> SM.
> Thus:
> - The NetVC will never triggered by NetHandler.
> - Only InactivityCop could handle the NetVC and the default timeout value is 
> 86400 secs.
> For the counter: net_connections_currently_open_stat
> - It is increased in “connect_re_internal()”
> - It isn't decreased while the con.fd set to NO_FD due to hyper emergency 
> - Because it is decreased in close_UnixNetVConnection() only con.fd != NO_FD. 
> (TS-4178)



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

[jira] [Updated] (TS-4875) Hoist SSL index creation into library initialization.

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4875:
--
Backport to Version: 7.0.0

> Hoist SSL index creation into library initialization.
> -
>
> Key: TS-4875
> URL: https://issues.apache.org/jira/browse/TS-4875
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SSL
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.1.0
>
>  Time Spent: 2h 20m
>  Remaining Estimate: 0h
>
> The SSL index used for server certificate validation can only be created 
> once, so we need to do it in the library initialization, not the client 
> context initialization. In principle, we can initialize client contexts 
> multiple times.



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

[jira] [Updated] (TS-4870) Storage can be marked offline multiple times which breaks related metrics

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4870:
--
Backport to Version: 7.0.0

> Storage can be marked offline multiple times which breaks related metrics
> -
>
> Key: TS-4870
> URL: https://issues.apache.org/jira/browse/TS-4870
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cache, Metrics
>Reporter: Gancho Tenev
>Assignee: Gancho Tenev
> Fix For: 7.1.0
>
>  Time Spent: 2h 50m
>  Remaining Estimate: 0h
>
> Let us say traffic server is running with 2 disks
> {code}
> $ cat etc/trafficserver/storage.config
> /dev/sdb
> /dev/sdc
> $ sudo fdisk -l|grep 'Disk /dev/sd[b|c]'
> Disk /dev/sdb: 134 MB, 134217728 bytes
> Disk /dev/sdc: 134 MB, 134217728 bytes
> {code}
> Let us see what happens when we mark the same disk 3 times in a raw 
> ({{/dev/sdb}}) and check the {{proxy.node.cache.bytes_total}}.
> {code}
> # Initial cache size (when using both disks).
> $ ./bin/traffic_ctl metric get proxy.node.cache.bytes_total
> proxy.node.cache.bytes_total 268025856
> # Take 1st disk offline. Cache size changes as expected.
> $ sudo ./bin/traffic_ctl storage offline /dev/sdb
> $ ./bin/traffic_ctl metric get proxy.node.cache.bytes_total
> proxy.node.cache.bytes_total 134012928
> # Take same disk offline again. Not good!
> $ sudo ./bin/traffic_ctl storage offline /dev/sdb
> $ ./bin/traffic_ctl metric get proxy.node.cache.bytes_total
> proxy.node.cache.bytes_total 0
> # Take same disk offline again. Negative value.
> $ sudo ./bin/traffic_ctl storage offline /dev/sdb
> $ ./bin/traffic_ctl metric get proxy.node.cache.bytes_total
> proxy.node.cache.bytes_total -134012928
> {code}



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

[jira] [Updated] (TS-4853) Parent Consistent Hash Selection - add parent selection URL and API.

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4853:
--
Assignee: John Rushford

> Parent Consistent Hash Selection - add parent selection URL and API.
> 
>
> Key: TS-4853
> URL: https://issues.apache.org/jira/browse/TS-4853
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Parent Proxy
>Reporter: Peter Chou
>Assignee: John Rushford
> Fix For: 7.1.0
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> Add the ability (via TS and Lua APIs) to set an explicit parent selection URL 
> that will be used for parent consistent hash selection hashing.



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

[jira] [Updated] (TS-4845) NULL dereference in url_sig

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4845:
--
Backport to Version: 6.2.1, 7.0.0

> NULL dereference in url_sig
> ---
>
> Key: TS-4845
> URL: https://issues.apache.org/jira/browse/TS-4845
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: James Peach
>Assignee: John Rushford
> Fix For: 7.1.0
>
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> Seen in the static analyzer:
> {noformat}
> Making all in url_sig
>   CC   url_sig.lo
> url_sig.c:564:38: warning: Null pointer argument in call to string length 
> function
>   app_qry = getAppQueryString(query, strlen(query));
>  ^
> 1 warning generated.
> {noformat}
> If there is no query string you can still do {{goto allow}}, but it looks 
> like the code assumes missing query string will always {{goto deny}}.



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

[jira] [Updated] (TS-4735) Possible deadlock on traffic_server startup

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4735:
--
Backport to Version: 7.0.0

> Possible deadlock on traffic_server startup
> ---
>
> Key: TS-4735
> URL: https://issues.apache.org/jira/browse/TS-4735
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 6.2.0
>Reporter: Shrihari
>Assignee: Shrihari
> Fix For: 7.1.0
>
>  Time Spent: 2h 50m
>  Remaining Estimate: 0h
>
> As part of startup, traffic_server creates two threads (to begin with).
> 1. (main) Thread (1) blocks till its signaled by another thread
> 1. Thread 2 polls for messages from traffic_manager
> It is waiting for a message from traffic_manager which contains all the 
> configuration required for it to go ahead with initialization. Hence, it is 
> critical that the main Thread (1) wait till it gets the configuration.
> Thread 2 which polls for message from traffic_manager works like this:
> {noformat}
> for(;;) {
>   if (pmgmt->require_lm) { <--- Always True (when using traffic_cop)
> pmgmt->pollLMConnection();  <--- | for (count = 0; count < 1; count 
> ++) 
>|   num = 
> mgmt_read_timeout(...) < Blocking call. returns 0 if nothing was received 
> for 1 second
>|   if !num: break 
> <--- Break out of the loop and return from function 
>|   else: 
> read(fd), add_to_event_queue, continue the loop, 
>| Back to fetching 
> another message
>   }
>   pmgmt->processEventQueue();  <--  Process the messages received in 
> pollLMConnection()
>   pmgmt->processSignalQueue();
>   mgmt_sleep_sec(pmgmt->timeout); 
> }
> {noformat}
> RCA:
> There are two problems here:
> 1. If we look into the above code, we should observe that the 
> pollLMConnection might not return back for a very long time if it keeps 
> getting messages. As a result, we may not call processEventQueue() which 
> processes the received messages. And unless we process the messages, we 
> cannot signal the main Thread (1) to continue, which is still blocked. Hence 
> we see the issue where traffic_server won't complete initialization for a 
> very long time.
> 2. The second problem is that why is traffic_server receiving so many 
> messages at boot-up? The problem lies in the configuration. In 6.2.x, we 
> replaced 
> 'proxy.process.ssl.total_success_handshake_count' with 
> 'proxy.process.ssl.total_success_handshake_count_in'. 
> In order to provide backwards compatibility, we defined the old stat in 
> stats.config.xml. The caveat here is that, since this statconfig is defined 
> in stats.config.xml, traffic_manager assumes the responsibility of updating 
> this stat. According to the code:
> {noformat}
> if (i_am_not_owner_of(stat)) : send traffic_server a notify message.
> {noformat}
> Ideally, this code should not be triggered because, traffic_manager does own 
> the stat. However, the ownership in the code is determined solely based on 
> the 'string name'. If the name contains 'process', it is owned by 
> traffic_server. This leads to an interesting scenario where traffic_manger 
> keeps updating its own stat and sends unnecessary events to traffic_server. 
> These updates happen every 1 second (Thanks James for helping me understand 
> this period) which is the same as our timeout in traffic_server.  Due to 
> 'Problem 1' we can prevent traffic_server from processing any messages for up 
> to 10,000 seconds! (Just imagine the case where the message is received just 
> before the timout of 1 second happens)
> I saw this happening with 100% on a VM but 0% on a physical box. I don't have 
> any other results as of now though.



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

[jira] [Updated] (TS-4705) Proposal: NetVC Context

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4705:
--
Backport to Version: 7.0.0

> Proposal: NetVC Context
> ---
>
> Key: TS-4705
> URL: https://issues.apache.org/jira/browse/TS-4705
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: Oknet Xu
>Assignee: Oknet Xu
> Fix For: 7.1.0
>
>  Time Spent: 3h 40m
>  Remaining Estimate: 0h
>
> Goal 1st:
> In the NetVConnection, we have get_local_addr() and get_remote_addr() methods.
> Also have members local_addr, remote_addr and netvc->con.addr.
> Thus, we should using netvc->con.addr or remote_addr to replace member 
> server_addr in UnixNetVConnection.
> Goal 2nd:
> SSLNetVConnection has member sslClientConnection with 2 methods 
> setSSLClientConnection() and getSSLClientConnection() to indictor ATS is a 
> client or server in a SSL session.
> To abstract above two goals, I'm design the netvc context function.
> As a proxy, there has two side: client side ( Client <-> Proxy ) and server 
> side ( Proxy <-> Server ). With the netvc context funtion to indicate which 
> side the NetVC working on.
> Goal 3rd:
> Fix a minor bug in NetAccept::do_blocking_accept, call to 
> check_emergency_throttle(con) first then allocate vc.
> Goal 4th:
> NetAccept Optimize, remove dup code, etc...



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

[jira] [Updated] (TS-4626) LogFile::close_file should not delete m_log handle

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4626:
--
Backport to Version: 6.2.1, 7.0.0

> LogFile::close_file should not delete m_log handle
> --
>
> Key: TS-4626
> URL: https://issues.apache.org/jira/browse/TS-4626
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Michael Chai
>Assignee: Daniel Xu
> Fix For: 7.1.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> When log file was deleted on the disk, LogFile::check_fd will close file 
> handle and reopen again.delete m_log at this point will cause 
> LogFile::open_file return "LOG_FILE_COULD_NOT_OPEN_FILE" .  otherwise, will 
> cause trafficserver crash at LogFile::preproc_and_try_delete
> 300 if (!m_log->m_start_time) {
> (gdb) bt
> #0  0x0068245f in LogFile::preproc_and_try_delete (this=0x1132eb0, 
> lb=0x7fffdc000da0) at LogFile.cc:300
> #1  0x0068caa6 in LogBufferManager::preproc_buffers (this=0x1132970, 
> sink=0x1132eb0) at LogObject.cc:77
> #2  0x00691a53 in LogObject::preproc_buffers (this=0x1132ae0, idx=0) 
> at LogObject.h:146
> #3  0x006901c3 in LogObjectManager::preproc_buffers (this=0x1127228, 
> idx=0) at LogObject.cc:1126
> #4  0x0066b668 in Log::preproc_thread_main (args=0x1131edc) at 
> Log.cc:1168
> #5  0x0066ce9d in LoggingPreprocContinuation::mainEvent 
> (this=0x1131ea0) at Log.cc:279
> #6  0x0050d662 in Continuation::handleEvent (this=0x1131ea0, event=1, 
> data=0x11529a0) at ../iocore/eventsystem/I_Continuation.h:153
> #7  0x007a1e9f in EThread::execute (this=0x707a1010) at 
> UnixEThread.cc:298
> #8  0x007a0d0c in spawn_thread_internal (a=0x1131ef0) at Thread.cc:84
> #9  0x764740a4 in start_thread (arg=0x707a0700) at 
> pthread_create.c:309
> #10 0x7541c04d in clone () at 
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
> (gdb) p m_log
> $1 = (BaseLogFile *) 0x0



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

[jira] [Updated] (TS-4612) Proposal: InactivityCop Optimize

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4612:
--
Backport to Version: 7.0.0

> Proposal: InactivityCop Optimize
> 
>
> Key: TS-4612
> URL: https://issues.apache.org/jira/browse/TS-4612
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core, Network
>Reporter: Oknet Xu
>Assignee: Oknet Xu
> Fix For: 7.1.0
>
>  Time Spent: 5h 50m
>  Remaining Estimate: 0h
>
> By review the processing of InactivityCop::check_inactivity():
> 1. get all local vc from open_list
> 2. put them into cop_list
> 3. check every vc in cop_list if it is already timeouted
> 4. callback vc->handleEvent to close vc if it is timeout
> InactivityCop and NetHandler share one mutex.
> InactivityCop runs every second, NetHandler runs every 10ms, that means 
> Nethandler runs 100 times until next InactivityCop runs.
> if one vc has read/write in a Nethandler call, it is won't be timeout in the 
> next InactivityCop run.
> Thus, if the vc has read/write in Nethandler, we move it out of cop-list then 
> the InactivityCop runs would get better performace.



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

[jira] [Updated] (TS-4558) ASAN buffer overflow in traffic_manager -h

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4558:
--
Backport to Version: 7.0.0

> ASAN buffer overflow in traffic_manager -h
> --
>
> Key: TS-4558
> URL: https://issues.apache.org/jira/browse/TS-4558
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Manager
>Reporter: Leif Hedstrom
>Assignee: Steven Feltner
>  Labels: ASAN
> Fix For: 7.1.0
>
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> {code}
> [root@qa1 ats]# ./bin/traffic_manager  -h
> Usage: traffic_manager [--SWITCH [ARG]]
>   switch__type__default___description
>   --proxyOff  on   
> =
> ==14425==ERROR: AddressSanitizer: global-buffer-overflow on address 
> 0x0089fd40 at pc 0x7fd0aef80b5e bp 0x7ffe0d210590 sp 0x7ffe0d210588
> READ of size 4 at 0x0089fd40 thread T0
> #0 0x7fd0aef80b5d in usage(ArgumentDescription const*, unsigned int, char 
> const*) /usr/local/src/trafficserver/lib/ts/ink_args.cc:323
> #1 0x7fd0aef7f5c7 in process_arg 
> /usr/local/src/trafficserver/lib/ts/ink_args.cc:122
> #2 0x7fd0aef80135 in process_args_ex(AppVersionInfo const*, 
> ArgumentDescription const*, unsigned int, char const**) 
> /usr/local/src/trafficserver/lib/ts/ink_args.cc:237
> #3 0x7fd0aef80bba in process_args(AppVersionInfo const*, 
> ArgumentDescription const*, unsigned int, char const**, char const*) 
> /usr/local/src/trafficserver/lib/ts/ink_args.cc:166
> #4 0x4305a4 in main 
> /usr/local/src/trafficserver/cmd/traffic_manager/traffic_manager.cc:481
> #5 0x7fd0abbfdb14 in __libc_start_main (/lib64/libc.so.6+0x21b14)
> #6 0x4343e4  (/opt/ats/bin/traffic_manager+0x4343e4)
> 0x0089fd41 is located 0 bytes to the right of global variable 'proxy_off' 
> defined in 'traffic_manager.cc:86:13' (0x89fd40) of size 1
>   'proxy_off' is ascii string ''
> SUMMARY: AddressSanitizer: global-buffer-overflow 
> /usr/local/src/trafficserver/lib/ts/ink_args.cc:323 usage(ArgumentDescription 
> const*, unsigned int, char const*)
> Shadow bytes around the buggy address:
>   0x8010bf50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x8010bf60: f9 f9 f9 f9 00 00 00 00 00 00 00 00 00 00 00 00
>   0x8010bf70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x8010bf80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x8010bf90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> =>0x8010bfa0: 00 00 00 00 f9 f9 f9 f9[01]f9 f9 f9 f9 f9 f9 f9
>   0x8010bfb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x8010bfc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x8010bfd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x8010bfe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x8010bff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> Shadow byte legend (one shadow byte represents 8 application bytes):
>   Addressable:   00
>   Partially addressable: 01 02 03 04 05 06 07
>   Heap left redzone:   fa
>   Heap right redzone:  fb
>   Freed heap region:   fd
>   Stack left redzone:  f1
>   Stack mid redzone:   f2
>   Stack right redzone: f3
>   Stack partial redzone:   f4
>   Stack after return:  f5
>   Stack use after scope:   f8
>   Global redzone:  f9
>   Global init order:   f6
>   Poisoned by user:f7
>   Container overflow:  fc
>   Array cookie:ac
>   Intra object redzone:bb
>   ASan internal:   fe
> ==14425==ABORTING
> {code}



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

[jira] [Updated] (TS-4539) The mutex of server_vc is not set while server_session reuse

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4539:
--
Fix Version/s: (was: 7.1.0)

> The mutex of server_vc is not set while server_session reuse
> 
>
> Key: TS-4539
> URL: https://issues.apache.org/jira/browse/TS-4539
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: Oknet Xu
>Assignee: Oknet Xu
>
> NetAccept got a client_vc and call new_ProxyMutex() to assign a mutex.
> And the HttpClientSession, HttpSM, HttpServerSession, server_vc also share 
> the same mutex.
> The HttpServerSession and server_vc will put into ServerSessionPool and may 
> assign to next new client_vc.
> The HttpSM::attach_server_session() only set the mutex of HttpServerSession 
> to the mutex of HttpSM after get a HttpServerSession from ServerSessionPool.
> But it forget to set the mutex of server_vc to the mutex of HttpSM.
>  
> {code}
> void
> HttpSM::attach_server_session(HttpServerSession *s)
> {
>   hsm_release_assert(server_session == NULL);
>   hsm_release_assert(server_entry == NULL);
>   hsm_release_assert(s->state == HSS_ACTIVE);
>   server_session = s; 
>   server_session->transact_count++;
>   // Set the mutex so that we have something to update
>   //   stats with
>   server_session->mutex = this->mutex;
> {code}
> But I can not found any issue, Is it by design?
> Or it is hard to locate the problem, due to my limited knowedge on HttpSM.



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

[jira] [Updated] (TS-4218) Intermittent HTTP/2 failure with h2spec (8.1.)

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4218:
--
Fix Version/s: (was: 7.1.0)

> Intermittent HTTP/2 failure with h2spec (8.1.)
> --
>
> Key: TS-4218
> URL: https://issues.apache.org/jira/browse/TS-4218
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Masaori Koshiba
>Assignee: Masaori Koshiba
>
> Sometimes I see a test for {{8.1. HTTP Request/Response Exchange}} in h2spec 
> is failed.
> - h2spec : v1.3.1
> - ATS master (9c707a89d58f0b635cc3c2070025ba08161beec0)
> {noformat}
>   8.1. HTTP Request/Response Exchange
> × Sends a second HEADERS frame without the END_STREAM flag
>   - The endpoint MUST respond with a stream error of type PROTOCOL_ERROR.
> Expected: GOAWAY frame (ErrorCode: PROTOCOL_ERROR)
>   RST_STREAM frame (ErrorCode: PROTOCOL_ERROR)
>   Connection close
>   Actual: RST_STREAM frame (Length: 4, Flags: 0, ErrorCode: 
> STREAM_CLOSED)
> {noformat}



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

[jira] [Updated] (TS-4072) Diagnostic log rolling races

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4072:
--
Backport to Version: 6.2.1, 7.0.0  (was: 6.2.1)

> Diagnostic log rolling races
> 
>
> Key: TS-4072
> URL: https://issues.apache.org/jira/browse/TS-4072
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Reporter: James Peach
>Assignee: Alan M. Carroll
> Fix For: 7.1.0
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> When diagnostic logs are rolled, {{Diags::diags_log}} is deleted and replaced 
> with a new log object. Since the global {{diags}} points to a a single 
> {{Diags}} object there is nothing to prevent a different thread logging 
> through this object at the time it is deleted.



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

[jira] [Work logged] (TS-4938) Crash due to null client_vc

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4938?focusedWorklogId=30270=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30270
 ]

ASF GitHub Bot logged work on TS-4938:
--

Author: ASF GitHub Bot
Created on: 07/Oct/16 17:30
Start Date: 07/Oct/16 17:30
Worklog Time Spent: 10m 
  Work Description: Github user bryancall commented on the issue:

https://github.com/apache/trafficserver/pull/1083
  
Why do we have to guard against the server_session server_vc being NULL 
now?  What change occurred to require this or was it always possible?


Issue Time Tracking
---

Worklog Id: (was: 30270)
Time Spent: 1h 10m  (was: 1h)

> Crash due to null client_vc
> ---
>
> Key: TS-4938
> URL: https://issues.apache.org/jira/browse/TS-4938
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 7.1.0
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> Saw this crash while testing fix for TS-4813.  Have a fix that checks 
> get_netvc() returns a non-NULL.  Should make a more comprehensive review on 
> the use of get_netvc() in HttpTransact.cc/HttpSM.cc
> {code}
> #0  0x0053ed2c in NetVConnection::get_local_addr (this=0x0) at 
> ../iocore/net/P_NetVConnection.h:60
> #1  0x0057dca4 in NetVConnection::get_local_port (this=0x0) at 
> ../iocore/net/P_NetVConnection.h:82
> #2  0x00627844 in 
> HttpTransact::initialize_state_variables_from_request (s=0x2b65700d4a98, 
> obsolete_incoming_request=0x2b65700d51b8)
> at HttpTransact.cc:5709
> #3  0x00632bd1 in HttpTransact::build_error_response 
> (s=0x2b65700d4a98, status_code=HTTP_STATUS_BAD_GATEWAY, 
> reason_phrase_or_null=0x7fb86c "Server Hangup", error_body_type=0x7fb87a 
> "connect#hangup", format=0x0) at HttpTransact.cc:8141
> #4  0x006311fa in HttpTransact::handle_server_died (s=0x2b65700d4a98) 
> at HttpTransact.cc:7789
> #5  0x00620bbc in HttpTransact::handle_server_connection_not_open 
> (s=0x2b65700d4a98) at HttpTransact.cc:3991
> #6  0x0061fd43 in HttpTransact::handle_response_from_server 
> (s=0x2b65700d4a98) at HttpTransact.cc:3824
> #7  0x0061d762 in HttpTransact::HandleResponse (s=0x2b65700d4a98) at 
> HttpTransact.cc:3401
> #8  0x005fc928 in HttpSM::call_transact_and_set_next_state 
> (this=0x2b65700d4a20, 
> f=0x61cf9a ) at 
> HttpSM.cc:7116
> #9  0x005f6902 in HttpSM::handle_server_setup_error 
> (this=0x2b65700d4a20, event=104, data=0x2aabd00372d8) at HttpSM.cc:5505
> #10 0x005e88a4 in HttpSM::state_send_server_request_header 
> (this=0x2b65700d4a20, event=104, data=0x2aabd00372d8) at HttpSM.cc:2053
> #11 0x005eb3ba in HttpSM::main_handler (this=0x2b65700d4a20, 
> event=104, data=0x2aabd00372d8) at HttpSM.cc:2655
> #12 0x005145ac in Continuation::handleEvent (this=0x2b65700d4a20, 
> event=104, data=0x2aabd00372d8) at ../iocore/eventsystem/I_Continuation.h:153
> #13 0x0079906f in write_signal_and_update (event=104, 
> vc=0x2aabd0037140) at UnixNetVConnection.cc:174
> #14 0x007992a6 in write_signal_done (event=104, nh=0x2b64f71b4cf0, 
> vc=0x2aabd0037140) at UnixNetVConnection.cc:216
> #15 0x0079a475 in write_to_net_io (nh=0x2b64f71b4cf0, 
> vc=0x2aabd0037140, thread=0x2b64f71b1010) at UnixNetVConnection.cc:547
> #16 0x00799dc7 in write_to_net (nh=0x2b64f71b4cf0, vc=0x2aabd0037140, 
> thread=0x2b64f71b1010) at UnixNetVConnection.cc:414
> #17 0x0079129d in NetHandler::mainNetEvent (this=0x2b64f71b4cf0, 
> event=5, e=0x1646ac0) at UnixNet.cc:515
> #18 0x005145ac in Continuation::handleEvent (this=0x2b64f71b4cf0, 
> event=5, data=0x1646ac0) at ../iocore/eventsystem/I_Continuation.h:153
> #19 0x007bc90a in EThread::process_event (this=0x2b64f71b1010, 
> e=0x1646ac0, calling_code=5) at UnixEThread.cc:143
> #20 0x007bcf0d in EThread::execute (this=0x2b64f71b1010) at 
> UnixEThread.cc:270
> #21 0x007bbf1e in spawn_thread_internal (a=0x15731f0) at Thread.cc:84
> #22 0x2b64f5fcfaa1 in start_thread () from /lib64/libpthread.so.0
> #23 0x0032310e893d in clone () from /lib64/libc.so.6
> {code}



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

[GitHub] trafficserver issue #1083: TS-4938: Avoid crashes due to NULL vc dereference...

[bryancall]

Github user bryancall commented on the issue:

https://github.com/apache/trafficserver/pull/1083
  
Why do we have to guard against the server_session server_vc being NULL 
now?  What change occurred to require this or was it always possible?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4920) Consolidate accept socket options

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4920?focusedWorklogId=30268=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30268
 ]

ASF GitHub Bot logged work on TS-4920:
--

Author: ASF GitHub Bot
Created on: 07/Oct/16 17:06
Start Date: 07/Oct/16 17:06
Worklog Time Spent: 10m 
  Work Description: Github user jpeach commented on the issue:

https://github.com/apache/trafficserver/pull/1068
  
Ping @bryancall @amc?


Issue Time Tracking
---

Worklog Id: (was: 30268)
Time Spent: 40m  (was: 0.5h)

> Consolidate accept socket options
> -
>
> Key: TS-4920
> URL: https://issues.apache.org/jira/browse/TS-4920
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.1.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> We have an object {{AcceptOptions}} that contains the options to apply to 
> listening sockets, but in many places, the individual options are passed 
> around. Consolidate this so that we pass a {{AcceptOptions}} to provide 
> better guarantees that all listening sockets are created equal.



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

[GitHub] trafficserver issue #1068: TS-4920: Consolidate accept socket options.

[jpeach]

Github user jpeach commented on the issue:

https://github.com/apache/trafficserver/pull/1068
  
Ping @bryancall @amc?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] trafficserver pull request #769: TS 4593: Extend ip_allow.config to filter d...

[SolidWallOfCode]

Github user SolidWallOfCode commented on a diff in the pull request:

https://github.com/apache/trafficserver/pull/769#discussion_r82413900
  
--- Diff: proxy/http/remap/RemapConfig.cc ---
@@ -123,6 +124,9 @@ process_filter_opt(url_mapping *mp, const 
BUILD_TABLE_INFO *bti, char *errStrBuf
 }
 errStr = remap_validate_filter_args(rpp, (const char **)bti->argv, 
bti->argc, errStrBuf, errStrBufSize);
   }
+  // Copy ip_allow_flag to url_mapping
--- End diff --

"Set the ip allow flag for this rule to the current ip allow flag state"


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] trafficserver pull request #1083: TS-4938: Avoid crashes due to NULL vc dere...

[jpeach]

Github user jpeach commented on a diff in the pull request:

https://github.com/apache/trafficserver/pull/1083#discussion_r82417079
  
--- Diff: proxy/http/HttpServerSession.h ---
@@ -136,6 +136,19 @@ class HttpServerSession : public VConnection
 ink_release_assert(server_vc != NULL);
 return server_vc->get_remote_endpoint();
   }
+
+  void
+  set_active_timeout(ink_hrtime timeout_in)
+  {
+if (server_vc)
+  server_vc->set_active_timeout(timeout_in);
+  }
--- End diff --

Please add a newline to separate functions.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] trafficserver pull request #1083: TS-4938: Avoid crashes due to NULL vc dere...

[jpeach]

Github user jpeach commented on a diff in the pull request:

https://github.com/apache/trafficserver/pull/1083#discussion_r82416759
  
--- Diff: proxy/http/HttpSM.cc ---
@@ -5841,7 +5843,9 @@ HttpSM::attach_server_session(HttpServerSession *s)
   UnixNetVConnection *server_vc = dynamic_cast(server_session->get_netvc());
   UnixNetVConnection *client_vc = (UnixNetVConnection 
*)(ua_session->get_netvc());
   SSLNetVConnection *ssl_vc = dynamic_cast(client_vc);
-  bool associated_connection= false;
+
+  ink_release_assert(!server_vc || !client_vc || server_vc->thread == 
client_vc->thread);
--- End diff --

Can you please add a comment to document the invariant this is enforcing?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4938) Crash due to null client_vc

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4938?focusedWorklogId=30263=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30263
 ]

ASF GitHub Bot logged work on TS-4938:
--

Author: ASF GitHub Bot
Created on: 07/Oct/16 16:01
Start Date: 07/Oct/16 16:01
Worklog Time Spent: 10m 
  Work Description: Github user jpeach commented on a diff in the pull 
request:

https://github.com/apache/trafficserver/pull/1083#discussion_r82417120
  
--- Diff: proxy/http/HttpServerSession.h ---
@@ -136,6 +136,19 @@ class HttpServerSession : public VConnection
 ink_release_assert(server_vc != NULL);
 return server_vc->get_remote_endpoint();
   }
+
+  void
+  set_active_timeout(ink_hrtime timeout_in)
+  {
+if (server_vc)
+  server_vc->set_active_timeout(timeout_in);
+  }
+  void
+  set_inactivity_timeout(ink_hrtime timeout_in)
+  {
+if (server_vc)
+  server_vc->set_inactivity_timeout(timeout_in);
+  }
--- End diff --

Newline please.


Issue Time Tracking
---

Worklog Id: (was: 30263)
Time Spent: 1h  (was: 50m)

> Crash due to null client_vc
> ---
>
> Key: TS-4938
> URL: https://issues.apache.org/jira/browse/TS-4938
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 7.1.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> Saw this crash while testing fix for TS-4813.  Have a fix that checks 
> get_netvc() returns a non-NULL.  Should make a more comprehensive review on 
> the use of get_netvc() in HttpTransact.cc/HttpSM.cc
> {code}
> #0  0x0053ed2c in NetVConnection::get_local_addr (this=0x0) at 
> ../iocore/net/P_NetVConnection.h:60
> #1  0x0057dca4 in NetVConnection::get_local_port (this=0x0) at 
> ../iocore/net/P_NetVConnection.h:82
> #2  0x00627844 in 
> HttpTransact::initialize_state_variables_from_request (s=0x2b65700d4a98, 
> obsolete_incoming_request=0x2b65700d51b8)
> at HttpTransact.cc:5709
> #3  0x00632bd1 in HttpTransact::build_error_response 
> (s=0x2b65700d4a98, status_code=HTTP_STATUS_BAD_GATEWAY, 
> reason_phrase_or_null=0x7fb86c "Server Hangup", error_body_type=0x7fb87a 
> "connect#hangup", format=0x0) at HttpTransact.cc:8141
> #4  0x006311fa in HttpTransact::handle_server_died (s=0x2b65700d4a98) 
> at HttpTransact.cc:7789
> #5  0x00620bbc in HttpTransact::handle_server_connection_not_open 
> (s=0x2b65700d4a98) at HttpTransact.cc:3991
> #6  0x0061fd43 in HttpTransact::handle_response_from_server 
> (s=0x2b65700d4a98) at HttpTransact.cc:3824
> #7  0x0061d762 in HttpTransact::HandleResponse (s=0x2b65700d4a98) at 
> HttpTransact.cc:3401
> #8  0x005fc928 in HttpSM::call_transact_and_set_next_state 
> (this=0x2b65700d4a20, 
> f=0x61cf9a ) at 
> HttpSM.cc:7116
> #9  0x005f6902 in HttpSM::handle_server_setup_error 
> (this=0x2b65700d4a20, event=104, data=0x2aabd00372d8) at HttpSM.cc:5505
> #10 0x005e88a4 in HttpSM::state_send_server_request_header 
> (this=0x2b65700d4a20, event=104, data=0x2aabd00372d8) at HttpSM.cc:2053
> #11 0x005eb3ba in HttpSM::main_handler (this=0x2b65700d4a20, 
> event=104, data=0x2aabd00372d8) at HttpSM.cc:2655
> #12 0x005145ac in Continuation::handleEvent (this=0x2b65700d4a20, 
> event=104, data=0x2aabd00372d8) at ../iocore/eventsystem/I_Continuation.h:153
> #13 0x0079906f in write_signal_and_update (event=104, 
> vc=0x2aabd0037140) at UnixNetVConnection.cc:174
> #14 0x007992a6 in write_signal_done (event=104, nh=0x2b64f71b4cf0, 
> vc=0x2aabd0037140) at UnixNetVConnection.cc:216
> #15 0x0079a475 in write_to_net_io (nh=0x2b64f71b4cf0, 
> vc=0x2aabd0037140, thread=0x2b64f71b1010) at UnixNetVConnection.cc:547
> #16 0x00799dc7 in write_to_net (nh=0x2b64f71b4cf0, vc=0x2aabd0037140, 
> thread=0x2b64f71b1010) at UnixNetVConnection.cc:414
> #17 0x0079129d in NetHandler::mainNetEvent (this=0x2b64f71b4cf0, 
> event=5, e=0x1646ac0) at UnixNet.cc:515
> #18 0x005145ac in Continuation::handleEvent (this=0x2b64f71b4cf0, 
> event=5, data=0x1646ac0) at ../iocore/eventsystem/I_Continuation.h:153
> #19 0x007bc90a in EThread::process_event (this=0x2b64f71b1010, 
> e=0x1646ac0, calling_code=5) at UnixEThread.cc:143
> #20 0x007bcf0d in EThread::execute (this=0x2b64f71b1010) at 
> UnixEThread.cc:270
> #21 0x007bbf1e in spawn_thread_internal (a=0x15731f0) at Thread.cc:84
> #22 0x2b64f5fcfaa1 in start_thread () from /lib64/libpthread.so.0
> #23 0x0032310e893d in clone () from /lib64/libc.so.6
> {code}



--
This message was 

[jira] [Work logged] (TS-4938) Crash due to null client_vc

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4938?focusedWorklogId=30265=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30265
 ]

ASF GitHub Bot logged work on TS-4938:
--

Author: ASF GitHub Bot
Created on: 07/Oct/16 16:01
Start Date: 07/Oct/16 16:01
Worklog Time Spent: 10m 
  Work Description: Github user jpeach commented on a diff in the pull 
request:

https://github.com/apache/trafficserver/pull/1083#discussion_r82417601
  
--- Diff: proxy/http/HttpTransact.cc ---
@@ -5795,11 +5799,8 @@ 
HttpTransact::initialize_state_variables_from_request(State *s, HTTPHdr *obsolet
   s->request_data.hostname_str = s->arena.str_store(host_name, host_len);
   ats_ip_copy(>request_data.src_ip, >client_info.src_addr);
   memset(>request_data.dest_ip, 0, sizeof(s->request_data.dest_ip));
-  if (s->state_machine->ua_session) {
-NetVConnection *netvc = s->state_machine->ua_session->get_netvc();
-if (netvc) {
-  s->request_data.incoming_port = netvc->get_local_port();
-}
+  if (s->state_machine->ua_session && vc) {
--- End diff --

If ``vc`` is  not NULL then ``ua_session`` is also not NULL, so checking 
``vc`` should be sufficient. Same for the previous check.


Issue Time Tracking
---

Worklog Id: (was: 30265)
Time Spent: 1h  (was: 50m)

> Crash due to null client_vc
> ---
>
> Key: TS-4938
> URL: https://issues.apache.org/jira/browse/TS-4938
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 7.1.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> Saw this crash while testing fix for TS-4813.  Have a fix that checks 
> get_netvc() returns a non-NULL.  Should make a more comprehensive review on 
> the use of get_netvc() in HttpTransact.cc/HttpSM.cc
> {code}
> #0  0x0053ed2c in NetVConnection::get_local_addr (this=0x0) at 
> ../iocore/net/P_NetVConnection.h:60
> #1  0x0057dca4 in NetVConnection::get_local_port (this=0x0) at 
> ../iocore/net/P_NetVConnection.h:82
> #2  0x00627844 in 
> HttpTransact::initialize_state_variables_from_request (s=0x2b65700d4a98, 
> obsolete_incoming_request=0x2b65700d51b8)
> at HttpTransact.cc:5709
> #3  0x00632bd1 in HttpTransact::build_error_response 
> (s=0x2b65700d4a98, status_code=HTTP_STATUS_BAD_GATEWAY, 
> reason_phrase_or_null=0x7fb86c "Server Hangup", error_body_type=0x7fb87a 
> "connect#hangup", format=0x0) at HttpTransact.cc:8141
> #4  0x006311fa in HttpTransact::handle_server_died (s=0x2b65700d4a98) 
> at HttpTransact.cc:7789
> #5  0x00620bbc in HttpTransact::handle_server_connection_not_open 
> (s=0x2b65700d4a98) at HttpTransact.cc:3991
> #6  0x0061fd43 in HttpTransact::handle_response_from_server 
> (s=0x2b65700d4a98) at HttpTransact.cc:3824
> #7  0x0061d762 in HttpTransact::HandleResponse (s=0x2b65700d4a98) at 
> HttpTransact.cc:3401
> #8  0x005fc928 in HttpSM::call_transact_and_set_next_state 
> (this=0x2b65700d4a20, 
> f=0x61cf9a ) at 
> HttpSM.cc:7116
> #9  0x005f6902 in HttpSM::handle_server_setup_error 
> (this=0x2b65700d4a20, event=104, data=0x2aabd00372d8) at HttpSM.cc:5505
> #10 0x005e88a4 in HttpSM::state_send_server_request_header 
> (this=0x2b65700d4a20, event=104, data=0x2aabd00372d8) at HttpSM.cc:2053
> #11 0x005eb3ba in HttpSM::main_handler (this=0x2b65700d4a20, 
> event=104, data=0x2aabd00372d8) at HttpSM.cc:2655
> #12 0x005145ac in Continuation::handleEvent (this=0x2b65700d4a20, 
> event=104, data=0x2aabd00372d8) at ../iocore/eventsystem/I_Continuation.h:153
> #13 0x0079906f in write_signal_and_update (event=104, 
> vc=0x2aabd0037140) at UnixNetVConnection.cc:174
> #14 0x007992a6 in write_signal_done (event=104, nh=0x2b64f71b4cf0, 
> vc=0x2aabd0037140) at UnixNetVConnection.cc:216
> #15 0x0079a475 in write_to_net_io (nh=0x2b64f71b4cf0, 
> vc=0x2aabd0037140, thread=0x2b64f71b1010) at UnixNetVConnection.cc:547
> #16 0x00799dc7 in write_to_net (nh=0x2b64f71b4cf0, vc=0x2aabd0037140, 
> thread=0x2b64f71b1010) at UnixNetVConnection.cc:414
> #17 0x0079129d in NetHandler::mainNetEvent (this=0x2b64f71b4cf0, 
> event=5, e=0x1646ac0) at UnixNet.cc:515
> #18 0x005145ac in Continuation::handleEvent (this=0x2b64f71b4cf0, 
> event=5, data=0x1646ac0) at ../iocore/eventsystem/I_Continuation.h:153
> #19 0x007bc90a in EThread::process_event (this=0x2b64f71b1010, 
> e=0x1646ac0, calling_code=5) at UnixEThread.cc:143
> #20 0x007bcf0d in EThread::execute (this=0x2b64f71b1010) at 
> UnixEThread.cc:270
> #21 0x007bbf1e in 

[jira] [Work logged] (TS-4938) Crash due to null client_vc

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4938?focusedWorklogId=30262=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30262
 ]

ASF GitHub Bot logged work on TS-4938:
--

Author: ASF GitHub Bot
Created on: 07/Oct/16 16:01
Start Date: 07/Oct/16 16:01
Worklog Time Spent: 10m 
  Work Description: Github user jpeach commented on a diff in the pull 
request:

https://github.com/apache/trafficserver/pull/1083#discussion_r82417079
  
--- Diff: proxy/http/HttpServerSession.h ---
@@ -136,6 +136,19 @@ class HttpServerSession : public VConnection
 ink_release_assert(server_vc != NULL);
 return server_vc->get_remote_endpoint();
   }
+
+  void
+  set_active_timeout(ink_hrtime timeout_in)
+  {
+if (server_vc)
+  server_vc->set_active_timeout(timeout_in);
+  }
--- End diff --

Please add a newline to separate functions.


Issue Time Tracking
---

Worklog Id: (was: 30262)
Time Spent: 1h  (was: 50m)

> Crash due to null client_vc
> ---
>
> Key: TS-4938
> URL: https://issues.apache.org/jira/browse/TS-4938
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 7.1.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> Saw this crash while testing fix for TS-4813.  Have a fix that checks 
> get_netvc() returns a non-NULL.  Should make a more comprehensive review on 
> the use of get_netvc() in HttpTransact.cc/HttpSM.cc
> {code}
> #0  0x0053ed2c in NetVConnection::get_local_addr (this=0x0) at 
> ../iocore/net/P_NetVConnection.h:60
> #1  0x0057dca4 in NetVConnection::get_local_port (this=0x0) at 
> ../iocore/net/P_NetVConnection.h:82
> #2  0x00627844 in 
> HttpTransact::initialize_state_variables_from_request (s=0x2b65700d4a98, 
> obsolete_incoming_request=0x2b65700d51b8)
> at HttpTransact.cc:5709
> #3  0x00632bd1 in HttpTransact::build_error_response 
> (s=0x2b65700d4a98, status_code=HTTP_STATUS_BAD_GATEWAY, 
> reason_phrase_or_null=0x7fb86c "Server Hangup", error_body_type=0x7fb87a 
> "connect#hangup", format=0x0) at HttpTransact.cc:8141
> #4  0x006311fa in HttpTransact::handle_server_died (s=0x2b65700d4a98) 
> at HttpTransact.cc:7789
> #5  0x00620bbc in HttpTransact::handle_server_connection_not_open 
> (s=0x2b65700d4a98) at HttpTransact.cc:3991
> #6  0x0061fd43 in HttpTransact::handle_response_from_server 
> (s=0x2b65700d4a98) at HttpTransact.cc:3824
> #7  0x0061d762 in HttpTransact::HandleResponse (s=0x2b65700d4a98) at 
> HttpTransact.cc:3401
> #8  0x005fc928 in HttpSM::call_transact_and_set_next_state 
> (this=0x2b65700d4a20, 
> f=0x61cf9a ) at 
> HttpSM.cc:7116
> #9  0x005f6902 in HttpSM::handle_server_setup_error 
> (this=0x2b65700d4a20, event=104, data=0x2aabd00372d8) at HttpSM.cc:5505
> #10 0x005e88a4 in HttpSM::state_send_server_request_header 
> (this=0x2b65700d4a20, event=104, data=0x2aabd00372d8) at HttpSM.cc:2053
> #11 0x005eb3ba in HttpSM::main_handler (this=0x2b65700d4a20, 
> event=104, data=0x2aabd00372d8) at HttpSM.cc:2655
> #12 0x005145ac in Continuation::handleEvent (this=0x2b65700d4a20, 
> event=104, data=0x2aabd00372d8) at ../iocore/eventsystem/I_Continuation.h:153
> #13 0x0079906f in write_signal_and_update (event=104, 
> vc=0x2aabd0037140) at UnixNetVConnection.cc:174
> #14 0x007992a6 in write_signal_done (event=104, nh=0x2b64f71b4cf0, 
> vc=0x2aabd0037140) at UnixNetVConnection.cc:216
> #15 0x0079a475 in write_to_net_io (nh=0x2b64f71b4cf0, 
> vc=0x2aabd0037140, thread=0x2b64f71b1010) at UnixNetVConnection.cc:547
> #16 0x00799dc7 in write_to_net (nh=0x2b64f71b4cf0, vc=0x2aabd0037140, 
> thread=0x2b64f71b1010) at UnixNetVConnection.cc:414
> #17 0x0079129d in NetHandler::mainNetEvent (this=0x2b64f71b4cf0, 
> event=5, e=0x1646ac0) at UnixNet.cc:515
> #18 0x005145ac in Continuation::handleEvent (this=0x2b64f71b4cf0, 
> event=5, data=0x1646ac0) at ../iocore/eventsystem/I_Continuation.h:153
> #19 0x007bc90a in EThread::process_event (this=0x2b64f71b1010, 
> e=0x1646ac0, calling_code=5) at UnixEThread.cc:143
> #20 0x007bcf0d in EThread::execute (this=0x2b64f71b1010) at 
> UnixEThread.cc:270
> #21 0x007bbf1e in spawn_thread_internal (a=0x15731f0) at Thread.cc:84
> #22 0x2b64f5fcfaa1 in start_thread () from /lib64/libpthread.so.0
> #23 0x0032310e893d in clone () from /lib64/libc.so.6
> {code}



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

[jira] [Work logged] (TS-4938) Crash due to null client_vc

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4938?focusedWorklogId=30261=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30261
 ]

ASF GitHub Bot logged work on TS-4938:
--

Author: ASF GitHub Bot
Created on: 07/Oct/16 16:01
Start Date: 07/Oct/16 16:01
Worklog Time Spent: 10m 
  Work Description: Github user jpeach commented on a diff in the pull 
request:

https://github.com/apache/trafficserver/pull/1083#discussion_r82417247
  
--- Diff: proxy/http/HttpTransact.cc ---
@@ -568,7 +568,10 @@ HttpTransact::BadRequest(State *s)
 void
 HttpTransact::HandleBlindTunnel(State *s)
 {
-  bool inbound_transparent_p = 
s->state_machine->ua_session->get_netvc()->get_is_transparent();
+  NetVConnection *vc = s->state_machine->ua_session->get_netvc();
+  if (!vc)
+return;
--- End diff --

Can this really happen? If it does, what does that mean?


Issue Time Tracking
---

Worklog Id: (was: 30261)
Time Spent: 1h  (was: 50m)

> Crash due to null client_vc
> ---
>
> Key: TS-4938
> URL: https://issues.apache.org/jira/browse/TS-4938
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 7.1.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> Saw this crash while testing fix for TS-4813.  Have a fix that checks 
> get_netvc() returns a non-NULL.  Should make a more comprehensive review on 
> the use of get_netvc() in HttpTransact.cc/HttpSM.cc
> {code}
> #0  0x0053ed2c in NetVConnection::get_local_addr (this=0x0) at 
> ../iocore/net/P_NetVConnection.h:60
> #1  0x0057dca4 in NetVConnection::get_local_port (this=0x0) at 
> ../iocore/net/P_NetVConnection.h:82
> #2  0x00627844 in 
> HttpTransact::initialize_state_variables_from_request (s=0x2b65700d4a98, 
> obsolete_incoming_request=0x2b65700d51b8)
> at HttpTransact.cc:5709
> #3  0x00632bd1 in HttpTransact::build_error_response 
> (s=0x2b65700d4a98, status_code=HTTP_STATUS_BAD_GATEWAY, 
> reason_phrase_or_null=0x7fb86c "Server Hangup", error_body_type=0x7fb87a 
> "connect#hangup", format=0x0) at HttpTransact.cc:8141
> #4  0x006311fa in HttpTransact::handle_server_died (s=0x2b65700d4a98) 
> at HttpTransact.cc:7789
> #5  0x00620bbc in HttpTransact::handle_server_connection_not_open 
> (s=0x2b65700d4a98) at HttpTransact.cc:3991
> #6  0x0061fd43 in HttpTransact::handle_response_from_server 
> (s=0x2b65700d4a98) at HttpTransact.cc:3824
> #7  0x0061d762 in HttpTransact::HandleResponse (s=0x2b65700d4a98) at 
> HttpTransact.cc:3401
> #8  0x005fc928 in HttpSM::call_transact_and_set_next_state 
> (this=0x2b65700d4a20, 
> f=0x61cf9a ) at 
> HttpSM.cc:7116
> #9  0x005f6902 in HttpSM::handle_server_setup_error 
> (this=0x2b65700d4a20, event=104, data=0x2aabd00372d8) at HttpSM.cc:5505
> #10 0x005e88a4 in HttpSM::state_send_server_request_header 
> (this=0x2b65700d4a20, event=104, data=0x2aabd00372d8) at HttpSM.cc:2053
> #11 0x005eb3ba in HttpSM::main_handler (this=0x2b65700d4a20, 
> event=104, data=0x2aabd00372d8) at HttpSM.cc:2655
> #12 0x005145ac in Continuation::handleEvent (this=0x2b65700d4a20, 
> event=104, data=0x2aabd00372d8) at ../iocore/eventsystem/I_Continuation.h:153
> #13 0x0079906f in write_signal_and_update (event=104, 
> vc=0x2aabd0037140) at UnixNetVConnection.cc:174
> #14 0x007992a6 in write_signal_done (event=104, nh=0x2b64f71b4cf0, 
> vc=0x2aabd0037140) at UnixNetVConnection.cc:216
> #15 0x0079a475 in write_to_net_io (nh=0x2b64f71b4cf0, 
> vc=0x2aabd0037140, thread=0x2b64f71b1010) at UnixNetVConnection.cc:547
> #16 0x00799dc7 in write_to_net (nh=0x2b64f71b4cf0, vc=0x2aabd0037140, 
> thread=0x2b64f71b1010) at UnixNetVConnection.cc:414
> #17 0x0079129d in NetHandler::mainNetEvent (this=0x2b64f71b4cf0, 
> event=5, e=0x1646ac0) at UnixNet.cc:515
> #18 0x005145ac in Continuation::handleEvent (this=0x2b64f71b4cf0, 
> event=5, data=0x1646ac0) at ../iocore/eventsystem/I_Continuation.h:153
> #19 0x007bc90a in EThread::process_event (this=0x2b64f71b1010, 
> e=0x1646ac0, calling_code=5) at UnixEThread.cc:143
> #20 0x007bcf0d in EThread::execute (this=0x2b64f71b1010) at 
> UnixEThread.cc:270
> #21 0x007bbf1e in spawn_thread_internal (a=0x15731f0) at Thread.cc:84
> #22 0x2b64f5fcfaa1 in start_thread () from /lib64/libpthread.so.0
> #23 0x0032310e893d in clone () from /lib64/libc.so.6
> {code}



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

[jira] [Work logged] (TS-4938) Crash due to null client_vc

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4938?focusedWorklogId=30264=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30264
 ]

ASF GitHub Bot logged work on TS-4938:
--

Author: ASF GitHub Bot
Created on: 07/Oct/16 16:01
Start Date: 07/Oct/16 16:01
Worklog Time Spent: 10m 
  Work Description: Github user jpeach commented on a diff in the pull 
request:

https://github.com/apache/trafficserver/pull/1083#discussion_r82416759
  
--- Diff: proxy/http/HttpSM.cc ---
@@ -5841,7 +5843,9 @@ HttpSM::attach_server_session(HttpServerSession *s)
   UnixNetVConnection *server_vc = dynamic_cast(server_session->get_netvc());
   UnixNetVConnection *client_vc = (UnixNetVConnection 
*)(ua_session->get_netvc());
   SSLNetVConnection *ssl_vc = dynamic_cast(client_vc);
-  bool associated_connection= false;
+
+  ink_release_assert(!server_vc || !client_vc || server_vc->thread == 
client_vc->thread);
--- End diff --

Can you please add a comment to document the invariant this is enforcing?


Issue Time Tracking
---

Worklog Id: (was: 30264)
Time Spent: 1h  (was: 50m)

> Crash due to null client_vc
> ---
>
> Key: TS-4938
> URL: https://issues.apache.org/jira/browse/TS-4938
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 7.1.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> Saw this crash while testing fix for TS-4813.  Have a fix that checks 
> get_netvc() returns a non-NULL.  Should make a more comprehensive review on 
> the use of get_netvc() in HttpTransact.cc/HttpSM.cc
> {code}
> #0  0x0053ed2c in NetVConnection::get_local_addr (this=0x0) at 
> ../iocore/net/P_NetVConnection.h:60
> #1  0x0057dca4 in NetVConnection::get_local_port (this=0x0) at 
> ../iocore/net/P_NetVConnection.h:82
> #2  0x00627844 in 
> HttpTransact::initialize_state_variables_from_request (s=0x2b65700d4a98, 
> obsolete_incoming_request=0x2b65700d51b8)
> at HttpTransact.cc:5709
> #3  0x00632bd1 in HttpTransact::build_error_response 
> (s=0x2b65700d4a98, status_code=HTTP_STATUS_BAD_GATEWAY, 
> reason_phrase_or_null=0x7fb86c "Server Hangup", error_body_type=0x7fb87a 
> "connect#hangup", format=0x0) at HttpTransact.cc:8141
> #4  0x006311fa in HttpTransact::handle_server_died (s=0x2b65700d4a98) 
> at HttpTransact.cc:7789
> #5  0x00620bbc in HttpTransact::handle_server_connection_not_open 
> (s=0x2b65700d4a98) at HttpTransact.cc:3991
> #6  0x0061fd43 in HttpTransact::handle_response_from_server 
> (s=0x2b65700d4a98) at HttpTransact.cc:3824
> #7  0x0061d762 in HttpTransact::HandleResponse (s=0x2b65700d4a98) at 
> HttpTransact.cc:3401
> #8  0x005fc928 in HttpSM::call_transact_and_set_next_state 
> (this=0x2b65700d4a20, 
> f=0x61cf9a ) at 
> HttpSM.cc:7116
> #9  0x005f6902 in HttpSM::handle_server_setup_error 
> (this=0x2b65700d4a20, event=104, data=0x2aabd00372d8) at HttpSM.cc:5505
> #10 0x005e88a4 in HttpSM::state_send_server_request_header 
> (this=0x2b65700d4a20, event=104, data=0x2aabd00372d8) at HttpSM.cc:2053
> #11 0x005eb3ba in HttpSM::main_handler (this=0x2b65700d4a20, 
> event=104, data=0x2aabd00372d8) at HttpSM.cc:2655
> #12 0x005145ac in Continuation::handleEvent (this=0x2b65700d4a20, 
> event=104, data=0x2aabd00372d8) at ../iocore/eventsystem/I_Continuation.h:153
> #13 0x0079906f in write_signal_and_update (event=104, 
> vc=0x2aabd0037140) at UnixNetVConnection.cc:174
> #14 0x007992a6 in write_signal_done (event=104, nh=0x2b64f71b4cf0, 
> vc=0x2aabd0037140) at UnixNetVConnection.cc:216
> #15 0x0079a475 in write_to_net_io (nh=0x2b64f71b4cf0, 
> vc=0x2aabd0037140, thread=0x2b64f71b1010) at UnixNetVConnection.cc:547
> #16 0x00799dc7 in write_to_net (nh=0x2b64f71b4cf0, vc=0x2aabd0037140, 
> thread=0x2b64f71b1010) at UnixNetVConnection.cc:414
> #17 0x0079129d in NetHandler::mainNetEvent (this=0x2b64f71b4cf0, 
> event=5, e=0x1646ac0) at UnixNet.cc:515
> #18 0x005145ac in Continuation::handleEvent (this=0x2b64f71b4cf0, 
> event=5, data=0x1646ac0) at ../iocore/eventsystem/I_Continuation.h:153
> #19 0x007bc90a in EThread::process_event (this=0x2b64f71b1010, 
> e=0x1646ac0, calling_code=5) at UnixEThread.cc:143
> #20 0x007bcf0d in EThread::execute (this=0x2b64f71b1010) at 
> UnixEThread.cc:270
> #21 0x007bbf1e in spawn_thread_internal (a=0x15731f0) at Thread.cc:84
> #22 0x2b64f5fcfaa1 in start_thread () from /lib64/libpthread.so.0
> #23 0x0032310e893d in clone () from /lib64/libc.so.6
> {code}



--
This message was 

[GitHub] trafficserver pull request #1083: TS-4938: Avoid crashes due to NULL vc dere...

[jpeach]

Github user jpeach commented on a diff in the pull request:

https://github.com/apache/trafficserver/pull/1083#discussion_r82417247
  
--- Diff: proxy/http/HttpTransact.cc ---
@@ -568,7 +568,10 @@ HttpTransact::BadRequest(State *s)
 void
 HttpTransact::HandleBlindTunnel(State *s)
 {
-  bool inbound_transparent_p = 
s->state_machine->ua_session->get_netvc()->get_is_transparent();
+  NetVConnection *vc = s->state_machine->ua_session->get_netvc();
+  if (!vc)
+return;
--- End diff --

Can this really happen? If it does, what does that mean?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] trafficserver pull request #1083: TS-4938: Avoid crashes due to NULL vc dere...

[jpeach]

Github user jpeach commented on a diff in the pull request:

https://github.com/apache/trafficserver/pull/1083#discussion_r82417601
  
--- Diff: proxy/http/HttpTransact.cc ---
@@ -5795,11 +5799,8 @@ 
HttpTransact::initialize_state_variables_from_request(State *s, HTTPHdr *obsolet
   s->request_data.hostname_str = s->arena.str_store(host_name, host_len);
   ats_ip_copy(>request_data.src_ip, >client_info.src_addr);
   memset(>request_data.dest_ip, 0, sizeof(s->request_data.dest_ip));
-  if (s->state_machine->ua_session) {
-NetVConnection *netvc = s->state_machine->ua_session->get_netvc();
-if (netvc) {
-  s->request_data.incoming_port = netvc->get_local_port();
-}
+  if (s->state_machine->ua_session && vc) {
--- End diff --

If ``vc`` is  not NULL then ``ua_session`` is also not NULL, so checking 
``vc`` should be sufficient. Same for the previous check.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] trafficserver pull request #1083: TS-4938: Avoid crashes due to NULL vc dere...

[jpeach]

Github user jpeach commented on a diff in the pull request:

https://github.com/apache/trafficserver/pull/1083#discussion_r82417120
  
--- Diff: proxy/http/HttpServerSession.h ---
@@ -136,6 +136,19 @@ class HttpServerSession : public VConnection
 ink_release_assert(server_vc != NULL);
 return server_vc->get_remote_endpoint();
   }
+
+  void
+  set_active_timeout(ink_hrtime timeout_in)
+  {
+if (server_vc)
+  server_vc->set_active_timeout(timeout_in);
+  }
+  void
+  set_inactivity_timeout(ink_hrtime timeout_in)
+  {
+if (server_vc)
+  server_vc->set_inactivity_timeout(timeout_in);
+  }
--- End diff --

Newline please.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Resolved] (TS-4626) LogFile::close_file should not delete m_log handle

[Alan M. Carroll (JIRA)]

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

Alan M. Carroll resolved TS-4626.
-
Resolution: Fixed

> LogFile::close_file should not delete m_log handle
> --
>
> Key: TS-4626
> URL: https://issues.apache.org/jira/browse/TS-4626
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Michael Chai
>Assignee: Daniel Xu
> Fix For: 7.1.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> When log file was deleted on the disk, LogFile::check_fd will close file 
> handle and reopen again.delete m_log at this point will cause 
> LogFile::open_file return "LOG_FILE_COULD_NOT_OPEN_FILE" .  otherwise, will 
> cause trafficserver crash at LogFile::preproc_and_try_delete
> 300 if (!m_log->m_start_time) {
> (gdb) bt
> #0  0x0068245f in LogFile::preproc_and_try_delete (this=0x1132eb0, 
> lb=0x7fffdc000da0) at LogFile.cc:300
> #1  0x0068caa6 in LogBufferManager::preproc_buffers (this=0x1132970, 
> sink=0x1132eb0) at LogObject.cc:77
> #2  0x00691a53 in LogObject::preproc_buffers (this=0x1132ae0, idx=0) 
> at LogObject.h:146
> #3  0x006901c3 in LogObjectManager::preproc_buffers (this=0x1127228, 
> idx=0) at LogObject.cc:1126
> #4  0x0066b668 in Log::preproc_thread_main (args=0x1131edc) at 
> Log.cc:1168
> #5  0x0066ce9d in LoggingPreprocContinuation::mainEvent 
> (this=0x1131ea0) at Log.cc:279
> #6  0x0050d662 in Continuation::handleEvent (this=0x1131ea0, event=1, 
> data=0x11529a0) at ../iocore/eventsystem/I_Continuation.h:153
> #7  0x007a1e9f in EThread::execute (this=0x707a1010) at 
> UnixEThread.cc:298
> #8  0x007a0d0c in spawn_thread_internal (a=0x1131ef0) at Thread.cc:84
> #9  0x764740a4 in start_thread (arg=0x707a0700) at 
> pthread_create.c:309
> #10 0x7541c04d in clone () at 
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
> (gdb) p m_log
> $1 = (BaseLogFile *) 0x0



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

[jira] [Work logged] (TS-4626) LogFile::close_file should not delete m_log handle

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4626?focusedWorklogId=30260=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30260
 ]

ASF GitHub Bot logged work on TS-4626:
--

Author: ASF GitHub Bot
Created on: 07/Oct/16 15:43
Start Date: 07/Oct/16 15:43
Worklog Time Spent: 10m 
  Work Description: Github user SolidWallOfCode closed the pull request at:

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


Issue Time Tracking
---

Worklog Id: (was: 30260)
Time Spent: 1h  (was: 50m)

> LogFile::close_file should not delete m_log handle
> --
>
> Key: TS-4626
> URL: https://issues.apache.org/jira/browse/TS-4626
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Michael Chai
>Assignee: Daniel Xu
> Fix For: 7.1.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> When log file was deleted on the disk, LogFile::check_fd will close file 
> handle and reopen again.delete m_log at this point will cause 
> LogFile::open_file return "LOG_FILE_COULD_NOT_OPEN_FILE" .  otherwise, will 
> cause trafficserver crash at LogFile::preproc_and_try_delete
> 300 if (!m_log->m_start_time) {
> (gdb) bt
> #0  0x0068245f in LogFile::preproc_and_try_delete (this=0x1132eb0, 
> lb=0x7fffdc000da0) at LogFile.cc:300
> #1  0x0068caa6 in LogBufferManager::preproc_buffers (this=0x1132970, 
> sink=0x1132eb0) at LogObject.cc:77
> #2  0x00691a53 in LogObject::preproc_buffers (this=0x1132ae0, idx=0) 
> at LogObject.h:146
> #3  0x006901c3 in LogObjectManager::preproc_buffers (this=0x1127228, 
> idx=0) at LogObject.cc:1126
> #4  0x0066b668 in Log::preproc_thread_main (args=0x1131edc) at 
> Log.cc:1168
> #5  0x0066ce9d in LoggingPreprocContinuation::mainEvent 
> (this=0x1131ea0) at Log.cc:279
> #6  0x0050d662 in Continuation::handleEvent (this=0x1131ea0, event=1, 
> data=0x11529a0) at ../iocore/eventsystem/I_Continuation.h:153
> #7  0x007a1e9f in EThread::execute (this=0x707a1010) at 
> UnixEThread.cc:298
> #8  0x007a0d0c in spawn_thread_internal (a=0x1131ef0) at Thread.cc:84
> #9  0x764740a4 in start_thread (arg=0x707a0700) at 
> pthread_create.c:309
> #10 0x7541c04d in clone () at 
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
> (gdb) p m_log
> $1 = (BaseLogFile *) 0x0



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

[jira] [Work logged] (TS-4626) LogFile::close_file should not delete m_log handle

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4626?focusedWorklogId=30259=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30259
 ]

ASF GitHub Bot logged work on TS-4626:
--

Author: ASF GitHub Bot
Created on: 07/Oct/16 15:43
Start Date: 07/Oct/16 15:43
Worklog Time Spent: 10m 
  Work Description: Github user SolidWallOfCode commented on the issue:

https://github.com/apache/trafficserver/pull/1059
  
Checked with @danobi and review the bug, looks like a good fix.


Issue Time Tracking
---

Worklog Id: (was: 30259)
Time Spent: 50m  (was: 40m)

> LogFile::close_file should not delete m_log handle
> --
>
> Key: TS-4626
> URL: https://issues.apache.org/jira/browse/TS-4626
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Michael Chai
>Assignee: Daniel Xu
> Fix For: 7.1.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> When log file was deleted on the disk, LogFile::check_fd will close file 
> handle and reopen again.delete m_log at this point will cause 
> LogFile::open_file return "LOG_FILE_COULD_NOT_OPEN_FILE" .  otherwise, will 
> cause trafficserver crash at LogFile::preproc_and_try_delete
> 300 if (!m_log->m_start_time) {
> (gdb) bt
> #0  0x0068245f in LogFile::preproc_and_try_delete (this=0x1132eb0, 
> lb=0x7fffdc000da0) at LogFile.cc:300
> #1  0x0068caa6 in LogBufferManager::preproc_buffers (this=0x1132970, 
> sink=0x1132eb0) at LogObject.cc:77
> #2  0x00691a53 in LogObject::preproc_buffers (this=0x1132ae0, idx=0) 
> at LogObject.h:146
> #3  0x006901c3 in LogObjectManager::preproc_buffers (this=0x1127228, 
> idx=0) at LogObject.cc:1126
> #4  0x0066b668 in Log::preproc_thread_main (args=0x1131edc) at 
> Log.cc:1168
> #5  0x0066ce9d in LoggingPreprocContinuation::mainEvent 
> (this=0x1131ea0) at Log.cc:279
> #6  0x0050d662 in Continuation::handleEvent (this=0x1131ea0, event=1, 
> data=0x11529a0) at ../iocore/eventsystem/I_Continuation.h:153
> #7  0x007a1e9f in EThread::execute (this=0x707a1010) at 
> UnixEThread.cc:298
> #8  0x007a0d0c in spawn_thread_internal (a=0x1131ef0) at Thread.cc:84
> #9  0x764740a4 in start_thread (arg=0x707a0700) at 
> pthread_create.c:309
> #10 0x7541c04d in clone () at 
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
> (gdb) p m_log
> $1 = (BaseLogFile *) 0x0



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

[GitHub] trafficserver pull request #1059: TS-4626: LogFile::close_file should not de...

[SolidWallOfCode]

Github user SolidWallOfCode closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] trafficserver issue #1059: TS-4626: LogFile::close_file should not delete m_...

[SolidWallOfCode]

Github user SolidWallOfCode commented on the issue:

https://github.com/apache/trafficserver/pull/1059
  
Checked with @danobi and review the bug, looks like a good fix.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] trafficserver pull request #769: TS 4593: Extend ip_allow.config to filter d...

[SolidWallOfCode]

Github user SolidWallOfCode commented on a diff in the pull request:

https://github.com/apache/trafficserver/pull/769#discussion_r82413603
  
--- Diff: proxy/http/HttpTransact.cc ---
@@ -567,6 +567,16 @@ HttpTransact::BadRequest(State *s)
 }
 
 void
+HttpTransact::Forbidden(State *s)
+{
+  DebugTxn("http_trans", "[Forbidden]"
+ "parser marked request forbidden");
--- End diff --

Was this here prior to the patch? "parser marked" seems incorrect, unless 
it's legacy.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] trafficserver pull request #769: TS 4593: Extend ip_allow.config to filter d...

[SolidWallOfCode]

Github user SolidWallOfCode commented on a diff in the pull request:

https://github.com/apache/trafficserver/pull/769#discussion_r82414307
  
--- Diff: proxy/http/remap/RemapConfig.cc ---
@@ -1415,6 +1434,7 @@ remap_parse_config_bti(const char *path, 
BUILD_TABLE_INFO *bti)
 return false;
   } /* end of while(cur_line != NULL) */
 
+  (void)IpAllow::enableAcceptCheck(bti->accept_check_p);
--- End diff --

Did the compiler actually complain about this, to require the `(void)`?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] trafficserver pull request #769: TS 4593: Extend ip_allow.config to filter d...

[SolidWallOfCode]

Github user SolidWallOfCode commented on a diff in the pull request:

https://github.com/apache/trafficserver/pull/769#discussion_r82414495
  
--- Diff: proxy/http/remap/RemapConfig.h ---
@@ -53,6 +53,8 @@ struct BUILD_TABLE_INFO {
   char *paramv[BUILD_TABLE_MAX_ARGS];
   char *argv[BUILD_TABLE_MAX_ARGS];
 
+  unsigned int ip_allow_flag : 1;
--- End diff --

Hmmm, need a better name. "ip_allow_check_enabled_p" maybe?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] trafficserver pull request #769: TS 4593: Extend ip_allow.config to filter d...

[SolidWallOfCode]

Github user SolidWallOfCode commented on a diff in the pull request:

https://github.com/apache/trafficserver/pull/769#discussion_r82414079
  
--- Diff: proxy/http/remap/RemapConfig.cc ---
@@ -1153,6 +1169,9 @@ remap_parse_config_bti(const char *path, 
BUILD_TABLE_INFO *bti)
   goto MAP_ERROR;
 }
 
+// update sticky flag
+bti->accept_check_p &= (bool)bti->ip_allow_flag;
--- End diff --

`&&=` - +logical+ and.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] trafficserver pull request #769: TS 4593: Extend ip_allow.config to filter d...

[SolidWallOfCode]

Github user SolidWallOfCode commented on a diff in the pull request:

https://github.com/apache/trafficserver/pull/769#discussion_r82413194
  
--- Diff: proxy/http/HttpSM.cc ---
@@ -4726,6 +4727,44 @@ HttpSM::do_http_server_open(bool raw)
 milestones[TS_MILESTONE_SERVER_FIRST_CONNECT] = 
milestones[TS_MILESTONE_SERVER_CONNECT];
   }
 
+  // Check for remap rule. If so, only apply ip_allow filter if it is 
activated (ip_allow_flag set).
+  // Otherwise, if no remap rule is defined, apply the ip_allow filter. 
+  if(!t_state.url_remap_success || (t_state.url_remap_success && 
t_state.url_map.getMapping()->ip_allow_flag)) {
+
+// Method allowed on dest IP address check
+sockaddr *server_ip = _state.current.server->dst_addr.sa;
+IpAllow::scoped_config ip_allow;
+const AclRecord *acl_record = NULL;
+int method = t_state.hdr_info.server_request.method_get_wksidx();
+
+if(ip_allow) {
+  acl_record = ip_allow->match(server_ip, true);
+  bool deny_request = false;
+
+  if (acl_record && !acl_record->isEmpty() && 
(acl_record->_method_mask != AclRecord::ALL_METHOD_MASK)) {
+if (method != -1) {
+  deny_request = !acl_record->isMethodAllowed(method);
+} else {
+  int method_str_len;
+  const char *method_str = 
t_state.hdr_info.server_request.method_get(_str_len);
+  deny_request = 
!acl_record->isNonstandardMethodAllowed(std::string(method_str, 
method_str_len));
+}
+  }
+  if (deny_request) {
+if (is_debug_tag_set("ip-allow")) {
+  ip_text_buffer ipb;
+  Warning("server '%s' prohibited by ip-allow policy", 
ats_ip_ntop(server_ip, ipb, sizeof(ipb)));
+  Debug("ip-allow", "Quick filter denial on %s:%s with mask %x", 
ats_ip_ntop(_state.current.server->dst_addr.sa, ipb, sizeof(ipb)),
--- End diff --

"Quick filter"?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] trafficserver pull request #769: TS 4593: Extend ip_allow.config to filter d...

[SolidWallOfCode]

Github user SolidWallOfCode commented on a diff in the pull request:

https://github.com/apache/trafficserver/pull/769#discussion_r82400518
  
--- Diff: proxy/IPAllow.h ---
@@ -129,34 +129,55 @@ class IpAllow : public ConfigInfo
   {
 return _METHOD_ACL;
   }
+  
+  /// @return The previous accept check state
+  static bool enableAcceptCheck(bool state) {
+bool temp = accept_check_p;
+accept_check_p = state;
+return temp;
+  }
+  /// @return The current accept check state
+  static bool isAcceptCheckEnabled() {
+return accept_check_p;
+  }
 
   typedef ConfigProcessor::scoped_config scoped_config;
 
 private:
   static int configid;
   static const AclRecord ALL_METHOD_ACL;
+  static bool accept_check_p;
 
+  void PrintMap(IpMap * map);
   int BuildTable();
 
   char config_file_path[PATH_NAME_MAX];
   const char *module_name;
   const char *action;
-  IpMap _map;
-  Vec _acls;
+  IpMap _src_map;
+  IpMap _dest_map;
+  Vec _src_acls;
+  Vec _dest_acls;
 };
 
 inline AclRecord *
-IpAllow::match(IpEndpoint const *ip) const
+IpAllow::match(IpEndpoint const *ip, bool is_dest_ip) const
 {
-  return this->match(>sa);
+  return this->match(>sa, is_dest_ip);
 }
 
 inline AclRecord *
-IpAllow::match(sockaddr const *ip) const
+IpAllow::match(sockaddr const *ip, bool is_dest_ip) const
 {
   void *raw;
-  if (_map.contains(ip, )) {
-return static_cast(raw);
+  if(is_dest_ip) {
--- End diff --

I think
```
IpAllow::match(sockaddr const* ip, match_key_t key) {
void *raw = NULL;
this->map(key).contains(ip, );
return static_cast(raw);
```

Then define
```
IpMap& map(match_key_t key) { return key == SRC_ADDR ? _src_map : 
_dest_map; }
```

This could be used elsewhere instead of the current ternary operator for 
cleaner code.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4938) Crash due to null client_vc

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4938?focusedWorklogId=30258=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30258
 ]

ASF GitHub Bot logged work on TS-4938:
--

Author: ASF GitHub Bot
Created on: 07/Oct/16 14:19
Start Date: 07/Oct/16 14:19
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1083
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/839/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 30258)
Time Spent: 50m  (was: 40m)

> Crash due to null client_vc
> ---
>
> Key: TS-4938
> URL: https://issues.apache.org/jira/browse/TS-4938
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 7.1.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> Saw this crash while testing fix for TS-4813.  Have a fix that checks 
> get_netvc() returns a non-NULL.  Should make a more comprehensive review on 
> the use of get_netvc() in HttpTransact.cc/HttpSM.cc
> {code}
> #0  0x0053ed2c in NetVConnection::get_local_addr (this=0x0) at 
> ../iocore/net/P_NetVConnection.h:60
> #1  0x0057dca4 in NetVConnection::get_local_port (this=0x0) at 
> ../iocore/net/P_NetVConnection.h:82
> #2  0x00627844 in 
> HttpTransact::initialize_state_variables_from_request (s=0x2b65700d4a98, 
> obsolete_incoming_request=0x2b65700d51b8)
> at HttpTransact.cc:5709
> #3  0x00632bd1 in HttpTransact::build_error_response 
> (s=0x2b65700d4a98, status_code=HTTP_STATUS_BAD_GATEWAY, 
> reason_phrase_or_null=0x7fb86c "Server Hangup", error_body_type=0x7fb87a 
> "connect#hangup", format=0x0) at HttpTransact.cc:8141
> #4  0x006311fa in HttpTransact::handle_server_died (s=0x2b65700d4a98) 
> at HttpTransact.cc:7789
> #5  0x00620bbc in HttpTransact::handle_server_connection_not_open 
> (s=0x2b65700d4a98) at HttpTransact.cc:3991
> #6  0x0061fd43 in HttpTransact::handle_response_from_server 
> (s=0x2b65700d4a98) at HttpTransact.cc:3824
> #7  0x0061d762 in HttpTransact::HandleResponse (s=0x2b65700d4a98) at 
> HttpTransact.cc:3401
> #8  0x005fc928 in HttpSM::call_transact_and_set_next_state 
> (this=0x2b65700d4a20, 
> f=0x61cf9a ) at 
> HttpSM.cc:7116
> #9  0x005f6902 in HttpSM::handle_server_setup_error 
> (this=0x2b65700d4a20, event=104, data=0x2aabd00372d8) at HttpSM.cc:5505
> #10 0x005e88a4 in HttpSM::state_send_server_request_header 
> (this=0x2b65700d4a20, event=104, data=0x2aabd00372d8) at HttpSM.cc:2053
> #11 0x005eb3ba in HttpSM::main_handler (this=0x2b65700d4a20, 
> event=104, data=0x2aabd00372d8) at HttpSM.cc:2655
> #12 0x005145ac in Continuation::handleEvent (this=0x2b65700d4a20, 
> event=104, data=0x2aabd00372d8) at ../iocore/eventsystem/I_Continuation.h:153
> #13 0x0079906f in write_signal_and_update (event=104, 
> vc=0x2aabd0037140) at UnixNetVConnection.cc:174
> #14 0x007992a6 in write_signal_done (event=104, nh=0x2b64f71b4cf0, 
> vc=0x2aabd0037140) at UnixNetVConnection.cc:216
> #15 0x0079a475 in write_to_net_io (nh=0x2b64f71b4cf0, 
> vc=0x2aabd0037140, thread=0x2b64f71b1010) at UnixNetVConnection.cc:547
> #16 0x00799dc7 in write_to_net (nh=0x2b64f71b4cf0, vc=0x2aabd0037140, 
> thread=0x2b64f71b1010) at UnixNetVConnection.cc:414
> #17 0x0079129d in NetHandler::mainNetEvent (this=0x2b64f71b4cf0, 
> event=5, e=0x1646ac0) at UnixNet.cc:515
> #18 0x005145ac in Continuation::handleEvent (this=0x2b64f71b4cf0, 
> event=5, data=0x1646ac0) at ../iocore/eventsystem/I_Continuation.h:153
> #19 0x007bc90a in EThread::process_event (this=0x2b64f71b1010, 
> e=0x1646ac0, calling_code=5) at UnixEThread.cc:143
> #20 0x007bcf0d in EThread::execute (this=0x2b64f71b1010) at 
> UnixEThread.cc:270
> #21 0x007bbf1e in spawn_thread_internal (a=0x15731f0) at Thread.cc:84
> #22 0x2b64f5fcfaa1 in start_thread () from /lib64/libpthread.so.0
> #23 0x0032310e893d in clone () from /lib64/libc.so.6
> {code}



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

[GitHub] trafficserver issue #1083: TS-4938: Avoid crashes due to NULL vc dereference...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1083
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/839/ for details.
 



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4938) Crash due to null client_vc

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4938?focusedWorklogId=30257=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30257
 ]

ASF GitHub Bot logged work on TS-4938:
--

Author: ASF GitHub Bot
Created on: 07/Oct/16 14:15
Start Date: 07/Oct/16 14:15
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1083
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/947/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 30257)
Time Spent: 40m  (was: 0.5h)

> Crash due to null client_vc
> ---
>
> Key: TS-4938
> URL: https://issues.apache.org/jira/browse/TS-4938
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 7.1.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Saw this crash while testing fix for TS-4813.  Have a fix that checks 
> get_netvc() returns a non-NULL.  Should make a more comprehensive review on 
> the use of get_netvc() in HttpTransact.cc/HttpSM.cc
> {code}
> #0  0x0053ed2c in NetVConnection::get_local_addr (this=0x0) at 
> ../iocore/net/P_NetVConnection.h:60
> #1  0x0057dca4 in NetVConnection::get_local_port (this=0x0) at 
> ../iocore/net/P_NetVConnection.h:82
> #2  0x00627844 in 
> HttpTransact::initialize_state_variables_from_request (s=0x2b65700d4a98, 
> obsolete_incoming_request=0x2b65700d51b8)
> at HttpTransact.cc:5709
> #3  0x00632bd1 in HttpTransact::build_error_response 
> (s=0x2b65700d4a98, status_code=HTTP_STATUS_BAD_GATEWAY, 
> reason_phrase_or_null=0x7fb86c "Server Hangup", error_body_type=0x7fb87a 
> "connect#hangup", format=0x0) at HttpTransact.cc:8141
> #4  0x006311fa in HttpTransact::handle_server_died (s=0x2b65700d4a98) 
> at HttpTransact.cc:7789
> #5  0x00620bbc in HttpTransact::handle_server_connection_not_open 
> (s=0x2b65700d4a98) at HttpTransact.cc:3991
> #6  0x0061fd43 in HttpTransact::handle_response_from_server 
> (s=0x2b65700d4a98) at HttpTransact.cc:3824
> #7  0x0061d762 in HttpTransact::HandleResponse (s=0x2b65700d4a98) at 
> HttpTransact.cc:3401
> #8  0x005fc928 in HttpSM::call_transact_and_set_next_state 
> (this=0x2b65700d4a20, 
> f=0x61cf9a ) at 
> HttpSM.cc:7116
> #9  0x005f6902 in HttpSM::handle_server_setup_error 
> (this=0x2b65700d4a20, event=104, data=0x2aabd00372d8) at HttpSM.cc:5505
> #10 0x005e88a4 in HttpSM::state_send_server_request_header 
> (this=0x2b65700d4a20, event=104, data=0x2aabd00372d8) at HttpSM.cc:2053
> #11 0x005eb3ba in HttpSM::main_handler (this=0x2b65700d4a20, 
> event=104, data=0x2aabd00372d8) at HttpSM.cc:2655
> #12 0x005145ac in Continuation::handleEvent (this=0x2b65700d4a20, 
> event=104, data=0x2aabd00372d8) at ../iocore/eventsystem/I_Continuation.h:153
> #13 0x0079906f in write_signal_and_update (event=104, 
> vc=0x2aabd0037140) at UnixNetVConnection.cc:174
> #14 0x007992a6 in write_signal_done (event=104, nh=0x2b64f71b4cf0, 
> vc=0x2aabd0037140) at UnixNetVConnection.cc:216
> #15 0x0079a475 in write_to_net_io (nh=0x2b64f71b4cf0, 
> vc=0x2aabd0037140, thread=0x2b64f71b1010) at UnixNetVConnection.cc:547
> #16 0x00799dc7 in write_to_net (nh=0x2b64f71b4cf0, vc=0x2aabd0037140, 
> thread=0x2b64f71b1010) at UnixNetVConnection.cc:414
> #17 0x0079129d in NetHandler::mainNetEvent (this=0x2b64f71b4cf0, 
> event=5, e=0x1646ac0) at UnixNet.cc:515
> #18 0x005145ac in Continuation::handleEvent (this=0x2b64f71b4cf0, 
> event=5, data=0x1646ac0) at ../iocore/eventsystem/I_Continuation.h:153
> #19 0x007bc90a in EThread::process_event (this=0x2b64f71b1010, 
> e=0x1646ac0, calling_code=5) at UnixEThread.cc:143
> #20 0x007bcf0d in EThread::execute (this=0x2b64f71b1010) at 
> UnixEThread.cc:270
> #21 0x007bbf1e in spawn_thread_internal (a=0x15731f0) at Thread.cc:84
> #22 0x2b64f5fcfaa1 in start_thread () from /lib64/libpthread.so.0
> #23 0x0032310e893d in clone () from /lib64/libc.so.6
> {code}



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

[GitHub] trafficserver issue #1083: TS-4938: Avoid crashes due to NULL vc dereference...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1083
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/947/ for details.
 



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---