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

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/1037
  
@PSUdaemon @masaori335 Let's get another Jira open to remove or refactor 
the thread startup options so that this kind of error can't happen. It looks to 
me like the thread function arguments are not ever used.


Issue Time Tracking
---

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

> 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
> Fix For: 7.1.0
>
>  Time Spent: 1h
>  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)

[GitHub] trafficserver issue #1037: TS-4883: Fix Thread::start call in EventProcessor...

[jpeach]

Github user jpeach commented on the issue:

https://github.com/apache/trafficserver/pull/1037
  
@PSUdaemon @masaori335 Let's get another Jira open to remove or refactor 
the thread startup options so that this kind of error can't happen. It looks to 
me like the thread function arguments are not ever used.


---
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-4883) Argument mismatch of the Thread::start call in EventProcessor::start

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> 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
> Fix For: 7.1.0
>
>  Time Spent: 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)

[GitHub] trafficserver issue #1037: TS-4883: Fix Thread::start call in EventProcessor...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1037
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/738/ 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-4883) Argument mismatch of the Thread::start call in EventProcessor::start

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> 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
> Fix For: 7.1.0
>
>  Time Spent: 40m
>  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)

[GitHub] trafficserver issue #1037: TS-4883: Fix Thread::start call in EventProcessor...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1037
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/843/ 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-4883) Argument mismatch of the Thread::start call in EventProcessor::start

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/1037
  
[approve ci]


Issue Time Tracking
---

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

> 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
> Fix For: 7.1.0
>
>  Time Spent: 0.5h
>  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)

[GitHub] trafficserver issue #1037: TS-4883: Fix Thread::start call in EventProcessor...

[masaori335]

Github user masaori335 commented on the issue:

https://github.com/apache/trafficserver/pull/1037
  
[approve ci]


---
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-4883) Argument mismatch of the Thread::start call in EventProcessor::start

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 21/Sep/16 03:54
Start Date: 21/Sep/16 03:54
Worklog Time Spent: 10m 
  Work Description: Github user masaori335 commented on the issue:

https://github.com/apache/trafficserver/pull/1037
  
Looks good to me


Issue Time Tracking
---

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

> 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
> Fix For: 7.1.0
>
>  Time Spent: 20m
>  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)

[GitHub] trafficserver issue #1037: TS-4883: Fix Thread::start call in EventProcessor...

[masaori335]

Github user masaori335 commented on the issue:

https://github.com/apache/trafficserver/pull/1037
  
Looks good to me


---
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-4883) Argument mismatch of the Thread::start call in EventProcessor::start

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 21/Sep/16 03:45
Start Date: 21/Sep/16 03:45
Worklog Time Spent: 10m 
  Work Description: GitHub user mgosui opened a pull request:

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

TS-4883: Fix Thread::start call in EventProcessor::start

[TS-4883](https://issues.apache.org/jira/browse/TS-4883)

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

$ git pull https://github.com/mgosui/trafficserver ts-4883

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

https://github.com/apache/trafficserver/pull/1037.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 #1037


commit a545a809ab5eae205ac8bab0c23fe01c4fca2fdd
Author: Masato Gosui 
Date:   2016-09-21T03:42:00Z

TS-4883: Fix Thread::start call in EventProcessor::start




Issue Time Tracking
---

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

> 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
> Fix For: 7.1.0
>
>  Time Spent: 10m
>  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)

[GitHub] trafficserver pull request #1037: TS-4883: Fix Thread::start call in EventPr...

[mgosui]

GitHub user mgosui opened a pull request:

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

TS-4883: Fix Thread::start call in EventProcessor::start

[TS-4883](https://issues.apache.org/jira/browse/TS-4883)

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

$ git pull https://github.com/mgosui/trafficserver ts-4883

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

https://github.com/apache/trafficserver/pull/1037.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 #1037


commit a545a809ab5eae205ac8bab0c23fe01c4fca2fdd
Author: Masato Gosui 
Date:   2016-09-21T03:42:00Z

TS-4883: Fix Thread::start call in EventProcessor::start




---
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] [Updated] (TS-4883) Argument mismatch of the Thread::start call in EventProcessor::start

[Masaori Koshiba (JIRA)]

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

Masaori Koshiba updated TS-4883:

Fix Version/s: 7.1.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
> Fix For: 7.1.0
>
>
> 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] [Created] (TS-4883) Argument mismatch of the Thread::start call in EventProcessor::start

[Masato Gosui (JIRA)]

Masato Gosui created TS-4883:


 Summary: 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


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-4880) RemapPlugin class doesn't work correctly

[Ryo Okubo (JIRA)]

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

Ryo Okubo updated TS-4880:
--
Description: 
Current atscppapi::RemapPlugin has two issues. These seem to be caused by 
missing utils::internal::initTransactionManagement() call.

First, after TS-4555, plugins uses RemapPlugin class doesn't work because it 
can't pass an assertion.

{noformat}
# my remap.config. It uses RemapPlugin, one of atscppapi examples.
map / http://127.0.0.1:80/ @plugin=RemapPlugin.so
{noformat}

{noformat}
$ lldb /path/to/traffic_server
...
(lldb) r
...
(lldb) bt
...
* thread #7: tid = 0x3ce4eef, 0x7fff886d0f06 
libsystem_kernel.dylib`__pthread_kill + 10, name = '[ET_NET 4]', stop reason = 
signal SIGABRT
  * frame #0: 0x7fff886d0f06 libsystem_kernel.dylib`__pthread_kill + 10
