date:20160911

[jira] [Work logged] (TS-3216) Add HPKP (Public Key Pinning Extension for HTTP) support

2016-09-11 Thread ASF GitHub Bot (JIRA)


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

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

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

https://github.com/apache/trafficserver/pull/990#discussion_r78311103
  
--- Diff: iocore/net/SSLUtils.cc ---
@@ -344,6 +361,11 @@ set_context_cert(SSL *ssl)
   ctx = cc->ctx;
   }
 
+  if (cc && cc->hpkp) {
+netvc->hpkp = cc->hpkp;
--- End diff --

Right, it could be problem.


Issue Time Tracking
---

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

> Add HPKP (Public Key Pinning Extension for HTTP) support
> 
>
> Key: TS-3216
> URL: https://issues.apache.org/jira/browse/TS-3216
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: SSL
>Reporter: Masaori Koshiba
>Assignee: Masaori Koshiba
>  Labels: review
> Fix For: 7.0.0
>
> Attachments: hpkp-001.patch, hpkp-002.patch, hpkp-003.patch
>
>  Time Spent: 2h 20m
>  Remaining Estimate: 0h
>
> Add "Public Key Pinning Extension for HTTP" Support in Traffic Server.
> RFC 7469 Public Key Pinning Extension for HTTP
> - https://tools.ietf.org/html/rfc7469



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

[GitHub] trafficserver pull request #990: TS-3216: Add HPKP Support

2016-09-11 Thread masaori335

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

https://github.com/apache/trafficserver/pull/990#discussion_r78311103
  
--- Diff: iocore/net/SSLUtils.cc ---
@@ -344,6 +361,11 @@ set_context_cert(SSL *ssl)
   ctx = cc->ctx;
   }
 
+  if (cc && cc->hpkp) {
+netvc->hpkp = cc->hpkp;
--- End diff --

Right, it could be problem.


---
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-3216) Add HPKP (Public Key Pinning Extension for HTTP) support

2016-09-11 Thread ASF GitHub Bot (JIRA)


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

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

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

https://github.com/apache/trafficserver/pull/990#discussion_r78310891
  
--- Diff: iocore/net/SSLUtils.cc ---
@@ -344,6 +361,11 @@ set_context_cert(SSL *ssl)
   ctx = cc->ctx;
   }
 
+  if (cc && cc->hpkp) {
+netvc->hpkp = cc->hpkp;
--- End diff --

in that case, you are racing against configuration reload and will 
dereference a bad pointer if the transaction takes a long time.


Issue Time Tracking
---

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

> Add HPKP (Public Key Pinning Extension for HTTP) support
> 
>
> Key: TS-3216
> URL: https://issues.apache.org/jira/browse/TS-3216
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: SSL
>Reporter: Masaori Koshiba
>Assignee: Masaori Koshiba
>  Labels: review
> Fix For: 7.0.0
>
> Attachments: hpkp-001.patch, hpkp-002.patch, hpkp-003.patch
>
>  Time Spent: 2h 10m
>  Remaining Estimate: 0h
>
> Add "Public Key Pinning Extension for HTTP" Support in Traffic Server.
> RFC 7469 Public Key Pinning Extension for HTTP
> - https://tools.ietf.org/html/rfc7469



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

[GitHub] trafficserver pull request #990: TS-3216: Add HPKP Support

2016-09-11 Thread jpeach

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

https://github.com/apache/trafficserver/pull/990#discussion_r78310891
  
--- Diff: iocore/net/SSLUtils.cc ---
@@ -344,6 +361,11 @@ set_context_cert(SSL *ssl)
   ctx = cc->ctx;
   }
 
+  if (cc && cc->hpkp) {
+netvc->hpkp = cc->hpkp;
--- End diff --

in that case, you are racing against configuration reload and will 
dereference a bad pointer if the transaction takes a long time.


---
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-3216) Add HPKP (Public Key Pinning Extension for HTTP) support

2016-09-11 Thread ASF GitHub Bot (JIRA)


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

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

Author: ASF GitHub Bot
Created on: 12/Sep/16 02:56
Start Date: 12/Sep/16 02:56
Worklog Time Spent: 10m 
  Work Description: Github user masaori335 commented on a diff in the pull 
request:

https://github.com/apache/trafficserver/pull/990#discussion_r78310812
  
--- Diff: iocore/net/SSLUtils.cc ---
@@ -344,6 +361,11 @@ set_context_cert(SSL *ssl)
   ctx = cc->ctx;
   }
 
+  if (cc && cc->hpkp) {
+netvc->hpkp = cc->hpkp;
--- End diff --

SSLCertContext still owns that. 
Hmm, copying the values of hpkp is only one choice?


Issue Time Tracking
---

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

> Add HPKP (Public Key Pinning Extension for HTTP) support
> 
>
> Key: TS-3216
> URL: https://issues.apache.org/jira/browse/TS-3216
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: SSL
>Reporter: Masaori Koshiba
>Assignee: Masaori Koshiba
>  Labels: review
> Fix For: 7.0.0
>
> Attachments: hpkp-001.patch, hpkp-002.patch, hpkp-003.patch
>
>  Time Spent: 2h
>  Remaining Estimate: 0h
>
> Add "Public Key Pinning Extension for HTTP" Support in Traffic Server.
> RFC 7469 Public Key Pinning Extension for HTTP
> - https://tools.ietf.org/html/rfc7469



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

[GitHub] trafficserver pull request #990: TS-3216: Add HPKP Support

2016-09-11 Thread masaori335

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

https://github.com/apache/trafficserver/pull/990#discussion_r78310812
  
--- Diff: iocore/net/SSLUtils.cc ---
@@ -344,6 +361,11 @@ set_context_cert(SSL *ssl)
   ctx = cc->ctx;
   }
 
+  if (cc && cc->hpkp) {
+netvc->hpkp = cc->hpkp;
--- End diff --

SSLCertContext still owns that. 
Hmm, copying the values of hpkp is only one choice?


---
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-3743) Crash Under Heavy Load and Sending Plugin Error Page

2016-09-11 Thread ASF GitHub Bot (JIRA)


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

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

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

https://github.com/apache/trafficserver/pull/1006
  
Clang format i think 


Issue Time Tracking
---

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