frame #1: 0x7fff91d6b4ec libsystem_pthread.dylib`pthread_kill + 90
frame #2: 0x7fff902b56df libsystem_c.dylib`abort + 129
frame #3: 0x00039799 
libtsutil.7.dylib`ink_abort(message_format="%s:%d: failed assertion `%s`") + 
361 at ink_error.cc:79
frame #4: 0x0003703f 
libtsutil.7.dylib`::_ink_assert(expression="arg_idx >= 0 && arg_idx < 
HTTP_SSN_TXN_MAX_USER_ARG", file="InkAPI.cc", line=5881) + 47 at 
ink_assert.cc:37
frame #5: 0x0001000446c3 
traffic_server`::_TSReleaseAssert(text="arg_idx >= 0 && arg_idx < 
HTTP_SSN_TXN_MAX_USER_ARG", file="InkAPI.cc", line=5881) + 35 at InkAPI.cc:396
frame #6: 0x000100054e0f 
traffic_server`::TSHttpTxnArgGet(txnp=0x05d6b200, arg_idx=-1) + 111 at 
InkAPI.cc:5881
frame #7: 0x0579bb9b 
libatscppapi.7.dylib`atscppapi::utils::internal::getTransaction(ats_txn_handle=0x05d6b200)
 + 27 at utils_internal.cc:159
frame #8: 0x057bba8c 
libatscppapi.7.dylib`::TSRemapDoRemap(ih=0x00759fe0, 
rh=0x05d6b200, rri=0x7058df08) + 108 at RemapPlugin.cc:35
frame #9: 0x0001001cb79e 
traffic_server`RemapPlugins::run_plugin(this=0x7058e0e8, 
plugin=0x00759f90) + 350 at RemapPlugins.cc:75
frame #10: 0x0001001cb9c3 
traffic_server`RemapPlugins::run_single_remap(this=0x7058e0e8) + 435 at 
RemapPlugins.cc:111
...
{noformat}

Second, Remap Plugin remains an another issue if we simply revert 
https://github.com/apache/trafficserver/commit/17fdb2fd7dc47d09f8c8d7f9b6ff27b035c00d85.
 Objects of atscppapi::Transaction is created correctly at utils_internal.cc, 
but its destructor is never called.

{noformat}
# Revert and rebuild ATS
$ git revert 17fdb2fd7dc47d09f8c8d7f9b6ff27b035c00d85 --no-commit
...
$ make && make install
{noformat}

{noformat}
$ lldb /path/to/traffic_server
...
(lldb) r
...
# It can pass the assertion! but ...

(lldb) b -M ~Transaction
(lldb) r
# atscppapi::Transaction::~Transaction() is not called.
{noformat}

  was:
Current atscppapi::RemapPlugin has two issues. These seem to be caused by 
missing utils::internal::initTransactionManagement() call.

First, after TS-4555, plugins uses RemapPlugin class doesn't work because it 
can't pass an assertion.

{noformat}
# my remap.config. It uses RemapPlugin, one of atscppapi examples.
map / http://127.0.0.1:80/ @plugin=RemapPlugin.so
{noformat}

{noformat}
$ lldb /path/to/traffic_server
...
(lldb) r
...
(lldb) bt
...
* thread #7: tid = 0x3ce4eef, 0x7fff886d0f06 
libsystem_kernel.dylib`__pthread_kill + 10, name = '[ET_NET 4]', stop reason = 
signal SIGABRT
  * frame #0: 0x7fff886d0f06 libsystem_kernel.dylib`__pthread_kill + 10
frame #1: 0x7fff91d6b4ec libsystem_pthread.dylib`pthread_kill + 90
frame #2: 0x7fff902b56df libsystem_c.dylib`abort + 129
frame #3: 0x00039799 
libtsutil.7.dylib`ink_abort(message_format="%s:%d: failed assertion `%s`") + 
361 at ink_error.cc:79
frame #4: 0x0003703f 
libtsutil.7.dylib`::_ink_assert(expression="arg_idx >= 0 && arg_idx < 
HTTP_SSN_TXN_MAX_USER_ARG", file="InkAPI.cc", line=5881) + 47 at 
ink_assert.cc:37
frame #5: 0x0001000446c3 
traffic_server`::_TSReleaseAssert(text="arg_idx >= 0 && arg_idx < 
HTTP_SSN_TXN_MAX_USER_ARG", file="InkAPI.cc", line=5881) + 35 at InkAPI.cc:396
frame #6: 0x000100054e0f 
traffic_server`::TSHttpTxnArgGet(txnp=0x05d6b200, arg_idx=-1) + 111 at 
InkAPI.cc:5881
frame #7: 0x0579bb9b 
libatscppapi.7.dylib`atscppapi::utils::internal::getTransaction(ats_txn_handle=0x05d6b200)
 + 27 at utils_internal.cc:159
frame #8: 0x057bba8c 
libatscppapi.7.dylib`::TSRemapDoRemap(ih=0x00759fe0, 
rh=0x05d6b200, rri=0x7058df08) + 108 at RemapPlugin.cc:35
frame #9: 0x0001001cb79e 
traffic_server`RemapPlugins::run_plugin(this=0x7058e0e8, 
plugin=0x00759f90) + 350 at RemapPlugins.cc:75
frame #10: 0x0001001cb9c3 
traffic_server`RemapPlugins::run_single_remap(this=0x7058e0e8) + 435 at 
RemapPlugins.cc:111
...
{noformat}

Second, Remap 

[jira] [Updated] (TS-2258) Verify that all fields are correct in RecordsConfig.cc

[Jari Alhonen (JIRA)]

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

Jari Alhonen updated TS-2258:
-
Assignee: (was: Jari Alhonen)

> Verify that all fields are correct in RecordsConfig.cc
> --
>
> Key: TS-2258
> URL: https://issues.apache.org/jira/browse/TS-2258
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Leif Hedstrom
>  Labels: newbie
> Fix For: 7.1.0
>
>  Time Spent: 7h 40m
>  Remaining Estimate: 0h
>
> We should go through every configuration in RecordsConfig.cc, and assure that 
> fields such as if it's dynamically reloadable or not, validation regexes etc. 
> are all set 100% correct.
> Once this file is accurate, and will be the one true authoritative source for 
> everything "configuration"; it can be used for command line help (e.g. 
> traffic_line can say if a config is reloadable), and we can even use it as a 
> source for the Sphinx documentation.
> A bonus would be to add a one-line helper line for each configuration in 
> RecordsConfig.cc. This can again be used for e.g. traffic_line, or for a new 
> type of tools to help managing configurations.



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

[jira] [Commented] (TS-2258) Verify that all fields are correct in RecordsConfig.cc

[Jari Alhonen (JIRA)]

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

Jari Alhonen commented on TS-2258:
--

There is plenty more, 887 was just a start. But I would rather focus on other 
things at the moment, someone else can pick this up.

> Verify that all fields are correct in RecordsConfig.cc
> --
>
> Key: TS-2258
> URL: https://issues.apache.org/jira/browse/TS-2258
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Leif Hedstrom
>Assignee: Jari Alhonen
>  Labels: newbie
> Fix For: 7.1.0
>
>  Time Spent: 7h 40m
>  Remaining Estimate: 0h
>
> We should go through every configuration in RecordsConfig.cc, and assure that 
> fields such as if it's dynamically reloadable or not, validation regexes etc. 
> are all set 100% correct.
> Once this file is accurate, and will be the one true authoritative source for 
> everything "configuration"; it can be used for command line help (e.g. 
> traffic_line can say if a config is reloadable), and we can even use it as a 
> source for the Sphinx documentation.
> A bonus would be to add a one-line helper line for each configuration in 
> RecordsConfig.cc. This can again be used for e.g. traffic_line, or for a new 
> type of tools to help managing configurations.



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

[jira] [Work logged] (TS-4882) TCP Fast Open support for SSL server sessions.

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> TCP Fast Open support for SSL server sessions.
> --
>
> Key: TS-4882
> URL: https://issues.apache.org/jira/browse/TS-4882
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core, SSL
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.1.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Add support for using TCP Fast Open on TLS server sessions. This is mainly 
> interesting for CONNECT tunnels where we can't use long running persistent 
> sessions.



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

[GitHub] trafficserver issue #1036: [WIP] TS-4882: TCP Fast Open support for server s...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1036
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/737/ 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-4882) TCP Fast Open support for SSL server sessions.

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> TCP Fast Open support for SSL server sessions.
> --
>
> Key: TS-4882
> URL: https://issues.apache.org/jira/browse/TS-4882
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core, SSL
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.1.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Add support for using TCP Fast Open on TLS server sessions. This is mainly 
> interesting for CONNECT tunnels where we can't use long running persistent 
> sessions.



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

[GitHub] trafficserver issue #1036: [WIP] TS-4882: TCP Fast Open support for server s...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1036
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/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.
---

[GitHub] trafficserver pull request #1036: [WIP] TS-4882: TCP Fast Open support for s...

[jpeach]

GitHub user jpeach opened a pull request:

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

[WIP] TS-4882: TCP Fast Open support for server sessions.



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

$ git pull https://github.com/jpeach/trafficserver fix/4882

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

https://github.com/apache/trafficserver/pull/1036.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 #1036


commit 9499442244d2028369b9202d66bbb227f64e1b5e
Author: James Peach 
Date:   2016-09-20T17:17:45Z

TS-4882: Add a socket BIO for TCP Fast Open.

commit efe8521bd41825838ad33e22b4ef0b6520725cb5
Author: James Peach 
Date:   2016-09-20T18:44:37Z

TS-4882: Implement TCP Fast Open for SSL.

Wire up socket flag configuration for TCP Fast Open to be used on
outbound SSL connections.

commit 8fca803cade9f2cc7ea4d8a855ef6b6df2d90a1d
Author: James Peach 
Date:   2016-09-20T22:49:24Z

TS-4882: Implement TCP Fast Open for CONNECT tunnels.




---
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-4882) TCP Fast Open support for SSL server sessions.

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 20/Sep/16 23:47
Start Date: 20/Sep/16 23:47
Worklog Time Spent: 10m 
  Work Description: GitHub user jpeach opened a pull request:

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

[WIP] TS-4882: TCP Fast Open support for server sessions.



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

$ git pull https://github.com/jpeach/trafficserver fix/4882

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

https://github.com/apache/trafficserver/pull/1036.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 #1036


commit 9499442244d2028369b9202d66bbb227f64e1b5e
Author: James Peach 
Date:   2016-09-20T17:17:45Z

TS-4882: Add a socket BIO for TCP Fast Open.

commit efe8521bd41825838ad33e22b4ef0b6520725cb5
Author: James Peach 
Date:   2016-09-20T18:44:37Z

TS-4882: Implement TCP Fast Open for SSL.

Wire up socket flag configuration for TCP Fast Open to be used on
outbound SSL connections.

commit 8fca803cade9f2cc7ea4d8a855ef6b6df2d90a1d
Author: James Peach 
Date:   2016-09-20T22:49:24Z

TS-4882: Implement TCP Fast Open for CONNECT tunnels.




Issue Time Tracking
---

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

> TCP Fast Open support for SSL server sessions.
> --
>
> Key: TS-4882
> URL: https://issues.apache.org/jira/browse/TS-4882
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core, SSL
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.1.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Add support for using TCP Fast Open on TLS server sessions. This is mainly 
> interesting for CONNECT tunnels where we can't use long running persistent 
> sessions.



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

[jira] [Commented] (TS-2258) Verify that all fields are correct in RecordsConfig.cc

[James Peach (JIRA)]

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

James Peach commented on TS-2258:
-

[~jaript] is there more work here, or does PR #887 complete it?

> Verify that all fields are correct in RecordsConfig.cc
> --
>
> Key: TS-2258
> URL: https://issues.apache.org/jira/browse/TS-2258
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Leif Hedstrom
>Assignee: Jari Alhonen
>  Labels: newbie
> Fix For: 7.1.0
>
>  Time Spent: 7h 40m
>  Remaining Estimate: 0h
>
> We should go through every configuration in RecordsConfig.cc, and assure that 
> fields such as if it's dynamically reloadable or not, validation regexes etc. 
> are all set 100% correct.
> Once this file is accurate, and will be the one true authoritative source for 
> everything "configuration"; it can be used for command line help (e.g. 
> traffic_line can say if a config is reloadable), and we can even use it as a 
> source for the Sphinx documentation.
> A bonus would be to add a one-line helper line for each configuration in 
> RecordsConfig.cc. This can again be used for e.g. traffic_line, or for a new 
> type of tools to help managing configurations.



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

[jira] [Work logged] (TS-2258) Verify that all fields are correct in RecordsConfig.cc

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 20/Sep/16 23:06
Start Date: 20/Sep/16 23:06
Worklog Time Spent: 10m 
  Work Description: Github user asfgit closed the pull request at:

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


Issue Time Tracking
---

Worklog Id: (was: 29415)
Time Spent: 7h 40m  (was: 7.5h)

> Verify that all fields are correct in RecordsConfig.cc
> --
>
> Key: TS-2258
> URL: https://issues.apache.org/jira/browse/TS-2258
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Leif Hedstrom
>  Labels: newbie
> Fix For: 7.1.0
>
>  Time Spent: 7h 40m
>  Remaining Estimate: 0h
>
> We should go through every configuration in RecordsConfig.cc, and assure that 
> fields such as if it's dynamically reloadable or not, validation regexes etc. 
> are all set 100% correct.
> Once this file is accurate, and will be the one true authoritative source for 
> everything "configuration"; it can be used for command line help (e.g. 
> traffic_line can say if a config is reloadable), and we can even use it as a 
> source for the Sphinx documentation.
> A bonus would be to add a one-line helper line for each configuration in 
> RecordsConfig.cc. This can again be used for e.g. traffic_line, or for a new 
> type of tools to help managing configurations.



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

[jira] [Updated] (TS-2258) Verify that all fields are correct in RecordsConfig.cc

[James Peach (JIRA)]

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

James Peach updated TS-2258:

Assignee: Jari Alhonen

> Verify that all fields are correct in RecordsConfig.cc
> --
>
> Key: TS-2258
> URL: https://issues.apache.org/jira/browse/TS-2258
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Leif Hedstrom
>Assignee: Jari Alhonen
>  Labels: newbie
> Fix For: 7.1.0
>
>  Time Spent: 7h 40m
>  Remaining Estimate: 0h
>
> We should go through every configuration in RecordsConfig.cc, and assure that 
> fields such as if it's dynamically reloadable or not, validation regexes etc. 
> are all set 100% correct.
> Once this file is accurate, and will be the one true authoritative source for 
> everything "configuration"; it can be used for command line help (e.g. 
> traffic_line can say if a config is reloadable), and we can even use it as a 
> source for the Sphinx documentation.
> A bonus would be to add a one-line helper line for each configuration in 
> RecordsConfig.cc. This can again be used for e.g. traffic_line, or for a new 
> type of tools to help managing configurations.



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

[GitHub] trafficserver pull request #887: TS-2258: Mark whether configs are reloadabl...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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-4707) Parent Consistent Hash Selection - add fname and maxdirs options.

[Peter Chou (JIRA)]

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

Peter Chou commented on TS-4707:


[~gancho] -- This seems fine to me also. I would like to add that you should 
only implement the specific functionality for 'fname' and 'maxdirs' if you 
think it would benefit the wider community. Otherwise, the focus can just be on 
extending the existing cache URL manipulation capability to the parent 
selection URL.