> Crash Under Heavy Load and Sending Plugin Error Page
> 
>
> Key: TS-3743
> URL: https://issues.apache.org/jira/browse/TS-3743
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Sam Baskinger
>Assignee: Nick Kew
>  Labels: review
> Fix For: 7.1.0
>
> Attachments: TS-3743.patch, stacktrace.txt
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> One of the tests done on the [IronBee|http://www.ironbee.com] plugin for 
> TrafficServer is to send a [OWASP 
> Zap|https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project] scan 
> through the proxy at a DokuWiki server. When this is done TrafficServer will 
> crash. The crash is not always at the same point in the scan, but is always 
> when IronBee is generating a custom block page. We've reviewed IronBee and 
> cannot find anything it is doing to provoke the crash.
> The crash is always in {{HttpTunnel::producer_run 
> (this=this@entry=0xaf6021c8, p=p@entry=0xaf6022f8)}} and in all cases 
> {{c->vc}} is invalid.
> Our investigations correlated the crash with HttpSM's 
> {{ua_session->m_active}} being false. More specifically we suspect that 
> {{Http::SM::setup_internal_transfer()}} starts with {{ua_session->m_active}} 
> as true and then closes it -- setting {{ua_session->m_active}} to false -- 
> before {{tunnel.tunnel_run(p)}} is called at the end of the function.
> Please refer to two attachments. The first is a copy of the stack trace we've 
> been working off of. Every crash has a remarkably similar call stack. The 
> second attachment is a patch that is working in our labs.
> This crash also appears in the TrafficServer 4.x code, and the same patch 
> seems to resolve it.



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

[GitHub] trafficserver issue #1006: TS-3743: Avoid crash due to accessing dead sessio...

2016-09-11 Thread zwoop

Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/1006
  
Clang format i think 


---
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 #990: TS-3216: Add HPKP Support

2016-09-11 Thread masaori335

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

https://github.com/apache/trafficserver/pull/990#discussion_r78309860
  
--- Diff: iocore/net/SSLUtils.cc ---
@@ -1866,10 +1934,17 @@ ssl_store_ssl_context(const SSLConfigParams 
*params, SSLCertLookup *lookup, cons
 keyblock = ssl_context_enable_tickets(ctx, NULL);
   }
 
+  // Generate HPKP header if hpkp is enabled.
+  if (sslMultCertSettings.hpkp_enabled >= 0 ? 
sslMultCertSettings.hpkp_enabled : params->hpkp_enabled) {
--- End diff --

It is possible:) `sslMultCertSettings.hpkp_enabled` is initialized by `-1`, 
so settings in ssl_multicert.config (`0` or `1`) is preceded if they're 
written. This is expected behavior, right?


---
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-3216) Add HPKP (Public Key Pinning Extension for HTTP) support

2016-09-11 Thread ASF GitHub Bot (JIRA)


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

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

Author: ASF GitHub Bot
Created on: 12/Sep/16 02:31
Start Date: 12/Sep/16 02:31
Worklog Time Spent: 10m 
  Work Description: Github user masaori335 commented on a diff in the pull 
request:

https://github.com/apache/trafficserver/pull/990#discussion_r78309860
  
--- Diff: iocore/net/SSLUtils.cc ---
@@ -1866,10 +1934,17 @@ ssl_store_ssl_context(const SSLConfigParams 
*params, SSLCertLookup *lookup, cons
 keyblock = ssl_context_enable_tickets(ctx, NULL);
   }
 
+  // Generate HPKP header if hpkp is enabled.
+  if (sslMultCertSettings.hpkp_enabled >= 0 ? 
sslMultCertSettings.hpkp_enabled : params->hpkp_enabled) {
--- End diff --

It is possible:) `sslMultCertSettings.hpkp_enabled` is initialized by `-1`, 
so settings in ssl_multicert.config (`0` or `1`) is preceded if they're 
written. This is expected behavior, right?


Issue Time Tracking
---

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

> Add HPKP (Public Key Pinning Extension for HTTP) support
> 
>
> Key: TS-3216
> URL: https://issues.apache.org/jira/browse/TS-3216
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: SSL
>Reporter: Masaori Koshiba
>Assignee: Masaori Koshiba
>  Labels: review
> Fix For: 7.0.0
>
> Attachments: hpkp-001.patch, hpkp-002.patch, hpkp-003.patch
>
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> Add "Public Key Pinning Extension for HTTP" Support in Traffic Server.
> RFC 7469 Public Key Pinning Extension for HTTP
> - https://tools.ietf.org/html/rfc7469



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

[jira] [Closed] (TS-4747) If the connection of parent is not alive, update the hostdb to mark the server down.

2016-09-11 Thread John Rushford (JIRA)


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

John Rushford closed TS-4747.
-
Resolution: Fixed

fix has been merged