> Parent Consistent Hash Selection - add fname and maxdirs options.
> -
>
> Key: TS-4707
> URL: https://issues.apache.org/jira/browse/TS-4707
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Parent Proxy
>Reporter: Peter Chou
>Assignee: Peter Chou
> Fix For: 7.1.0
>
>  Time Spent: 11.5h
>  Remaining Estimate: 0h
>
> This enhancement adds two options, "fname" and "maxdirs", which can be used 
> to exclude the file-name and some of the directories in the path. The 
> remaining portions of the path are then used as part of the hash computation 
> for selecting among multiple parent caches.
> For our usage, it was desirable from an operational perspective to direct all 
> components of particular sub-tree to a single parent cache (to simplify 
> trouble-shooting, pre-loading, etc.). This can be achieved by excluding the 
> query-string, file-name, and right-most portions of the path from the hash 
> computation.



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

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

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

Worklog Id: (was: 29409)
Time Spent: 2h 50m  (was: 2h 40m)

> 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)

[GitHub] trafficserver issue #1028: TS-4870: Avoid marking storage offline multiple t...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1028
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/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.
---

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

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 20/Sep/16 17:21
Start Date: 20/Sep/16 17:21
Worklog Time Spent: 10m 
  Work Description: Github user jpeach closed the pull request at:

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


Issue Time Tracking
---

Worklog Id: (was: 29408)
Time Spent: 2h 40m  (was: 2.5h)

> 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 40m
>  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)

[GitHub] trafficserver pull request #1028: TS-4870: Avoid marking storage offline mul...

[jpeach]

Github user jpeach closed the pull request at:

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


---
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-4817) Frequent segfaults in Cache::open_write

[Susan Hinrichs (JIRA)]

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

Susan Hinrichs commented on TS-4817:


I see TransformTerminus on the stack.  Is there a plugin involved?

> Frequent segfaults in Cache::open_write
> ---
>
> Key: TS-4817
> URL: https://issues.apache.org/jira/browse/TS-4817
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cache, HTTP
>Reporter: Mathias Biilmann Christensen
> Fix For: 7.1.0
>
> Attachments: core-dump.tar.gz
>
>
> I've been running some tests with the master branch sending some production 
> traffic to a test server, and am seeing very frequent segfaults.
> I'm running fb8bcbcac3c1d6c7a15340f0093342fb9f207e78
> The stack traces look like this:
> {noformat}
> traffic_server - STACK TRACE: 
> /opt/ts/bin/traffic_server(crash_logger_invoke(int, siginfo_t*, 
> void*)+0xc3)[0x511280]
> /lib/x86_64-linux-gnu/libpthread.so.0(+0x10330)[0x2ae12de39330]
> /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37)[0x2ae12eaa1c37]
> /lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x2ae12eaa5028]
> /opt/ts/lib/libtsutil.so.7(ink_warning(char const*, ...)+0x0)[0x2ae12cb11f4e]
> /opt/ts/lib/libtsutil.so.7(ats_base64_encode(unsigned char const*, unsigned 
> long, char*, unsigned long, unsigned long*)+0x0)[0x2ae12cb0f8e4]
> /opt/ts/bin/traffic_server(HttpTunnel::consumer_handler(int, 
> HttpTunnelConsumer*)+0xcc)[0x63efb2]
> /opt/ts/bin/traffic_server(HttpTunnel::main_handler(int, 
> void*)+0x133)[0x63f9b7]
> /opt/ts/bin/traffic_server(Continuation::handleEvent(int, 
> void*)+0x72)[0x51425a]
> /opt/ts/bin/traffic_server(CacheVC::calluser(int)+0xaa)[0x74f4c8]
> /opt/ts/bin/traffic_server(CacheVC::openWriteMain(int, 
> Event*)+0x3de)[0x759d48]
> /opt/ts/bin/traffic_server(Continuation::handleEvent(int, 
> void*)+0x72)[0x51425a]
> /opt/ts/bin/traffic_server(CacheVC::callcont(int)+0xfc)[0x74f608]
> /opt/ts/bin/traffic_server(CacheVC::openWriteStartDone(int, 
> Event*)+0x8a4)[0x75a9ee]
> /opt/ts/bin/traffic_server(Continuation::handleEvent(int, 
> void*)+0x72)[0x51425a]
> /opt/ts/bin/traffic_server(CacheVC::handleReadDone(int, 
> Event*)+0xd15)[0x72a3e7]
> /opt/ts/bin/traffic_server(Continuation::handleEvent(int, 
> void*)+0x72)[0x51425a]
> /opt/ts/bin/traffic_server(Cache::open_write(Continuation*, ats::CryptoHash 
> const*, HTTPInfo*, long, ats::CryptoHash const*, CacheFragType, char const*, 
> int)+0x6f$
> )[0x75b9df]
> /opt/ts/bin/traffic_server(CacheProcessor::open_write(Continuation*, int, 
> HttpCacheKey const*, bool, HTTPHdr*, HTTPInfo*, long, 
> CacheFragType)+0x129)[0x72eee5]
> /opt/ts/bin/traffic_server(HttpCacheSM::open_write(HttpCacheKey const*, URL*, 
> HTTPHdr*, HTTPInfo*, long, bool, bool)+0x236)[0x5d25a2]
> /opt/ts/bin/traffic_server(HttpSM::do_cache_prepare_action(HttpCacheSM*, 
> HTTPInfo*, bool, bool)+0x352)[0x5f054e]
> /opt/ts/bin/traffic_server(HttpSM::do_cache_prepare_write_transform()+0x69)[0x6013dd]
> /opt/ts/bin/traffic_server(HttpSM::set_next_state()+0x1a27)[0x5fb613]
> /opt/ts/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void 
> (*)(HttpTransact::State*))+0x1ae)[0x5f9be4]
> /opt/ts/bin/traffic_server(HttpSM::state_response_wait_for_transform_read(int,
>  void*)+0x19b)[0x5e35cd]
> /opt/ts/bin/traffic_server(HttpSM::main_handler(int, void*)+0x33a)[0x5e88ac]
> /opt/ts/bin/traffic_server(Continuation::handleEvent(int, 
> void*)+0x72)[0x51425a]
> /opt/ts/bin/traffic_server(TransformTerminus::handle_event(int, 
> void*)+0x2fe)[0x561096]
> /opt/ts/bin/traffic_server(Continuation::handleEvent(int, 
> void*)+0x72)[0x51425a]
> /opt/ts/bin/traffic_server(EThread::process_event(Event*, 
> int)+0x136)[0x7b3eac]
> /opt/ts/bin/traffic_server(EThread::execute()+0xdc)[0x7b410c]
> /opt/ts/bin/traffic_server(main+0x139c)[0x546c99]
> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x2ae12ea8cf45]
> /opt/ts/bin/traffic_server[0x4f9840]
> FATAL: HttpTunnel.cc:1372: failed assertion `c->alive == true`
> {noformat}
> I'm attaching a core dump from a debug build of ATS as well



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

[jira] [Commented] (TS-4468) http.server_session_sharing.match = both unsafe with HTTPS

[Susan Hinrichs (JIRA)]

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

Susan Hinrichs commented on TS-4468:


I am concerned that we would be reducing client-side session reuse in HTTP/2 
case if we get too aggressive in policing SNI matching host field on new 
requests.  

Say the client negotiated a new TLS connection with SNI name set to 
one.bob.come.  It uses HTTP/2 to send a request with HOST set to one.bob.com.  
Then it sends a request with HOST field set to two.bob.com.  one.bob.com and 
two.bob.com resolve to the same address, and the cert is a wildcard for 
*.bob.com, so the client is reusing the same HTTP/2 session.  If we were 
stringent as [~oknet] suggests in bullet 2 we should reject that client 
request, which would reduce the utility of HTTP/2.

[~jered]'s patch only adapts our reuse to meet the requirements of upstream 
HTTP/1.x servers.

At most, if we decided we needed to be stringent in enforcing SNI/host matching 
on client side, I would want the ability to opt out.  

> http.server_session_sharing.match = both unsafe with HTTPS
> --
>
> Key: TS-4468
> URL: https://issues.apache.org/jira/browse/TS-4468
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP, SSL
>Affects Versions: 6.1.1
>Reporter: Jered Floyd
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
> Attachments: TS-4468.patch
>
>  Time Spent: 3h 10m
>  Remaining Estimate: 0h
>
> proxy.config.http.server_session_sharing.match has a default value of "both", 
> which compares IP address, port, and FQDN when determining whether a 
> connection can be reused for further user agent requests.
> The "host" (FQDN) matching does not behave safely when ATS is operating as a 
> reverse proxy.  The compared value is the origin server FQDN after mapping, 
> rather than the initial "Host" target.
> If multiple Hosts map to the same origin server and the scheme is HTTPS, ATS 
> will attempt to reuse a connection that may have an SNI Host that does not 
> match the HTTP Host.  With Apache 2.4 origin servers this results in 400 Bad 
> Request to the user agent.
> PROBLEM REPRODUCTION:
> You can observe this behavior with two mapping rules such as:
> map https://example.com/ https://origin.example.com/
> map https://www.example.com/ https://origin.example.com/
> Non-caching clients alternately fetching URIs from the two targets will see 
> 400 Bad Request responses intermittently.
> WORKAROUND:
> proxy.config.http.server_session_sharing.match should have a default value of 
> "none" when proxy.config.reverse_proxy.enabled is "1"
> SUGGESTED FIXES:
> In order of completeness:
> 1) Do not share server sessions on reverse_proxy requests.
> 2) Do not share server sessions on reverse_proxy requests where scheme is 
> HTTPS.
> 3) Compare target host (SNI host) rather than replacement host when 
> determining if reuse of server session is allowed (when 
> server_session_sharing.match is set to "host" or "both").



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

[jira] [Created] (TS-4882) TCP Fast Open support for SSL server sessions.

[James Peach (JIRA)]

James Peach created TS-4882:
---

 Summary: TCP Fast Open support for SSL server sessions.
 Key: TS-4882
 URL: https://issues.apache.org/jira/browse/TS-4882
 Project: Traffic Server
  Issue Type: Improvement
  Components: Core, SSL
Reporter: James Peach


Add support for using TCP Fast Open on TLS server sessions. This is mainly 
interesting for CONNECT tunnels where we can't use long running persistent 
sessions.



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

[jira] [Updated] (TS-4882) TCP Fast Open support for SSL server sessions.

[James Peach (JIRA)]

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

James Peach updated TS-4882:

 Assignee: James Peach
Fix Version/s: 7.1.0

> TCP Fast Open support for SSL server sessions.
> --
>
> Key: TS-4882
> URL: https://issues.apache.org/jira/browse/TS-4882
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core, SSL
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.1.0
>
>
> Add support for using TCP Fast Open on TLS server sessions. This is mainly 
> interesting for CONNECT tunnels where we can't use long running persistent 
> sessions.



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

[jira] [Work logged] (TS-4866) Remove traffic_cop health checking.

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/1035
  
I like this a lot. As a follow-on Jira, can you look into keeping some 
metrics (published to traffic_manager or simply to stdout on SIGUSR1) to make 
it easier to monitor?


Issue Time Tracking
---

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

> Remove traffic_cop health checking.
> ---
>
> Key: TS-4866
> URL: https://issues.apache.org/jira/browse/TS-4866
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cop
>Affects Versions: 7.0.0
>Reporter: James Peach
>Assignee: Leif Hedstrom
> Fix For: 7.1.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> There is a school of thought that {{traffic_cop}} health checking causes more 
> problems that in solves. Consider whether we should eliminate health checking 
> from {{traffic_cop}}.



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

[GitHub] trafficserver issue #1035: TS-4866: Makes traffic_cop killing optional

[jpeach]

Github user jpeach commented on the issue:

https://github.com/apache/trafficserver/pull/1035
  
I like this a lot. As a follow-on Jira, can you look into keeping some 
metrics (published to traffic_manager or simply to stdout on SIGUSR1) to make 
it easier to monitor?


---
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-4468) http.server_session_sharing.match = both unsafe with HTTPS

[Jered Floyd (JIRA)]

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

Jered Floyd commented on TS-4468:
-

This is discussing when ATS is acting as a server? I haven't addressed this in 
my patch. Apache Server responds with a "400 Bad Request". RFC 6066 doesn't 
seem to offer guidance for the server actions. The current ATS behavior is 
probably acceptable.

> http.server_session_sharing.match = both unsafe with HTTPS
> --
>
> Key: TS-4468
> URL: https://issues.apache.org/jira/browse/TS-4468
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP, SSL
>Affects Versions: 6.1.1
>Reporter: Jered Floyd
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
> Attachments: TS-4468.patch
>
>  Time Spent: 3h 10m
>  Remaining Estimate: 0h
>
> proxy.config.http.server_session_sharing.match has a default value of "both", 
> which compares IP address, port, and FQDN when determining whether a 
> connection can be reused for further user agent requests.
> The "host" (FQDN) matching does not behave safely when ATS is operating as a 
> reverse proxy.  The compared value is the origin server FQDN after mapping, 
> rather than the initial "Host" target.
> If multiple Hosts map to the same origin server and the scheme is HTTPS, ATS 
> will attempt to reuse a connection that may have an SNI Host that does not 
> match the HTTP Host.  With Apache 2.4 origin servers this results in 400 Bad 
> Request to the user agent.
> PROBLEM REPRODUCTION:
> You can observe this behavior with two mapping rules such as:
> map https://example.com/ https://origin.example.com/
> map https://www.example.com/ https://origin.example.com/
> Non-caching clients alternately fetching URIs from the two targets will see 
> 400 Bad Request responses intermittently.
> WORKAROUND:
> proxy.config.http.server_session_sharing.match should have a default value of 
> "none" when proxy.config.reverse_proxy.enabled is "1"
> SUGGESTED FIXES:
> In order of completeness:
> 1) Do not share server sessions on reverse_proxy requests.
> 2) Do not share server sessions on reverse_proxy requests where scheme is 
> HTTPS.
> 3) Compare target host (SNI host) rather than replacement host when 
> determining if reuse of server session is allowed (when 
> server_session_sharing.match is set to "host" or "both").



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