> If the connection of parent is not alive, update the hostdb to mark the 
> server down.
> 
>
> Key: TS-4747
> URL: https://issues.apache.org/jira/browse/TS-4747
> Project: Traffic Server
>  Issue Type: Improvement
>Reporter: xiangdong chen
>Assignee: John Rushford
> Fix For: 7.0.0
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> the parent.config is like this:
> dest_domain=www.cxdtest.com parent=“dnstest1.com:80”;round_bin=strict
> and the dnstest1.com contains two ip:
> 192.168.1.1 （but it was down）
> 192.168.1.2
> if the request go to the parent, and the parent is domain,which contains 
> multi ip. if one ip is down,but we not make the host down ,if the next 
> request is comming, it will choice this ip again. we should make the host 
> down.
> fix code on HttpTransact::handle_response_from_parent(State *s) 
> default: {
> LookingUp_t next_lookup = UNDEFINED_LOOKUP;
> DebugTxn("http_trans", "[hrfp] connection not alive");
> s->state_machine->do_hostdb_update_if_necessary();//added by xdchen, make 
> the host down,line:3606



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

[jira] [Work logged] (TS-4747) If the connection of parent is not alive, update the hostdb to mark the server down.

2016-09-11 Thread ASF GitHub Bot (JIRA)


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

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

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

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


Issue Time Tracking
---

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

> If the connection of parent is not alive, update the hostdb to mark the 
> server down.
> 
>
> Key: TS-4747
> URL: https://issues.apache.org/jira/browse/TS-4747
> Project: Traffic Server
>  Issue Type: Improvement
>Reporter: xiangdong chen
>Assignee: John Rushford
> Fix For: 7.0.0
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> the parent.config is like this:
> dest_domain=www.cxdtest.com parent=“dnstest1.com:80”;round_bin=strict
> and the dnstest1.com contains two ip:
> 192.168.1.1 （but it was down）
> 192.168.1.2
> if the request go to the parent, and the parent is domain,which contains 
> multi ip. if one ip is down,but we not make the host down ,if the next 
> request is comming, it will choice this ip again. we should make the host 
> down.
> fix code on HttpTransact::handle_response_from_parent(State *s) 
> default: {
> LookingUp_t next_lookup = UNDEFINED_LOOKUP;
> DebugTxn("http_trans", "[hrfp] connection not alive");
> s->state_machine->do_hostdb_update_if_necessary();//added by xdchen, make 
> the host down,line:3606



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

[GitHub] trafficserver pull request #984: TS-4747: if the connection of parent is not...

2016-09-11 Thread jrushford

Github user jrushford closed the pull request at:

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


---
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-analyzer #2623

2016-09-11 Thread jenkins

See 

Changes:

[Masaori Koshiba] TS-4759: Fix stream states management

[amc] TS-1882: Check for unrecognized configuration values. This closes #971.

--
[...truncated 5337 lines...]
reading sources... [ 69%] developer-guide/api/functions/TSVIONDoneGet.en
reading sources... [ 69%] developer-guide/api/functions/TSVIONDoneSet.en
reading sources... [ 70%] developer-guide/api/functions/TSVIONTodoGet.en
reading sources... [ 70%] developer-guide/api/functions/TSVIOReaderGet.en
reading sources... [ 70%] developer-guide/api/functions/TSVIOReenable.en
reading sources... [ 70%] developer-guide/api/functions/TSVIOVConnGet.en
reading sources... [ 70%] developer-guide/api/functions/TSfclose.en
reading sources... [ 71%] developer-guide/api/functions/TSfflush.en
reading sources... [ 71%] developer-guide/api/functions/TSfgets.en
reading sources... [ 71%] developer-guide/api/functions/TSfopen.en
reading sources... [ 71%] developer-guide/api/functions/TSfread.en
reading sources... [ 72%] developer-guide/api/functions/TSfwrite.en
reading sources... [ 72%] developer-guide/api/functions/TSmalloc.en
reading sources... [ 72%] developer-guide/api/functions/index.en
reading sources... [ 72%] developer-guide/api/index.en
reading sources... [ 72%] developer-guide/api/types/TSCacheDataType.en
reading sources... [ 73%] developer-guide/api/types/TSCacheError.en
reading sources... [ 73%] developer-guide/api/types/TSCacheLookupResult.en
reading sources... [ 73%] developer-guide/api/types/TSCacheScanResult.en
reading sources... [ 73%] developer-guide/api/types/TSEvent.en
reading sources... [ 74%] developer-guide/api/types/TSFetchWakeUpOptions.en
reading sources... [ 74%] developer-guide/api/types/TSHttpHookID.en
reading sources... [ 74%] developer-guide/api/types/TSHttpStatus.en
reading sources... [ 74%] developer-guide/api/types/TSHttpType.en
reading sources... [ 74%] developer-guide/api/types/TSIOBuffersSizeIndex.en
reading sources... [ 75%] developer-guide/api/types/TSLifecycleHookID.en
reading sources... [ 75%] developer-guide/api/types/TSLookingUpType.en
reading sources... [ 75%] developer-guide/api/types/TSMilestonesType.en
reading sources... [ 75%] developer-guide/api/types/TSOverridableConfigKey.en
reading sources... [ 75%] developer-guide/api/types/TSParseResult.en
reading sources... [ 76%] developer-guide/api/types/TSRecordAccessType.en
reading sources... [ 76%] developer-guide/api/types/TSRecordCheckType.en
reading sources... [ 76%] developer-guide/api/types/TSRecordDataType.en
reading sources... [ 76%] developer-guide/api/types/TSRecordModeType.en
reading sources... [ 77%] developer-guide/api/types/TSRecordPersistType.en
reading sources... [ 77%] developer-guide/api/types/TSRecordType.en
reading sources... [ 77%] developer-guide/api/types/TSRecordUpdateType.en
reading sources... [ 77%] developer-guide/api/types/TSReturnCode.en
reading sources... [ 77%] developer-guide/api/types/TSSDKVersion.en
reading sources... [ 78%] 
developer-guide/api/types/TSServerSessionSharingMatchType.en
reading sources... [ 78%] 
developer-guide/api/types/TSServerSessionSharingPoolType.en
reading sources... [ 78%] developer-guide/api/types/TSServerState.en
reading sources... [ 78%] developer-guide/api/types/TSStatPeristence.en
reading sources... [ 79%] developer-guide/api/types/TSStatSync.en
reading sources... [ 79%] developer-guide/api/types/TSThreadPool.en
reading sources... [ 79%] developer-guide/api/types/TSUuid.en
reading sources... [ 79%] developer-guide/api/types/TSVConnCloseFlags.en
reading sources... [ 79%] developer-guide/api/types/index.en
reading sources... [ 80%] developer-guide/architecture/api-functions.en
reading sources... [ 80%] developer-guide/architecture/architecture.en
reading sources... [ 80%] developer-guide/architecture/consistency.en
reading sources... [ 80%] developer-guide/architecture/data-structures.en
reading sources... [ 81%] developer-guide/architecture/index.en
reading sources... [ 81%] developer-guide/architecture/ram-cache.en
reading sources... [ 81%] developer-guide/architecture/tiered-storage.en
reading sources... [ 81%] developer-guide/config-vars.en
reading sources... [ 81%] developer-guide/continuous-integration/index.en
reading sources... [ 82%] developer-guide/contributing/index.en
reading sources... [ 82%] developer-guide/debugging/core-dump-analysis.en
reading sources... [ 82%] developer-guide/debugging/debug-builds.en
reading sources... [ 82%] developer-guide/debugging/debug-tags.en
reading sources... [ 83%] developer-guide/debugging/index.en
reading sources... [ 83%] developer-guide/debugging/memory-leaks.en
reading sources... [ 83%] developer-guide/debugging/profiling.en
reading sources... [ 83%] developer-guide/debugging/using-tsassert.en
reading sources... [ 83%] developer-guide/documentation/adding-domains.en
reading sources... [ 84%] developer-guide/documentation/building.en
reading

[jira] [Resolved] (TS-4759) Intermittent HTTP/2 failure with h2spec (6.4.)

2016-09-11 Thread Masaori Koshiba (JIRA)


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

Masaori Koshiba resolved TS-4759.
-
Resolution: Fixed

> Intermittent HTTP/2 failure with h2spec (6.4.)
> --
>
> Key: TS-4759
> URL: https://issues.apache.org/jira/browse/TS-4759
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Masaori Koshiba
>Assignee: Masaori Koshiba
> Fix For: 7.0.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> {noformat}
>   6.4. RST_STREAM
> × Sends a RST_STREAM frame with a length other than 4 octets
>   - The endpoint MUST respond with a connection error of type 
> FRAME_SIZE_ERROR.
> Expected: GOAWAY frame (ErrorCode: FRAME_SIZE_ERROR)
>   Connection close
>   Actual: DATA frame (Length: 0, Flags: 1)
> {noformat}
> ( h2spec v1.4.2 )



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

[jira] [Work logged] (TS-4759) Intermittent HTTP/2 failure with h2spec (6.4.)

2016-09-11 Thread ASF GitHub Bot (JIRA)


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

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

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

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


Issue Time Tracking
---

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

> Intermittent HTTP/2 failure with h2spec (6.4.)
> --
>
> Key: TS-4759
> URL: https://issues.apache.org/jira/browse/TS-4759
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Masaori Koshiba
>Assignee: Masaori Koshiba
> Fix For: 7.0.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> {noformat}
>   6.4. RST_STREAM
> × Sends a RST_STREAM frame with a length other than 4 octets
>   - The endpoint MUST respond with a connection error of type 
> FRAME_SIZE_ERROR.
> Expected: GOAWAY frame (ErrorCode: FRAME_SIZE_ERROR)
>   Connection close
>   Actual: DATA frame (Length: 0, Flags: 1)
> {noformat}
> ( h2spec v1.4.2 )



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

[GitHub] trafficserver pull request #999: TS-4759: Fix stream states management

2016-09-11 Thread masaori335

Github user masaori335 closed the pull request at:

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


---
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-3743) Crash Under Heavy Load and Sending Plugin Error Page

2016-09-11 Thread ASF GitHub Bot (JIRA)


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

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

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

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



Issue Time Tracking
---

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

> Crash Under Heavy Load and Sending Plugin Error Page
> 
>
> Key: TS-3743
> URL: https://issues.apache.org/jira/browse/TS-3743
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Sam Baskinger
>Assignee: Nick Kew
>  Labels: review
> Fix For: 7.1.0
>
> Attachments: TS-3743.patch, stacktrace.txt
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> One of the tests done on the [IronBee|http://www.ironbee.com] plugin for 
> TrafficServer is to send a [OWASP 
> Zap|https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project] scan 
> through the proxy at a DokuWiki server. When this is done TrafficServer will 
> crash. The crash is not always at the same point in the scan, but is always 
> when IronBee is generating a custom block page. We've reviewed IronBee and 
> cannot find anything it is doing to provoke the crash.
> The crash is always in {{HttpTunnel::producer_run 
> (this=this@entry=0xaf6021c8, p=p@entry=0xaf6022f8)}} and in all cases 
> {{c->vc}} is invalid.
> Our investigations correlated the crash with HttpSM's 
> {{ua_session->m_active}} being false. More specifically we suspect that 
> {{Http::SM::setup_internal_transfer()}} starts with {{ua_session->m_active}} 
> as true and then closes it -- setting {{ua_session->m_active}} to false -- 
> before {{tunnel.tunnel_run(p)}} is called at the end of the function.
> Please refer to two attachments. The first is a copy of the stack trace we've 
> been working off of. Every crash has a remarkably similar call stack. The 
> second attachment is a patch that is working in our labs.
> This crash also appears in the TrafficServer 4.x code, and the same patch 
> seems to resolve it.



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

[GitHub] trafficserver issue #1006: TS-3743: Avoid crash due to accessing dead sessio...

2016-09-11 Thread atsci

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1006
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/778/ 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-3743) Crash Under Heavy Load and Sending Plugin Error Page

2016-09-11 Thread ASF GitHub Bot (JIRA)


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

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

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

https://github.com/apache/trafficserver/pull/1006
  
Linux build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/674/ for details.
 



Issue Time Tracking
---

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

> Crash Under Heavy Load and Sending Plugin Error Page
> 
>
> Key: TS-3743
> URL: https://issues.apache.org/jira/browse/TS-3743
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Sam Baskinger
>Assignee: Nick Kew
>  Labels: review
> Fix For: 7.1.0
>
> Attachments: TS-3743.patch, stacktrace.txt
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> One of the tests done on the [IronBee|http://www.ironbee.com] plugin for 
> TrafficServer is to send a [OWASP 
> Zap|https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project] scan 
> through the proxy at a DokuWiki server. When this is done TrafficServer will 
> crash. The crash is not always at the same point in the scan, but is always 
> when IronBee is generating a custom block page. We've reviewed IronBee and 
> cannot find anything it is doing to provoke the crash.
> The crash is always in {{HttpTunnel::producer_run 
> (this=this@entry=0xaf6021c8, p=p@entry=0xaf6022f8)}} and in all cases 
> {{c->vc}} is invalid.
> Our investigations correlated the crash with HttpSM's 
> {{ua_session->m_active}} being false. More specifically we suspect that 
> {{Http::SM::setup_internal_transfer()}} starts with {{ua_session->m_active}} 
> as true and then closes it -- setting {{ua_session->m_active}} to false -- 
> before {{tunnel.tunnel_run(p)}} is called at the end of the function.
> Please refer to two attachments. The first is a copy of the stack trace we've 
> been working off of. Every crash has a remarkably similar call stack. The 
> second attachment is a patch that is working in our labs.
> This crash also appears in the TrafficServer 4.x code, and the same patch 
> seems to resolve it.



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

[GitHub] trafficserver issue #1006: TS-3743: Avoid crash due to accessing dead sessio...

2016-09-11 Thread atsci

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1006
  
Linux build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/674/ 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 #1006: TS-3743: Avoid crash due to accessing dead...

2016-09-11 Thread niq

GitHub user niq opened a pull request:

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

TS-3743: Avoid crash due to accessing dead session under load

Patch by Sam Baskinger

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

$ git pull https://github.com/niq/trafficserver TS-3743

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

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


commit a30ed2c69250a0d092efdb0b931bd5f007d2aa93
Author: Nick Kew 
Date:   2016-09-11T22:55:06Z

TS-3743: Avoid crash due to accessing dead session under load
Patch by Sam Baskinger




---
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-3743) Crash Under Heavy Load and Sending Plugin Error Page

2016-09-11 Thread ASF GitHub Bot (JIRA)


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

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

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

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

TS-3743: Avoid crash due to accessing dead session under load

Patch by Sam Baskinger

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

$ git pull https://github.com/niq/trafficserver TS-3743

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

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


commit a30ed2c69250a0d092efdb0b931bd5f007d2aa93
Author: Nick Kew 
Date:   2016-09-11T22:55:06Z

TS-3743: Avoid crash due to accessing dead session under load
Patch by Sam Baskinger




Issue Time Tracking
---

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

> Crash Under Heavy Load and Sending Plugin Error Page
> 
>
> Key: TS-3743
> URL: https://issues.apache.org/jira/browse/TS-3743
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Sam Baskinger
>Assignee: Nick Kew
>  Labels: review
> Fix For: 7.1.0
>
> Attachments: TS-3743.patch, stacktrace.txt
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> One of the tests done on the [IronBee|http://www.ironbee.com] plugin for 
> TrafficServer is to send a [OWASP 
> Zap|https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project] scan 
> through the proxy at a DokuWiki server. When this is done TrafficServer will 
> crash. The crash is not always at the same point in the scan, but is always 
> when IronBee is generating a custom block page. We've reviewed IronBee and 
> cannot find anything it is doing to provoke the crash.
> The crash is always in {{HttpTunnel::producer_run 
> (this=this@entry=0xaf6021c8, p=p@entry=0xaf6022f8)}} and in all cases 
> {{c->vc}} is invalid.
> Our investigations correlated the crash with HttpSM's 
> {{ua_session->m_active}} being false. More specifically we suspect that 
> {{Http::SM::setup_internal_transfer()}} starts with {{ua_session->m_active}} 
> as true and then closes it -- setting {{ua_session->m_active}} to false -- 
> before {{tunnel.tunnel_run(p)}} is called at the end of the function.
> Please refer to two attachments. The first is a copy of the stack trace we've 
> been working off of. Every crash has a remarkably similar call stack. The 
> second attachment is a patch that is working in our labs.
> This crash also appears in the TrafficServer 4.x code, and the same patch 
> seems to resolve it.



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

[jira] [Work logged] (TS-4555) C++ API takes a transaction argument without allocating it

2016-09-11 Thread ASF GitHub Bot (JIRA)


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

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

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

https://github.com/apache/trafficserver/pull/967#discussion_r78303393
  
--- Diff: lib/atscppapi/src/utils_internal.cc ---
@@ -99,6 +97,8 @@ handleTransactionEvents(TSCont cont, TSEvent event, void 
*edata)
 void
 setupTransactionManagement()
 {
+  // Reserve a transaction slot
+  TSAssert(TS_SUCCESS == TSHttpArgIndexReserve("atscppapi", "ATS CPP API", 
_STORAGE_INDEX));
--- End diff --

Right, you would use ``TSHttpArgIndexNameLookup``.


Issue Time Tracking
---

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

> C++ API takes a transaction argument without allocating it
> --
>
> Key: TS-4555
> URL: https://issues.apache.org/jira/browse/TS-4555
> Project: Traffic Server
>  Issue Type: Bug
>  Components: CPP API
>Reporter: James Peach
>Assignee: Alan M. Carroll
> Fix For: 7.0.0
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> {code}
> Transaction &
> utils::internal::getTransaction(TSHttpTxn ats_txn_handle)
> {
>   Transaction *transaction = static_cast *>(TSHttpTxnArgGet(ats_txn_handle, TRANSACTION_STORAGE_INDEX));
>   if (!transaction) {
> transaction = new Transaction(static_cast(ats_txn_handle));
> LOG_DEBUG("Created new transaction object at %p for ats pointer %p", 
> transaction, ats_txn_handle);
> TSHttpTxnArgSet(ats_txn_handle, TRANSACTION_STORAGE_INDEX, transaction);
>   }
>   return *transaction;
> }
> {code}
> {{TRANSACTION_STORAGE_INDEX}} is hardcoded constant that is not allocated by 
> {{TSHttpArgIndexReserve}}, so it is subject to collisions with other plugins.



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

[GitHub] trafficserver pull request #967: TS-4555: Make CPP API use a reserved transa...

2016-09-11 Thread jpeach

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

https://github.com/apache/trafficserver/pull/967#discussion_r78303393
  
--- Diff: lib/atscppapi/src/utils_internal.cc ---
@@ -99,6 +97,8 @@ handleTransactionEvents(TSCont cont, TSEvent event, void 
*edata)
 void
 setupTransactionManagement()
 {
+  // Reserve a transaction slot
+  TSAssert(TS_SUCCESS == TSHttpArgIndexReserve("atscppapi", "ATS CPP API", 
_STORAGE_INDEX));
--- End diff --

Right, you would use ``TSHttpArgIndexNameLookup``.


---
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-analyzer #2622

2016-09-11 Thread jenkins

See 

Changes:

[amc] TS-4555: Make CPP API use a reserved transaction arg. This closes #967.

--
[...truncated 5334 lines...]
reading sources... [ 69%] developer-guide/api/functions/TSVIONBytesGet.en
reading sources... [ 69%] developer-guide/api/functions/TSVIONBytesSet.en
reading sources... [ 69%] developer-guide/api/functions/TSVIONDoneGet.en
reading sources... [ 70%] developer-guide/api/functions/TSVIONDoneSet.en
reading sources... [ 70%] developer-guide/api/functions/TSVIONTodoGet.en
reading sources... [ 70%] developer-guide/api/functions/TSVIOReaderGet.en
reading sources... [ 70%] developer-guide/api/functions/TSVIOReenable.en
reading sources... [ 70%] developer-guide/api/functions/TSVIOVConnGet.en
reading sources... [ 71%] developer-guide/api/functions/TSfclose.en
reading sources... [ 71%] developer-guide/api/functions/TSfflush.en
reading sources... [ 71%] developer-guide/api/functions/TSfgets.en
reading sources... [ 71%] developer-guide/api/functions/TSfopen.en
reading sources... [ 72%] developer-guide/api/functions/TSfread.en
reading sources... [ 72%] developer-guide/api/functions/TSfwrite.en
reading sources... [ 72%] developer-guide/api/functions/TSmalloc.en
reading sources... [ 72%] developer-guide/api/functions/index.en
reading sources... [ 72%] developer-guide/api/index.en
reading sources... [ 73%] developer-guide/api/types/TSCacheDataType.en
reading sources... [ 73%] developer-guide/api/types/TSCacheError.en
reading sources... [ 73%] developer-guide/api/types/TSCacheLookupResult.en
reading sources... [ 73%] developer-guide/api/types/TSCacheScanResult.en
reading sources... [ 74%] developer-guide/api/types/TSEvent.en
reading sources... [ 74%] developer-guide/api/types/TSFetchWakeUpOptions.en
reading sources... [ 74%] developer-guide/api/types/TSHttpHookID.en
reading sources... [ 74%] developer-guide/api/types/TSHttpStatus.en
reading sources... [ 74%] developer-guide/api/types/TSHttpType.en
reading sources... [ 75%] developer-guide/api/types/TSIOBuffersSizeIndex.en
reading sources... [ 75%] developer-guide/api/types/TSLifecycleHookID.en
reading sources... [ 75%] developer-guide/api/types/TSLookingUpType.en
reading sources... [ 75%] developer-guide/api/types/TSMilestonesType.en
reading sources... [ 76%] developer-guide/api/types/TSOverridableConfigKey.en
reading sources... [ 76%] developer-guide/api/types/TSParseResult.en
reading sources... [ 76%] developer-guide/api/types/TSRecordAccessType.en
reading sources... [ 76%] developer-guide/api/types/TSRecordCheckType.en
reading sources... [ 76%] developer-guide/api/types/TSRecordDataType.en
reading sources... [ 77%] developer-guide/api/types/TSRecordModeType.en
reading sources... [ 77%] developer-guide/api/types/TSRecordPersistType.en
reading sources... [ 77%] developer-guide/api/types/TSRecordType.en
reading sources... [ 77%] developer-guide/api/types/TSRecordUpdateType.en
reading sources... [ 78%] developer-guide/api/types/TSReturnCode.en
reading sources... [ 78%] developer-guide/api/types/TSSDKVersion.en
reading sources... [ 78%] 
developer-guide/api/types/TSServerSessionSharingMatchType.en
reading sources... [ 78%] 
developer-guide/api/types/TSServerSessionSharingPoolType.en
reading sources... [ 78%] developer-guide/api/types/TSServerState.en
reading sources... [ 79%] developer-guide/api/types/TSThreadPool.en
reading sources... [ 79%] developer-guide/api/types/TSUuid.en
reading sources... [ 79%] developer-guide/api/types/TSVConnCloseFlags.en
reading sources... [ 79%] developer-guide/api/types/index.en
reading sources... [ 80%] developer-guide/architecture/api-functions.en
reading sources... [ 80%] developer-guide/architecture/architecture.en
reading sources... [ 80%] developer-guide/architecture/consistency.en
reading sources... [ 80%] developer-guide/architecture/data-structures.en
reading sources... [ 80%] developer-guide/architecture/index.en
reading sources... [ 81%] developer-guide/architecture/ram-cache.en
reading sources... [ 81%] developer-guide/architecture/tiered-storage.en
reading sources... [ 81%] developer-guide/config-vars.en
reading sources... [ 81%] developer-guide/continuous-integration/index.en
reading sources... [ 82%] developer-guide/contributing/index.en
reading sources... [ 82%] developer-guide/debugging/core-dump-analysis.en
reading sources... [ 82%] developer-guide/debugging/debug-builds.en
reading sources... [ 82%] developer-guide/debugging/debug-tags.en
reading sources... [ 82%] developer-guide/debugging/index.en
reading sources... [ 83%] developer-guide/debugging/memory-leaks.en
reading sources... [ 83%] developer-guide/debugging/profiling.en
reading sources... [ 83%] developer-guide/debugging/using-tsassert.en
reading sources... [ 83%] developer-guide/documentation/adding-domains.en
reading sources... [ 84%] developer-guide/documentation/building.en
reading sources... [ 84%]

[jira] [Resolved] (TS-1882) ATS doesn't warn about unknown config items

2016-09-11 Thread Alan M. Carroll (JIRA)


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

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

> ATS doesn't warn about unknown config items
> ---
>
> Key: TS-1882
> URL: https://issues.apache.org/jira/browse/TS-1882
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Configuration
>Reporter: Ebrahim Mohammadi
>Assignee: Alan M. Carroll
> Fix For: 7.0.0
>
>  Time Spent: 3.5h
>  Remaining Estimate: 0h
>
> Apache Traffic Server doesn't warn about unknown configuration file items. It 
> can cause huge confusions, specially in case of trying to get features of a 
> newer version to work on an older installed version by mistake, as I found 
> out the hard way!



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

[jira] [Work logged] (TS-1882) ATS doesn't warn about unknown config items

2016-09-11 Thread ASF GitHub Bot (JIRA)


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

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

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

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


Issue Time Tracking
---

Worklog Id: (was: 28752)
Time Spent: 3.5h  (was: 3h 20m)

> ATS doesn't warn about unknown config items
> ---
>
> Key: TS-1882
> URL: https://issues.apache.org/jira/browse/TS-1882
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Configuration
>Reporter: Ebrahim Mohammadi
>Assignee: Alan M. Carroll
> Fix For: 7.0.0
>
>  Time Spent: 3.5h
>  Remaining Estimate: 0h
>
> Apache Traffic Server doesn't warn about unknown configuration file items. It 
> can cause huge confusions, specially in case of trying to get features of a 
> newer version to work on an older installed version by mistake, as I found 
> out the hard way!



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

[GitHub] trafficserver pull request #971: TS-1882: Check for unrecognized configurati...

2016-09-11 Thread asfgit

Github user asfgit closed the pull request at:

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


---
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-2987) TS API to identify if the client connection is via HTTP/2

2016-09-11 Thread Alan M. Carroll (JIRA)


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

Alan M. Carroll updated TS-2987:

Assignee: Susan Hinrichs  (was: Alan M. Carroll)

> TS API to identify if the client connection is via HTTP/2
> -
>
> Key: TS-2987
> URL: https://issues.apache.org/jira/browse/TS-2987
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HTTP/2, TS API
>Reporter: Sudheer Vinukonda
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> Need a TS API for the plugins to be able to identify whether the incoming 
> client connection is via SPDY. The plugins would like to relay this 
> information over to the origins which may return a different kind of response 
> for a spdy client vs a non-spdy client. For example, the origins may skip the 
> optimizations such as domain-sharding which work well with non-spdy clients, 
> but, would cancel the benefits of spdy to multiplex requests. 
> The proposed API (the sole credit goes to [~amc]) checks the plugin_tag to 
> identify if the connection is spdy. In the future, the HttpSM data structure 
> may be enhanced to store a spdy indicator.



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

[jira] [Resolved] (TS-4155) HTTP header parse should error on LF field terminator

2016-09-11 Thread Alan M. Carroll (JIRA)


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

Alan M. Carroll resolved TS-4155.
-
   Resolution: Won't Fix
Fix Version/s: (was: 7.0.0)

There has been much discussion about this. My final view is that this is not a 
bug, this is expected behavior. The concensus was that rather than being 
strict, ATS should follow the recommendation in the HTTPbis specification and 
allow a single LF to terminate a field.

> HTTP header parse should error on LF field terminator
> -
>
> Key: TS-4155
> URL: https://issues.apache.org/jira/browse/TS-4155
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HTTP
>Reporter: Alan M. Carroll
>Assignee: Alan M. Carroll
>  Labels: incompatible
>
> If an HTTP request header terminates one of the fields with just a line feed 
> ATS will parse it as if the header terminated at the end of the previous 
> line. I think I understand why this was done but in my opinion that is 
> obsolete and ATS should instead generate a parse error. Such a request in my 
> reading clearly violates the HTTP specification and should therefore generate 
> a parse error. Another option is to treat the line feed as a proper line 
> terminator which, while I think would be better than the current behavior 
> would still be wrong. General usage has advanced sufficiently that ATS should 
> require properly formatted request headers.



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

[jira] [Resolved] (TS-4555) C++ API takes a transaction argument without allocating it

2016-09-11 Thread Alan M. Carroll (JIRA)


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

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

> C++ API takes a transaction argument without allocating it
> --
>
> Key: TS-4555
> URL: https://issues.apache.org/jira/browse/TS-4555
> Project: Traffic Server
>  Issue Type: Bug
>  Components: CPP API
>Reporter: James Peach
>Assignee: Alan M. Carroll
> Fix For: 7.0.0
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> {code}
> Transaction &
> utils::internal::getTransaction(TSHttpTxn ats_txn_handle)
> {
>   Transaction *transaction = static_cast *>(TSHttpTxnArgGet(ats_txn_handle, TRANSACTION_STORAGE_INDEX));
>   if (!transaction) {
> transaction = new Transaction(static_cast(ats_txn_handle));
> LOG_DEBUG("Created new transaction object at %p for ats pointer %p", 
> transaction, ats_txn_handle);
> TSHttpTxnArgSet(ats_txn_handle, TRANSACTION_STORAGE_INDEX, transaction);
>   }
>   return *transaction;
> }
> {code}
> {{TRANSACTION_STORAGE_INDEX}} is hardcoded constant that is not allocated by 
> {{TSHttpArgIndexReserve}}, so it is subject to collisions with other plugins.



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

[jira] [Work logged] (TS-4555) C++ API takes a transaction argument without allocating it

2016-09-11 Thread ASF GitHub Bot (JIRA)


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

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

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

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


Issue Time Tracking
---

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

> C++ API takes a transaction argument without allocating it
> --
>
> Key: TS-4555
> URL: https://issues.apache.org/jira/browse/TS-4555
> Project: Traffic Server
>  Issue Type: Bug
>  Components: CPP API
>Reporter: James Peach
>Assignee: Alan M. Carroll
> Fix For: 7.0.0
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> {code}
> Transaction &
> utils::internal::getTransaction(TSHttpTxn ats_txn_handle)
> {
>   Transaction *transaction = static_cast *>(TSHttpTxnArgGet(ats_txn_handle, TRANSACTION_STORAGE_INDEX));
>   if (!transaction) {
> transaction = new Transaction(static_cast(ats_txn_handle));
> LOG_DEBUG("Created new transaction object at %p for ats pointer %p", 
> transaction, ats_txn_handle);
> TSHttpTxnArgSet(ats_txn_handle, TRANSACTION_STORAGE_INDEX, transaction);
>   }
>   return *transaction;
> }
> {code}
> {{TRANSACTION_STORAGE_INDEX}} is hardcoded constant that is not allocated by 
> {{TSHttpArgIndexReserve}}, so it is subject to collisions with other plugins.



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

[GitHub] trafficserver pull request #967: TS-4555: Make CPP API use a reserved transa...

2016-09-11 Thread asfgit

Github user asfgit closed the pull request at:

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


---
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-4555) C++ API takes a transaction argument without allocating it

2016-09-11 Thread ASF GitHub Bot (JIRA)


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

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

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

https://github.com/apache/trafficserver/pull/967#discussion_r78302162
  
--- Diff: lib/atscppapi/src/utils_internal.cc ---
@@ -99,6 +97,8 @@ handleTransactionEvents(TSCont cont, TSEvent event, void 
*edata)
 void
 setupTransactionManagement()
 {
+  // Reserve a transaction slot
+  TSAssert(TS_SUCCESS == TSHttpArgIndexReserve("atscppapi", "ATS CPP API", 
_STORAGE_INDEX));
--- End diff --

I think the problem with `GlobalPlugin::GlobalPlugin` is it can be called 
multiple times, once for each global plugin defined. I think only one 
transaction arg is required, though, for all global plugins.


Issue Time Tracking
---

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

> C++ API takes a transaction argument without allocating it
> --
>
> Key: TS-4555
> URL: https://issues.apache.org/jira/browse/TS-4555
> Project: Traffic Server
>  Issue Type: Bug
>  Components: CPP API
>Reporter: James Peach
>Assignee: Alan M. Carroll
> Fix For: 7.0.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> {code}
> Transaction &
> utils::internal::getTransaction(TSHttpTxn ats_txn_handle)
> {
>   Transaction *transaction = static_cast *>(TSHttpTxnArgGet(ats_txn_handle, TRANSACTION_STORAGE_INDEX));
>   if (!transaction) {
> transaction = new Transaction(static_cast(ats_txn_handle));
> LOG_DEBUG("Created new transaction object at %p for ats pointer %p", 
> transaction, ats_txn_handle);
> TSHttpTxnArgSet(ats_txn_handle, TRANSACTION_STORAGE_INDEX, transaction);
>   }
>   return *transaction;
> }
> {code}
> {{TRANSACTION_STORAGE_INDEX}} is hardcoded constant that is not allocated by 
> {{TSHttpArgIndexReserve}}, so it is subject to collisions with other plugins.



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

[GitHub] trafficserver pull request #967: TS-4555: Make CPP API use a reserved transa...

2016-09-11 Thread SolidWallOfCode

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

https://github.com/apache/trafficserver/pull/967#discussion_r78302162
  
--- Diff: lib/atscppapi/src/utils_internal.cc ---
@@ -99,6 +97,8 @@ handleTransactionEvents(TSCont cont, TSEvent event, void 
*edata)
 void
 setupTransactionManagement()
 {
+  // Reserve a transaction slot
+  TSAssert(TS_SUCCESS == TSHttpArgIndexReserve("atscppapi", "ATS CPP API", 
_STORAGE_INDEX));
--- End diff --

I think the problem with `GlobalPlugin::GlobalPlugin` is it can be called 
multiple times, once for each global plugin defined. I think only one 
transaction arg is required, though, for all global plugins.


---
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-4834) Expose bad disk and disk access failures

2016-09-11 Thread ASF GitHub Bot (JIRA)


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

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

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

https://github.com/apache/trafficserver/pull/996#discussion_r78302115
  
--- Diff: iocore/cache/Cache.cc ---
@@ -2070,6 +2070,16 @@ AIO_Callback_handler::handle_disk_failure(int /* 
event ATS_UNUSED */, void *data
   for (; disk_no < gndisks; disk_no++) {
 CacheDisk *d = gdisks[disk_no];
 
+/* find the Vol instance needed for updating per-volume stats by 
CACHE_INCREMENT_DYN_STAT */
+Vol *vol;
--- End diff --

If there are multiple volumes for the same physical disk / file descriptor, 
does this just find the first one?


Issue Time Tracking
---

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

> Expose bad disk and disk access failures
> 
>
> Key: TS-4834
> URL: https://issues.apache.org/jira/browse/TS-4834
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Cache, Metrics
>Reporter: Gancho Tenev
>Assignee: Gancho Tenev
> Fix For: 7.0.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> We would like to monitor low-level disk access failures and disks marked by 
> ATS as bad.
> I have a patch that exposes that information through
> {code}
> proxy.process.cache.disk_error_count 10
> proxy.process.cache.disk_bad_count 5
> {code}
> and the following tests/shows how it would work...
> Start ATS with 2 disks and tail {{diags.log}}
> {code}
> $ cat etc/trafficserver/storage.config
> /dev/sdb
> /dev/sdc
> $ tail -f var/log/trafficserver/diags.log
> [Sep  8 12:18:48.149] Server {0x2b5f43db54c0} NOTE: traffic server running
> [Sep  8 12:18:48.198] Server {0x2b5f44654700} NOTE: cache enabled
> {code}
> Check related metrics and observe all 0s
> {code}
> $ ./bin/traffic_ctl metric match "proxy.process.cache*.disk.*" 
> "proxy.process.cache.*(read|write).failure" 
> "proxy.process.http.cache_(read|write)_errors"
> proxy.process.cache.disk_error_count 0
> proxy.process.cache.disk_bad_count 0
> proxy.process.cache.read.failure 0
> proxy.process.cache.write.failure 0
> proxy.process.cache.volume_0.read.failure 0
> proxy.process.cache.volume_0.write.failure 0
> proxy.process.http.cache_write_errors 0
> proxy.process.http.cache_read_errors 0
> {code}
> Now using your favorite hard disk failure injection tool inject 10 failures, 
> by setting both disks used by this setup {{/dev/sdb}} and {{/dev/sdc}} to 
> fail all reads. And shoot 5 requests causing 10 failed reads.
> {code}
> $ for i in 1 2 3 4 5; do curl -x 127.0.0.1:80 http://example.com/1 -o 
> /dev/null -s; done
> $ tail -f var/log/trafficserver/diags.log
> [Sep  8 12:19:09.758] Server {0x2aaab4302700} WARNING: cache disk operation 
> failed READ -1 0
> [Sep  8 12:19:09.759] Server {0x2aaac0100700} WARNING: cache disk operation 
> failed READ -1 0
> [Sep  8 12:19:09.764] Server {0x2b5f43db54c0} WARNING: Error accessing Disk 
> /dev/sdb [1/10]
> [Sep  8 12:19:09.769] Server {0x2b5f44654700} WARNING: Error accessing Disk 
> /dev/sdb [2/10]
> [Sep  8 12:19:09.785] Server {0x2aaac0100700} WARNING: cache disk operation 
> failed READ -1 0
> [Sep  8 12:19:09.786] Server {0x2aaab4302700} WARNING: cache disk operation 
> failed READ -1 0
> [Sep  8 12:19:09.791] Server {0x2b5f44654700} WARNING: Error accessing Disk 
> /dev/sdb [3/10]
> [Sep  8 12:19:09.796] Server {0x2b5f43db54c0} WARNING: Error accessing Disk 
> /dev/sdb [4/10]
> [Sep  8 12:19:09.812] Server {0x2aaab4100700} WARNING: cache disk operation 
> failed READ -1 0
> [Sep  8 12:19:09.813] Server {0x2aaacc100700} WARNING: cache disk operation 
> failed READ -1 0
> [Sep  8 12:19:09.817] Server {0x2b5f43db54c0} WARNING: Error accessing Disk 
> /dev/sdb [5/10]
> [Sep  8 12:19:09.823] Server {0x2b5f44654700} WARNING: Error accessing Disk 
> /dev/sdb [6/10]
> [Sep  8 12:19:09.843] Server {0x2aaacc302700} WARNING: cache disk operation 
> failed READ -1 0
> [Sep  8 12:19:09.844] Server {0x2aaad8100700} WARNING: cache disk operation 
> failed READ -1 0
> [Sep  8 12:19:09.847] Server {0x2b5f44654700} WARNING: Error accessing Disk 
> /dev/sdb [7/10]
> [Sep  8 12:19:09.854] Server {0x2b5f43db54c0} WARNING: Error accessing Disk 
> /dev/sdb [8/10]
> [Sep  8 12:19:09.874] Server {0x2aaacc302700} WARNING: cache disk operation 
> failed READ -1 0
> [Sep  8 12:19:09.875] Server {0x2aaad8100700} WARNING: cache disk operation 
> failed READ -1 0
> [Sep  8 12:19:09.880] Server {0x2b5f43db54c0} WARNING: Error

[GitHub] trafficserver pull request #996: TS-4834 Expose bad disk and disk access fai...

2016-09-11 Thread SolidWallOfCode

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

https://github.com/apache/trafficserver/pull/996#discussion_r78302115
  
--- Diff: iocore/cache/Cache.cc ---
@@ -2070,6 +2070,16 @@ AIO_Callback_handler::handle_disk_failure(int /* 
event ATS_UNUSED */, void *data
   for (; disk_no < gndisks; disk_no++) {
 CacheDisk *d = gdisks[disk_no];
 
+/* find the Vol instance needed for updating per-volume stats by 
CACHE_INCREMENT_DYN_STAT */
+Vol *vol;
--- End diff --

If there are multiple volumes for the same physical disk / file descriptor, 
does this just find the first one?


---
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-4849) Promote TsBuffer.h to external API

2016-09-11 Thread James Peach (JIRA)


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

James Peach commented on TS-4849:
-

Seems like there are standard C++ library equivalents for most of this?

> Promote TsBuffer.h to external API
> --
>
> Key: TS-4849
> URL: https://issues.apache.org/jira/browse/TS-4849
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: CPP API
>Reporter: Alan M. Carroll
>Assignee: Brian Geffon
>
> It would be handy for many plugin tasks to have these classes available. It 
> is a header only implementation and so requires no linkage making it easy to 
> promote.



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

[jira] [Created] (TS-4849) Promote TsBuffer.h to external API

2016-09-11 Thread Alan M. Carroll (JIRA)

Alan M. Carroll created TS-4849:
---

 Summary: Promote TsBuffer.h to external API
 Key: TS-4849
 URL: https://issues.apache.org/jira/browse/TS-4849
 Project: Traffic Server
  Issue Type: Improvement
  Components: CPP API
Reporter: Alan M. Carroll
Assignee: Brian Geffon


It would be handy for many plugin tasks to have these classes available. It is 
a header only implementation and so requires no linkage making it easy to 
promote.



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

[GitHub] trafficserver issue #753: TS-4705: Proposal: NetVC Context

2016-09-11 Thread atsci

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/753
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/777/ 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-4705) Proposal: NetVC Context

2016-09-11 Thread ASF GitHub Bot (JIRA)


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

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

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

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



Issue Time Tracking
---

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

> 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.0.0
>
>  Time Spent: 2.5h
>  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] [Work logged] (TS-4705) Proposal: NetVC Context

2016-09-11 Thread ASF GitHub Bot (JIRA)


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

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

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

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



Issue Time Tracking
---

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

> 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.0.0
>
>  Time Spent: 2h 20m
>  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)

[GitHub] trafficserver issue #753: TS-4705: Proposal: NetVC Context

2016-09-11 Thread atsci

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/753
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/673/ 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-4522) Should signal SM with EVENT_ERROR on error in write_to_net_io(), EVENT_EOS only signaled from read_from_net()

2016-09-11 Thread ASF GitHub Bot (JIRA)


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

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

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

https://github.com/apache/trafficserver/pull/701
  
@jpeach Could you please review this PR? I think this is final version.


Issue Time Tracking
---

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

> Should signal SM with EVENT_ERROR on error in write_to_net_io(), EVENT_EOS 
> only signaled from read_from_net()
> -
>
> Key: TS-4522
> URL: https://issues.apache.org/jira/browse/TS-4522
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, Network
>Reporter: Oknet Xu
>Assignee: Oknet Xu
> Fix For: 7.0.0
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> The 1st Problem:
> The "r" saved return value from write(). The "r == 0" or "!r" is not means 
> EOS. 
> Because of on a closed socket fd: 
> - read(socketfd) return 0
> - write(socketfd) return EPIPE
> In the write_to_net_io, we check the return value of write() with the same 
> way to read().
> {code}
> if (!r || r == -ECONNRESET) {
> {code}
> It is a copy & paste bug.
> The bug makes no VC_EVENT_EOS callbacked while write_to_net_io, but 
> VC_EVENT_ERROR instead. 
> full code here:
> {code}
>   int64_t r = vc->load_buffer_and_write(towrite, buf, total_written, needs);
>   if (total_written > 0) {
> NET_SUM_DYN_STAT(net_write_bytes_stat, total_written);
> s->vio.ndone += total_written;
>   }
>   // check for errors
>   if (r <= 0) { // if the socket was not ready,add to WaitList
> if (r == -EAGAIN || r == -ENOTCONN) {
>   NET_INCREMENT_DYN_STAT(net_calls_to_write_nodata_stat);
>   if ((needs & EVENTIO_WRITE) == EVENTIO_WRITE) {
> vc->write.triggered = 0;
> nh->write_ready_list.remove(vc);
> write_reschedule(nh, vc);
>   }
>   if ((needs & EVENTIO_READ) == EVENTIO_READ) {
> vc->read.triggered = 0;
> nh->read_ready_list.remove(vc);
> read_reschedule(nh, vc);
>   }
>   return;
> }
> if (!r || r == -ECONNRESET) {
>   vc->write.triggered = 0;
>   write_signal_done(VC_EVENT_EOS, nh, vc);
>   return;
> }
> vc->write.triggered = 0;
> write_signal_error(nh, vc, (int)-total_written);
> return;
> {code}
> The 2nd Problem:
> In the iocore/net/I_NetVConnection.h, the comments for do_io_write:
> {code}
> 257   /**
> 258 Initiates write. Thread-safe, may be called when not handling
> 259 an event from the NetVConnection, or the NetVConnection creation
> 260 callback.
> 261 
> 262 Callbacks: non-reentrant, c's lock taken during callbacks.
> 263 
> 264 
> 265   
> 266 c->handleEvent(VC_EVENT_WRITE_READY, vio)
> 267 signifies data has written from the reader or there are no 
> bytes available for the reader to write.
> 268   
> 269   
> 270 c->handleEvent(VC_EVENT_WRITE_COMPLETE, vio)
> 271 signifies the amount of data indicated by nbytes has been 
> read from the buffer
> 272   
> 273   
> 274 c->handleEvent(VC_EVENT_ERROR, vio)
> 275 signified that error occured during write.
> 276   
> 277 
> 278 
> 279 The vio returned during callbacks is the same as the one returned
> 280 by do_io_write(). The vio can be changed only during call backs
> 281 from the vconnection. The vconnection deallocates the reader
> 282 when it is destroyed.
> 283 
> 284 @param c continuation to be called back after (partial) write
> 285 @param nbytes no of bytes to write, if unknown msut be set to 
> INT64_MAX
> 286 @param buf source of data
> 287 @param owner
> 288 @return vio pointer
> 289 
> 290   */
> 291   virtual VIO *do_io_write(Continuation *c, int64_t nbytes, 
> IOBufferReader *buf, bool owner = false) = 0;
> {code}
> Only 3 Events was introduced
> - VC_EVENT_WRITE_READY
> - VC_EVENT_WRITE_COMPLETE
> - VC_EVENT_ERROR
> The code {code}write_signal_done(VC_EVENT_EOS, nh, vc);{code} should not be 
> here (write_to_net_io).



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

[GitHub] trafficserver issue #701: TS-4522: Should signal SM with EVENT_ERROR on erro...

2016-09-11 Thread oknet

Github user oknet commented on the issue:

https://github.com/apache/trafficserver/pull/701
  
@jpeach Could you please review this PR? I think this is final version.


---
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-4843) traffic_cop does not seem to honor proxy.config.cop.init_sleep_time after traffic_server restart

2016-09-11 Thread Leif Hedstrom (JIRA)


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

Leif Hedstrom commented on TS-4843:
---

I suspect this is a side effect of TS-4721. What is probably happening is that 
traffic_server crashes (or gets killed), traffic_manager dies with it, and we 
don't seem to use this sleep when that happens?

> traffic_cop does not seem to honor proxy.config.cop.init_sleep_time after 
> traffic_server restart
> 
>
> Key: TS-4843
> URL: https://issues.apache.org/jira/browse/TS-4843
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cop
>Reporter: Leif Hedstrom
> Fix For: 7.0.0
>
>
> We set proxy.config.cop.init_sleep_time to a pretty high value (a few 
> minutes), which helps normal restart (where we start traffic_cop and the rest 
> of the tool chain). However, when traffic_server dies (or is killed by _cop), 
> the restart does not seem to use the proxy.config.cop.init_sleep_time any 
> more.
> The end result is that traffic_cop will now kill traffic_server after two 
> failed (10s each) healthchecks, and that goes on over and over again.



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

47 matches

Mail list logo