[jira] [Commented] (TS-4468) http.server_session_sharing.match = both unsafe with HTTPS

[Jered Floyd (JIRA)]

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

Jered Floyd commented on TS-4468:
-

> As a client, we should always set SNI upon application layer.  In another 
> word, the SNI of server_vc should always sync with Host header in 
> t_state.hdr_info.server_request.

You are missing the purpose of the patch; there is also the requirement that we 
do not use the server session for a "Host" that does not match the previously 
established SNI.

> http.server_session_sharing.match = both unsafe with HTTPS
> --
>
> Key: TS-4468
> URL: https://issues.apache.org/jira/browse/TS-4468
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP, SSL
>Affects Versions: 6.1.1
>Reporter: Jered Floyd
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
> Attachments: TS-4468.patch
>
>  Time Spent: 3h 10m
>  Remaining Estimate: 0h
>
> proxy.config.http.server_session_sharing.match has a default value of "both", 
> which compares IP address, port, and FQDN when determining whether a 
> connection can be reused for further user agent requests.
> The "host" (FQDN) matching does not behave safely when ATS is operating as a 
> reverse proxy.  The compared value is the origin server FQDN after mapping, 
> rather than the initial "Host" target.
> If multiple Hosts map to the same origin server and the scheme is HTTPS, ATS 
> will attempt to reuse a connection that may have an SNI Host that does not 
> match the HTTP Host.  With Apache 2.4 origin servers this results in 400 Bad 
> Request to the user agent.
> PROBLEM REPRODUCTION:
> You can observe this behavior with two mapping rules such as:
> map https://example.com/ https://origin.example.com/
> map https://www.example.com/ https://origin.example.com/
> Non-caching clients alternately fetching URIs from the two targets will see 
> 400 Bad Request responses intermittently.
> WORKAROUND:
> proxy.config.http.server_session_sharing.match should have a default value of 
> "none" when proxy.config.reverse_proxy.enabled is "1"
> SUGGESTED FIXES:
> In order of completeness:
> 1) Do not share server sessions on reverse_proxy requests.
> 2) Do not share server sessions on reverse_proxy requests where scheme is 
> HTTPS.
> 3) Compare target host (SNI host) rather than replacement host when 
> determining if reuse of server session is allowed (when 
> server_session_sharing.match is set to "host" or "both").



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

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

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/1028
  
@gtenev This looks good. Can you please squash the branch?


Issue Time Tracking
---

Worklog Id: (was: 29402)
Time Spent: 2.5h  (was: 2h 20m)

> 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: 2.5h
>  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)

[GitHub] trafficserver issue #1028: TS-4870 Avoid marking storage offline multiple ti...

[jpeach]

Github user jpeach commented on the issue:

https://github.com/apache/trafficserver/pull/1028
  
@gtenev This looks good. Can you please squash the branch?


---
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-4468) http.server_session_sharing.match = both unsafe with HTTPS

[Alan M. Carroll (JIRA)]

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

Alan M. Carroll commented on TS-4468:
-

A key question would be, what should be done if the second request for a user 
agent session is a different host? Should ATS send an error, or close the 
connection? That would be quite different behavior than the current situation. 
It might also be reasonable to allow changes of host that still match the 
certificate used for the session. E.g. if the selected cert has the FQDNs 
"yahoo.com" and "tumblr.com" it seems reasonable to let the user agent make 
requests against both hosts, but not against "apple.com".

IIRC correctly I discussed this point with Susan while looking at Jered's 
patch. If you check the patch, the session is not matched unless the 
`server_request->get_host()` matches the SNI name of net connection to the 
origin server.

One thing that's not clear is in what situations `t_state.current.server->name` 
is not the same as `server_request.get_host`.

> http.server_session_sharing.match = both unsafe with HTTPS
> --
>
> Key: TS-4468
> URL: https://issues.apache.org/jira/browse/TS-4468
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP, SSL
>Affects Versions: 6.1.1
>Reporter: Jered Floyd
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
> Attachments: TS-4468.patch
>
>  Time Spent: 3h 10m
>  Remaining Estimate: 0h
>
> proxy.config.http.server_session_sharing.match has a default value of "both", 
> which compares IP address, port, and FQDN when determining whether a 
> connection can be reused for further user agent requests.
> The "host" (FQDN) matching does not behave safely when ATS is operating as a 
> reverse proxy.  The compared value is the origin server FQDN after mapping, 
> rather than the initial "Host" target.
> If multiple Hosts map to the same origin server and the scheme is HTTPS, ATS 
> will attempt to reuse a connection that may have an SNI Host that does not 
> match the HTTP Host.  With Apache 2.4 origin servers this results in 400 Bad 
> Request to the user agent.
> PROBLEM REPRODUCTION:
> You can observe this behavior with two mapping rules such as:
> map https://example.com/ https://origin.example.com/
> map https://www.example.com/ https://origin.example.com/
> Non-caching clients alternately fetching URIs from the two targets will see 
> 400 Bad Request responses intermittently.
> WORKAROUND:
> proxy.config.http.server_session_sharing.match should have a default value of 
> "none" when proxy.config.reverse_proxy.enabled is "1"
> SUGGESTED FIXES:
> In order of completeness:
> 1) Do not share server sessions on reverse_proxy requests.
> 2) Do not share server sessions on reverse_proxy requests where scheme is 
> HTTPS.
> 3) Compare target host (SNI host) rather than replacement host when 
> determining if reuse of server session is allowed (when 
> server_session_sharing.match is set to "host" or "both").



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

[jira] [Work logged] (TS-4866) Remove traffic_cop health checking.

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 20/Sep/16 15:08
Start Date: 20/Sep/16 15:08
Worklog Time Spent: 10m 
  Work Description: Github user PSUdaemon commented on a diff in the pull 
request:

https://github.com/apache/trafficserver/pull/1035#discussion_r79634032
  
--- Diff: cmd/traffic_cop/traffic_cop.cc ---
@@ -651,6 +661,26 @@ config_reload_records()
   config_read_int("proxy.config.cluster.rsport", _port, true);
   config_read_int("proxy.config.cop.init_sleep_time", _sleep_time, 
true);
 
+  config_read_int("proxy.config.cop.active_health_checks", , true);
+  // 0 == No servers are killed
+  // 1 == Only traffic_manager can be killed on failure
+  // 2 == Only traffic_server can be killed on failure
+  // 3 == Any failing healthchecks can cause restarts (default)
+  switch (tmp) {
+  case 0:
+active_health_checks = COP_KILL_NONE;
+break;
+  case 1:
+active_health_checks = COP_KILL_MANAGER;
+break;
+  case 2:
+active_health_checks = COP_KILL_SERVER;
+break;
+  default:
+active_health_checks = COP_KILL_SERVER | COP_KILL_MANAGER;
+break;
+  }
+
--- End diff --

What do you think about skipping `tmp` and just saying something like:
```c++
config_read_int("proxy.config.cop.active_health_checks", 
_health_checks, true);
if ((active_health_checks < 0) || (active_health_checks > 3)) {
  active_health_checks = COP_KILL_SERVER | COP_KILL_MANAGER;
}
```


Issue Time Tracking
---

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

> Remove traffic_cop health checking.
> ---
>
> Key: TS-4866
> URL: https://issues.apache.org/jira/browse/TS-4866
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cop
>Affects Versions: 7.0.0
>Reporter: James Peach
>Assignee: Leif Hedstrom
> Fix For: 7.1.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> There is a school of thought that {{traffic_cop}} health checking causes more 
> problems that in solves. Consider whether we should eliminate health checking 
> from {{traffic_cop}}.



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

[GitHub] trafficserver pull request #1035: TS-4866: Makes traffic_cop killing optiona...

[PSUdaemon]

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

https://github.com/apache/trafficserver/pull/1035#discussion_r79634032
  
--- Diff: cmd/traffic_cop/traffic_cop.cc ---
@@ -651,6 +661,26 @@ config_reload_records()
   config_read_int("proxy.config.cluster.rsport", _port, true);
   config_read_int("proxy.config.cop.init_sleep_time", _sleep_time, 
true);
 
+  config_read_int("proxy.config.cop.active_health_checks", , true);
+  // 0 == No servers are killed
+  // 1 == Only traffic_manager can be killed on failure
+  // 2 == Only traffic_server can be killed on failure
+  // 3 == Any failing healthchecks can cause restarts (default)
+  switch (tmp) {
+  case 0:
+active_health_checks = COP_KILL_NONE;
+break;
+  case 1:
+active_health_checks = COP_KILL_MANAGER;
+break;
+  case 2:
+active_health_checks = COP_KILL_SERVER;
+break;
+  default:
+active_health_checks = COP_KILL_SERVER | COP_KILL_MANAGER;
+break;
+  }
+
--- End diff --

What do you think about skipping `tmp` and just saying something like:
```c++
config_read_int("proxy.config.cop.active_health_checks", 
_health_checks, true);
if ((active_health_checks < 0) || (active_health_checks > 3)) {
  active_health_checks = COP_KILL_SERVER | COP_KILL_MANAGER;
}
```


---
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-4334) The cache_range_requests plugin always attempts to modify the cache key.

[James Fang (JIRA)]

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

James Fang commented on TS-4334:


Gancho,

sorry for the delay, i was meaning that this is a invalid bug report according 
to my experiments.

and thanks for your explanation, i am going to convert my current approach 
(which uses cache_range_request ) to yours.

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



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

[jira] [Commented] (TS-4468) http.server_session_sharing.match = both unsafe with HTTPS

[Oknet Xu (JIRA)]

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

Oknet Xu commented on TS-4468:
--

{code}
4789 shared_result = httpSessionManager.acquire_session(this,   
  // state machine
4790
_state.current.server->dst_addr.sa, // ip + port
4791
t_state.current.server->name, // hostname
4792ua_session, 
  // has ptr to bound ua sessions
4793this
  // sm
4794);
{code}

The t_state.current.server->name should not used to acquire server session, It 
is only used to lookup hostdb and get dst_addr.

We should replace it with server_request.get_host() here to obey RFC6066.

> http.server_session_sharing.match = both unsafe with HTTPS
> --
>
> Key: TS-4468
> URL: https://issues.apache.org/jira/browse/TS-4468
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP, SSL
>Affects Versions: 6.1.1
>Reporter: Jered Floyd
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
> Attachments: TS-4468.patch
>
>  Time Spent: 3h 10m
>  Remaining Estimate: 0h
>
> proxy.config.http.server_session_sharing.match has a default value of "both", 
> which compares IP address, port, and FQDN when determining whether a 
> connection can be reused for further user agent requests.
> The "host" (FQDN) matching does not behave safely when ATS is operating as a 
> reverse proxy.  The compared value is the origin server FQDN after mapping, 
> rather than the initial "Host" target.
> If multiple Hosts map to the same origin server and the scheme is HTTPS, ATS 
> will attempt to reuse a connection that may have an SNI Host that does not 
> match the HTTP Host.  With Apache 2.4 origin servers this results in 400 Bad 
> Request to the user agent.
> PROBLEM REPRODUCTION:
> You can observe this behavior with two mapping rules such as:
> map https://example.com/ https://origin.example.com/
> map https://www.example.com/ https://origin.example.com/
> Non-caching clients alternately fetching URIs from the two targets will see 
> 400 Bad Request responses intermittently.
> WORKAROUND:
> proxy.config.http.server_session_sharing.match should have a default value of 
> "none" when proxy.config.reverse_proxy.enabled is "1"
> SUGGESTED FIXES:
> In order of completeness:
> 1) Do not share server sessions on reverse_proxy requests.
> 2) Do not share server sessions on reverse_proxy requests where scheme is 
> HTTPS.
> 3) Compare target host (SNI host) rather than replacement host when 
> determining if reuse of server session is allowed (when 
> server_session_sharing.match is set to "host" or "both").



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

[jira] [Commented] (TS-4468) http.server_session_sharing.match = both unsafe with HTTPS

[Oknet Xu (JIRA)]

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

Oknet Xu commented on TS-4468:
--

By my understand to RFC6066:

  - As a server, we should always verify SNI while it get a new request. (This 
is not yet complete in ATS)
- In another word, the SNI of client_vc should always sync with Host header 
in t_state.hdr_info.client_request.
  - As a client, we should always set SNI upon application layer.
- In another word, the SNI of server_vc should always sync with Host header 
in t_state.hdr_info.server_request.

Thus, we just do acquire server session upon server_request.get_host() is 
enough, and no need to compares SNI.

We just fix the bug if they are not synced.


> http.server_session_sharing.match = both unsafe with HTTPS
> --
>
> Key: TS-4468
> URL: https://issues.apache.org/jira/browse/TS-4468
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP, SSL
>Affects Versions: 6.1.1
>Reporter: Jered Floyd
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
> Attachments: TS-4468.patch
>
>  Time Spent: 3h 10m
>  Remaining Estimate: 0h
>
> proxy.config.http.server_session_sharing.match has a default value of "both", 
> which compares IP address, port, and FQDN when determining whether a 
> connection can be reused for further user agent requests.
> The "host" (FQDN) matching does not behave safely when ATS is operating as a 
> reverse proxy.  The compared value is the origin server FQDN after mapping, 
> rather than the initial "Host" target.
> If multiple Hosts map to the same origin server and the scheme is HTTPS, ATS 
> will attempt to reuse a connection that may have an SNI Host that does not 
> match the HTTP Host.  With Apache 2.4 origin servers this results in 400 Bad 
> Request to the user agent.
> PROBLEM REPRODUCTION:
> You can observe this behavior with two mapping rules such as:
> map https://example.com/ https://origin.example.com/
> map https://www.example.com/ https://origin.example.com/
> Non-caching clients alternately fetching URIs from the two targets will see 
> 400 Bad Request responses intermittently.
> WORKAROUND:
> proxy.config.http.server_session_sharing.match should have a default value of 
> "none" when proxy.config.reverse_proxy.enabled is "1"
> SUGGESTED FIXES:
> In order of completeness:
> 1) Do not share server sessions on reverse_proxy requests.
> 2) Do not share server sessions on reverse_proxy requests where scheme is 
> HTTPS.
> 3) Compare target host (SNI host) rather than replacement host when 
> determining if reuse of server session is allowed (when 
> server_session_sharing.match is set to "host" or "both").



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

[jira] [Commented] (TS-4707) Parent Consistent Hash Selection - add fname and maxdirs options.

[John Rushford (JIRA)]

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

John Rushford commented on TS-4707:
---

Gancho,

This sounds sensible to me, +1





> Parent Consistent Hash Selection - add fname and maxdirs options.
> -
>
> Key: TS-4707
> URL: https://issues.apache.org/jira/browse/TS-4707
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Parent Proxy
>Reporter: Peter Chou
>Assignee: Peter Chou
> Fix For: 7.1.0
>
>  Time Spent: 11.5h
>  Remaining Estimate: 0h
>
> This enhancement adds two options, "fname" and "maxdirs", which can be used 
> to exclude the file-name and some of the directories in the path. The 
> remaining portions of the path are then used as part of the hash computation 
> for selecting among multiple parent caches.
> For our usage, it was desirable from an operational perspective to direct all 
> components of particular sub-tree to a single parent cache (to simplify 
> trouble-shooting, pre-loading, etc.). This can be achieved by excluding the 
> query-string, file-name, and right-most portions of the path from the hash 
> computation.



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

[jira] [Work logged] (TS-4866) Remove traffic_cop health checking.

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Remove traffic_cop health checking.
> ---
>
> Key: TS-4866
> URL: https://issues.apache.org/jira/browse/TS-4866
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cop
>Affects Versions: 7.0.0
>Reporter: James Peach
>Assignee: Leif Hedstrom
> Fix For: 7.1.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> There is a school of thought that {{traffic_cop}} health checking causes more 
> problems that in solves. Consider whether we should eliminate health checking 
> from {{traffic_cop}}.



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

[GitHub] trafficserver issue #1035: TS-4866: Makes traffic_cop killing optional

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1035
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/736/ 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-4866) Remove traffic_cop health checking.

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Remove traffic_cop health checking.
> ---
>
> Key: TS-4866
> URL: https://issues.apache.org/jira/browse/TS-4866
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cop
>Affects Versions: 7.0.0
>Reporter: James Peach
>Assignee: Leif Hedstrom
> Fix For: 7.1.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> There is a school of thought that {{traffic_cop}} health checking causes more 
> problems that in solves. Consider whether we should eliminate health checking 
> from {{traffic_cop}}.



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

[GitHub] trafficserver issue #1035: TS-4866: Makes traffic_cop killing optional

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1035
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/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-4870) Storage can be marked offline multiple times which breaks related metrics

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/1028
  
@jpeach we ok to land this now?


Issue Time Tracking
---

Worklog Id: (was: 29390)
Time Spent: 2h 20m  (was: 2h 10m)

> 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 20m
>  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)

[GitHub] trafficserver issue #1028: TS-4870 Avoid marking storage offline multiple ti...

[zwoop]

Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/1028
  
@jpeach we ok to land this now?


---
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-4866) Remove traffic_cop health checking.

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 20/Sep/16 13:28
Start Date: 20/Sep/16 13:28
Worklog Time Spent: 10m 
  Work Description: GitHub user zwoop opened a pull request:

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

TS-4866: Makes traffic_cop killing optional

This adds a new configuration option, proxy.config.cop.active_health_checks:

 0 - traffic_cop is not allowed to kill any processes
 1 - Only traffic_manager can be killed on failed health checks
 2 - Only traffic_server can be killed on failed health checks
 3 - traffic_server and traffic_manager can be killed on failure (default)

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

$ git pull https://github.com/zwoop/trafficserver TS-4866

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

https://github.com/apache/trafficserver/pull/1035.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 #1035


commit 6c609d4acbf9de7524527f720b68dcd62c982812
Author: Leif Hedstrom 
Date:   2016-09-19T22:19:25Z

TS-4866: Makes traffic_cop killing optional

This adds a new configuration option, proxy.config.cop.active_health_checks:

 0 - traffic_cop is not allowed to kill any processes
 1 - Only traffic_manager can be killed on failed health checks
 2 - Only traffic_server can be killed on failed health checks
 3 - traffic_server and traffic_manager can be killed on failure (default)




Issue Time Tracking
---

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

> Remove traffic_cop health checking.
> ---
>
> Key: TS-4866
> URL: https://issues.apache.org/jira/browse/TS-4866
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cop
>Affects Versions: 7.0.0
>Reporter: James Peach
>Assignee: Leif Hedstrom
> Fix For: 7.1.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> There is a school of thought that {{traffic_cop}} health checking causes more 
> problems that in solves. Consider whether we should eliminate health checking 
> from {{traffic_cop}}.



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

[GitHub] trafficserver pull request #1035: TS-4866: Makes traffic_cop killing optiona...

[zwoop]

GitHub user zwoop opened a pull request:

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

TS-4866: Makes traffic_cop killing optional

This adds a new configuration option, proxy.config.cop.active_health_checks:

 0 - traffic_cop is not allowed to kill any processes
 1 - Only traffic_manager can be killed on failed health checks
 2 - Only traffic_server can be killed on failed health checks
 3 - traffic_server and traffic_manager can be killed on failure (default)

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

$ git pull https://github.com/zwoop/trafficserver TS-4866

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

https://github.com/apache/trafficserver/pull/1035.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 #1035


commit 6c609d4acbf9de7524527f720b68dcd62c982812
Author: Leif Hedstrom 
Date:   2016-09-19T22:19:25Z

TS-4866: Makes traffic_cop killing optional

This adds a new configuration option, proxy.config.cop.active_health_checks:

 0 - traffic_cop is not allowed to kill any processes
 1 - Only traffic_manager can be killed on failed health checks
 2 - Only traffic_server can be killed on failed health checks
 3 - traffic_server and traffic_manager can be killed on failure (default)




---
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-4879) NetVC leaks while hyper emergency occur on check_emergency_throttle()

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

Worklog Id: (was: 29388)
Time Spent: 3h  (was: 2h 50m)

> 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
>  Time Spent: 3h
>  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)

[GitHub] trafficserver issue #1033: TS-4879: Checking con.fd == NO_FD while we get re...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1033
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/735/ 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-4879) NetVC leaks while hyper emergency occur on check_emergency_throttle()

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

Worklog Id: (was: 29386)
Time Spent: 2h 50m  (was: 2h 40m)

> 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
>  Time Spent: 2h 50m
>  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)

[GitHub] trafficserver issue #1033: TS-4879: Checking con.fd == NO_FD while we get re...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1033
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/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.
---