[jira] [Work logged] (TS-4026) Remove clustering feature in 7.0.0 release

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

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

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

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

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



Issue Time Tracking
---

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

> Remove clustering feature in 7.0.0 release 
> ---
>
> Key: TS-4026
> URL: https://issues.apache.org/jira/browse/TS-4026
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Clustering
>Reporter: Bryan Call
>Assignee: Phil Sorber
>  Labels: incompatible
> Fix For: 7.0.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> From the ATS Fall Summit 2015 no one said they where using the clustering 
> feature.



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


[GitHub] trafficserver issue #966: TS-4026: Remove Clustering

2016-09-05 Thread atsci
Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/966
  
Linux build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/601/ 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-4026) Remove clustering feature in 7.0.0 release

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

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

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

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

https://github.com/apache/trafficserver/pull/966
  
FreeBSD build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/706/ for details.
 



Issue Time Tracking
---

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

> Remove clustering feature in 7.0.0 release 
> ---
>
> Key: TS-4026
> URL: https://issues.apache.org/jira/browse/TS-4026
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Clustering
>Reporter: Bryan Call
>Assignee: Phil Sorber
>  Labels: incompatible
> Fix For: 7.0.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> From the ATS Fall Summit 2015 no one said they where using the clustering 
> feature.



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


[GitHub] trafficserver issue #966: TS-4026: Remove Clustering

2016-09-05 Thread atsci
Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/966
  
FreeBSD build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/706/ for details.
 



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


[GitHub] trafficserver issue #966: TS-4026: Remove Clustering

2016-09-05 Thread zwoop
Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/966
  
[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-4026) Remove clustering feature in 7.0.0 release

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

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

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

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

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


Issue Time Tracking
---

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

> Remove clustering feature in 7.0.0 release 
> ---
>
> Key: TS-4026
> URL: https://issues.apache.org/jira/browse/TS-4026
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Clustering
>Reporter: Bryan Call
>Assignee: Phil Sorber
>  Labels: incompatible
> Fix For: 7.0.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> From the ATS Fall Summit 2015 no one said they where using the clustering 
> feature.



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


Jenkins build is back to normal : clang-analyzer #2599

2016-09-05 Thread jenkins
See 



[jira] [Work logged] (TS-4026) Remove clustering feature in 7.0.0 release

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

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

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

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

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



Issue Time Tracking
---

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

> Remove clustering feature in 7.0.0 release 
> ---
>
> Key: TS-4026
> URL: https://issues.apache.org/jira/browse/TS-4026
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Clustering
>Reporter: Bryan Call
>Assignee: Phil Sorber
>  Labels: incompatible
> Fix For: 7.0.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> From the ATS Fall Summit 2015 no one said they where using the clustering 
> feature.



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


[GitHub] trafficserver issue #966: TS-4026: Remove Clustering

2016-09-05 Thread atsci
Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/966
  
FreeBSD build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/705/ 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-4026) Remove clustering feature in 7.0.0 release

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

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

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

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

https://github.com/apache/trafficserver/pull/966
  
FreeBSD build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/705/ for details.
 



Issue Time Tracking
---

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

> Remove clustering feature in 7.0.0 release 
> ---
>
> Key: TS-4026
> URL: https://issues.apache.org/jira/browse/TS-4026
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Clustering
>Reporter: Bryan Call
>Assignee: Phil Sorber
>  Labels: incompatible
> Fix For: 7.0.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> From the ATS Fall Summit 2015 no one said they where using the clustering 
> feature.



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


[GitHub] trafficserver issue #966: TS-4026: Remove Clustering

2016-09-05 Thread atsci
Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/966
  
Linux build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/600/ 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.
---


Build failed in Jenkins: clang-analyzer #2598

2016-09-05 Thread jenkins
See 

Changes:

[Jari Alhonen] TS-4584: Resource leak, CID 1254818 and 1254809

[James Peach] TS-4769: Add a trivial TSSslServerContextCreate regression test.

[James Peach] Build fix.

--
[...truncated 5336 lines...]
reading sources... [ 69%] developer-guide/api/functions/TSVIOMutexGet.en
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... [ 71%] 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... [ 73%] 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... [ 75%] 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/TSSslVConnOp.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... [ 80%] 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... [ 82%] 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%] 

[jira] [Work logged] (TS-4026) Remove clustering feature in 7.0.0 release

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

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

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

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

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

TS-4026: Remove Clustering

This is a first rough cut. I haven't removed the actual clustering dirs to 
keep the diff readable, but I am sure something important got ripped out here. 
Please take a look and lets figure this out.

We might also just want to disable clustering with no way to enable, but I 
really wanted to take a crack at this and see if we can remove it now instead 
of leaving that code in there to compile all the time.

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

$ git pull https://github.com/PSUdaemon/trafficserver remove_clustering

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

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


commit fc9e7b13ffe68995e150fbd37906724124a869ca
Author: Phil Sorber 
Date:   2016-09-05T03:12:29Z

TS-4026: Remove Clustering




Issue Time Tracking
---

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

> Remove clustering feature in 7.0.0 release 
> ---
>
> Key: TS-4026
> URL: https://issues.apache.org/jira/browse/TS-4026
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Clustering
>Reporter: Bryan Call
>Assignee: Phil Sorber
>  Labels: incompatible
> Fix For: 7.0.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> From the ATS Fall Summit 2015 no one said they where using the clustering 
> feature.



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


[GitHub] trafficserver pull request #966: TS-4026: Remove Clustering

2016-09-05 Thread PSUdaemon
GitHub user PSUdaemon opened a pull request:

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

TS-4026: Remove Clustering

This is a first rough cut. I haven't removed the actual clustering dirs to 
keep the diff readable, but I am sure something important got ripped out here. 
Please take a look and lets figure this out.

We might also just want to disable clustering with no way to enable, but I 
really wanted to take a crack at this and see if we can remove it now instead 
of leaving that code in there to compile all the time.

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

$ git pull https://github.com/PSUdaemon/trafficserver remove_clustering

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

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


commit fc9e7b13ffe68995e150fbd37906724124a869ca
Author: Phil Sorber 
Date:   2016-09-05T03:12:29Z

TS-4026: Remove Clustering




---
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-4532) Static type checking for time units

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

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

Alan M. Carroll commented on TS-4532:
-

Forget ``NumericType``, I think ``std::chrono`` is overall more useful. I have 
[pull request|https://github.com/SolidWallOfCode/trafficserver/pull/1] with a 
partial conversion to start a discussion.

> Static type checking for time units
> ---
>
> Key: TS-4532
> URL: https://issues.apache.org/jira/browse/TS-4532
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: James Peach
>Assignee: Alan M. Carroll
> Fix For: 7.0.0
>
>  Time Spent: 3.5h
>  Remaining Estimate: 0h
>
> Since the various time units {{ink_time_t}}, {{time_t}}, {{ink_hrtime}} are 
> all typedefs of C integral types, it is very hard to ensure that units are 
> being converted and compared correctly.
> Consider wrapping these in trivial classes as part of making the time APIs 
> more straightforward. Alternatively, if we move to {{C++11}} investigate 
> {{std::chrono}} for this.



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


[jira] [Comment Edited] (TS-4532) Static type checking for time units

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

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

Alan M. Carroll edited comment on TS-4532 at 9/6/16 3:05 AM:
-

Forget {{NumericType}}, I think {{std::chrono}} is overall more useful. I have 
[pull request|https://github.com/SolidWallOfCode/trafficserver/pull/1] with a 
partial conversion to start a discussion.


was (Author: amc):
Forget ``NumericType``, I think ``std::chrono`` is overall more useful. I have 
[pull request|https://github.com/SolidWallOfCode/trafficserver/pull/1] with a 
partial conversion to start a discussion.

> Static type checking for time units
> ---
>
> Key: TS-4532
> URL: https://issues.apache.org/jira/browse/TS-4532
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: James Peach
>Assignee: Alan M. Carroll
> Fix For: 7.0.0
>
>  Time Spent: 3.5h
>  Remaining Estimate: 0h
>
> Since the various time units {{ink_time_t}}, {{time_t}}, {{ink_hrtime}} are 
> all typedefs of C integral types, it is very hard to ensure that units are 
> being converted and compared correctly.
> Consider wrapping these in trivial classes as part of making the time APIs 
> more straightforward. Alternatively, if we move to {{C++11}} investigate 
> {{std::chrono}} for this.



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


Jenkins build is back to normal : in_tree-master #2187

2016-09-05 Thread jenkins
See 



Jenkins build is back to normal : out_of_tree-master #1960

2016-09-05 Thread jenkins
See 



[GitHub] trafficserver pull request #965: TS-4532: Static type checking for time.

2016-09-05 Thread SolidWallOfCode
Github user SolidWallOfCode closed the pull request at:

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


---
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-4532) Static type checking for time units

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

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

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

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

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


Issue Time Tracking
---

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

> Static type checking for time units
> ---
>
> Key: TS-4532
> URL: https://issues.apache.org/jira/browse/TS-4532
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: James Peach
>Assignee: Alan M. Carroll
> Fix For: 7.0.0
>
>  Time Spent: 3.5h
>  Remaining Estimate: 0h
>
> Since the various time units {{ink_time_t}}, {{time_t}}, {{ink_hrtime}} are 
> all typedefs of C integral types, it is very hard to ensure that units are 
> being converted and compared correctly.
> Consider wrapping these in trivial classes as part of making the time APIs 
> more straightforward. Alternatively, if we move to {{C++11}} investigate 
> {{std::chrono}} for this.



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


Build failed in Jenkins: out_of_tree-master #1959

2016-09-05 Thread jenkins
See 

Changes:

[Jari Alhonen] TS-4584: Resource leak, CID 1254818 and 1254809

[James Peach] TS-4769: Add a trivial TSSslServerContextCreate regression test.

--
[...truncated 2361 lines...]
mv -f $depbase.Tpo $depbase.Po
depbase=`echo HttpTransactCache.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
ccache c++ -DHAVE_CONFIG_H -I. -I../../../proxy/http -I../../lib  
-I../../../iocore/eventsystem -I../../../iocore/net -I../../../iocore/aio 
-I../../../iocore/hostdb -I../../../iocore/cache -I../../../iocore/cluster 
-I../../../iocore/utils -I../../../iocore/dns -I../../../proxy/api/ts 
-I../../../proxy -I../../../lib -I../../../lib/records -I../../../mgmt 
-I../../../mgmt/utils -I../../../proxy/hdrs -I../../../proxy/shared 
-I../../../proxy/http/remap -I../../../proxy/logging -I../../../proxy/http2 
-Dlinux -D_LARGEFILE64_SOURCE=1 -D_COMPILE64BIT_SOURCE=1 -D_GNU_SOURCE 
-D_REENTRANT -D__STDC_LIMIT_MACROS=1 -D__STDC_FORMAT_MACROS=1 
-DOPENSSL_NO_SSL_INTERN  -std=c++11 -g -pipe -Wall -O3 
-feliminate-unused-debug-symbols -fno-strict-aliasing -Werror 
-Wno-invalid-offsetof -mcx16 -MT HttpTransactCache.o -MD -MP -MF $depbase.Tpo 
-c -o HttpTransactCache.o ../../../proxy/http/HttpTransactCache.cc &&\
mv -f $depbase.Tpo $depbase.Po
depbase=`echo HttpTransactHeaders.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
ccache c++ -DHAVE_CONFIG_H -I. -I../../../proxy/http -I../../lib  
-I../../../iocore/eventsystem -I../../../iocore/net -I../../../iocore/aio 
-I../../../iocore/hostdb -I../../../iocore/cache -I../../../iocore/cluster 
-I../../../iocore/utils -I../../../iocore/dns -I../../../proxy/api/ts 
-I../../../proxy -I../../../lib -I../../../lib/records -I../../../mgmt 
-I../../../mgmt/utils -I../../../proxy/hdrs -I../../../proxy/shared 
-I../../../proxy/http/remap -I../../../proxy/logging -I../../../proxy/http2 
-Dlinux -D_LARGEFILE64_SOURCE=1 -D_COMPILE64BIT_SOURCE=1 -D_GNU_SOURCE 
-D_REENTRANT -D__STDC_LIMIT_MACROS=1 -D__STDC_FORMAT_MACROS=1 
-DOPENSSL_NO_SSL_INTERN  -std=c++11 -g -pipe -Wall -O3 
-feliminate-unused-debug-symbols -fno-strict-aliasing -Werror 
-Wno-invalid-offsetof -mcx16 -MT HttpTransactHeaders.o -MD -MP -MF $depbase.Tpo 
-c -o HttpTransactHeaders.o ../../../proxy/http/HttpTransactHeaders.cc &&\
mv -f $depbase.Tpo $depbase.Po
depbase=`echo HttpTunnel.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
ccache c++ -DHAVE_CONFIG_H -I. -I../../../proxy/http -I../../lib  
-I../../../iocore/eventsystem -I../../../iocore/net -I../../../iocore/aio 
-I../../../iocore/hostdb -I../../../iocore/cache -I../../../iocore/cluster 
-I../../../iocore/utils -I../../../iocore/dns -I../../../proxy/api/ts 
-I../../../proxy -I../../../lib -I../../../lib/records -I../../../mgmt 
-I../../../mgmt/utils -I../../../proxy/hdrs -I../../../proxy/shared 
-I../../../proxy/http/remap -I../../../proxy/logging -I../../../proxy/http2 
-Dlinux -D_LARGEFILE64_SOURCE=1 -D_COMPILE64BIT_SOURCE=1 -D_GNU_SOURCE 
-D_REENTRANT -D__STDC_LIMIT_MACROS=1 -D__STDC_FORMAT_MACROS=1 
-DOPENSSL_NO_SSL_INTERN  -std=c++11 -g -pipe -Wall -O3 
-feliminate-unused-debug-symbols -fno-strict-aliasing -Werror 
-Wno-invalid-offsetof -mcx16 -MT HttpTunnel.o -MD -MP -MF $depbase.Tpo -c -o 
HttpTunnel.o ../../../proxy/http/HttpTunnel.cc &&\
mv -f $depbase.Tpo $depbase.Po
depbase=`echo HttpUpdateSM.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
ccache c++ -DHAVE_CONFIG_H -I. -I../../../proxy/http -I../../lib  
-I../../../iocore/eventsystem -I../../../iocore/net -I../../../iocore/aio 
-I../../../iocore/hostdb -I../../../iocore/cache -I../../../iocore/cluster 
-I../../../iocore/utils -I../../../iocore/dns -I../../../proxy/api/ts 
-I../../../proxy -I../../../lib -I../../../lib/records -I../../../mgmt 
-I../../../mgmt/utils -I../../../proxy/hdrs -I../../../proxy/shared 
-I../../../proxy/http/remap -I../../../proxy/logging -I../../../proxy/http2 
-Dlinux -D_LARGEFILE64_SOURCE=1 -D_COMPILE64BIT_SOURCE=1 -D_GNU_SOURCE 
-D_REENTRANT -D__STDC_LIMIT_MACROS=1 -D__STDC_FORMAT_MACROS=1 
-DOPENSSL_NO_SSL_INTERN  -std=c++11 -g -pipe -Wall -O3 
-feliminate-unused-debug-symbols -fno-strict-aliasing -Werror 
-Wno-invalid-offsetof -mcx16 -MT HttpUpdateSM.o -MD -MP -MF $depbase.Tpo -c -o 
HttpUpdateSM.o ../../../proxy/http/HttpUpdateSM.cc &&\
mv -f $depbase.Tpo $depbase.Po
depbase=`echo HttpUpdateTester.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
ccache c++ -DHAVE_CONFIG_H -I. -I../../../proxy/http -I../../lib  
-I../../../iocore/eventsystem -I../../../iocore/net -I../../../iocore/aio 
-I../../../iocore/hostdb -I../../../iocore/cache -I../../../iocore/cluster 
-I../../../iocore/utils -I../../../iocore/dns -I../../../proxy/api/ts 
-I../../../proxy -I../../../lib -I../../../lib/records -I../../../mgmt 
-I../../../mgmt/utils -I../../../proxy/hdrs -I../../../proxy/shared 
-I../../../proxy/http/remap -I../../../proxy/logging -I../../../proxy/http2 
-Dlinux -D_LARGEFILE64_SOURCE=1 -D_COMPILE64BIT_SOURCE=1 

Build failed in Jenkins: in_tree-master #2186

2016-09-05 Thread jenkins
See 

Changes:

[Jari Alhonen] TS-4584: Resource leak, CID 1254818 and 1254809

[James Peach] TS-4769: Add a trivial TSSslServerContextCreate regression test.

--
[...truncated 2360 lines...]
mv -f $depbase.Tpo $depbase.Po
depbase=`echo HttpTransactCache.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
ccache c++ -DHAVE_CONFIG_H -I. -I../../lib  -I../../iocore/eventsystem 
-I../../iocore/net -I../../iocore/aio -I../../iocore/hostdb 
-I../../iocore/cache -I../../iocore/cluster -I../../iocore/utils 
-I../../iocore/dns -I../../proxy/api/ts -I../../proxy -I../../lib 
-I../../lib/records -I../../mgmt -I../../mgmt/utils -I../../proxy/hdrs 
-I../../proxy/shared -I../../proxy/http/remap -I../../proxy/logging 
-I../../proxy/http2 -Dlinux -D_LARGEFILE64_SOURCE=1 -D_COMPILE64BIT_SOURCE=1 
-D_GNU_SOURCE -D_REENTRANT -D__STDC_LIMIT_MACROS=1 -D__STDC_FORMAT_MACROS=1 
-DOPENSSL_NO_SSL_INTERN  -std=c++11 -g -pipe -Wall -O3 
-feliminate-unused-debug-symbols -fno-strict-aliasing -Werror 
-Wno-invalid-offsetof -mcx16 -MT HttpTransactCache.o -MD -MP -MF $depbase.Tpo 
-c -o HttpTransactCache.o HttpTransactCache.cc &&\
mv -f $depbase.Tpo $depbase.Po
depbase=`echo HttpTransactHeaders.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
ccache c++ -DHAVE_CONFIG_H -I. -I../../lib  -I../../iocore/eventsystem 
-I../../iocore/net -I../../iocore/aio -I../../iocore/hostdb 
-I../../iocore/cache -I../../iocore/cluster -I../../iocore/utils 
-I../../iocore/dns -I../../proxy/api/ts -I../../proxy -I../../lib 
-I../../lib/records -I../../mgmt -I../../mgmt/utils -I../../proxy/hdrs 
-I../../proxy/shared -I../../proxy/http/remap -I../../proxy/logging 
-I../../proxy/http2 -Dlinux -D_LARGEFILE64_SOURCE=1 -D_COMPILE64BIT_SOURCE=1 
-D_GNU_SOURCE -D_REENTRANT -D__STDC_LIMIT_MACROS=1 -D__STDC_FORMAT_MACROS=1 
-DOPENSSL_NO_SSL_INTERN  -std=c++11 -g -pipe -Wall -O3 
-feliminate-unused-debug-symbols -fno-strict-aliasing -Werror 
-Wno-invalid-offsetof -mcx16 -MT HttpTransactHeaders.o -MD -MP -MF $depbase.Tpo 
-c -o HttpTransactHeaders.o HttpTransactHeaders.cc &&\
mv -f $depbase.Tpo $depbase.Po
depbase=`echo HttpTunnel.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
ccache c++ -DHAVE_CONFIG_H -I. -I../../lib  -I../../iocore/eventsystem 
-I../../iocore/net -I../../iocore/aio -I../../iocore/hostdb 
-I../../iocore/cache -I../../iocore/cluster -I../../iocore/utils 
-I../../iocore/dns -I../../proxy/api/ts -I../../proxy -I../../lib 
-I../../lib/records -I../../mgmt -I../../mgmt/utils -I../../proxy/hdrs 
-I../../proxy/shared -I../../proxy/http/remap -I../../proxy/logging 
-I../../proxy/http2 -Dlinux -D_LARGEFILE64_SOURCE=1 -D_COMPILE64BIT_SOURCE=1 
-D_GNU_SOURCE -D_REENTRANT -D__STDC_LIMIT_MACROS=1 -D__STDC_FORMAT_MACROS=1 
-DOPENSSL_NO_SSL_INTERN  -std=c++11 -g -pipe -Wall -O3 
-feliminate-unused-debug-symbols -fno-strict-aliasing -Werror 
-Wno-invalid-offsetof -mcx16 -MT HttpTunnel.o -MD -MP -MF $depbase.Tpo -c -o 
HttpTunnel.o HttpTunnel.cc &&\
mv -f $depbase.Tpo $depbase.Po
depbase=`echo HttpUpdateSM.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
ccache c++ -DHAVE_CONFIG_H -I. -I../../lib  -I../../iocore/eventsystem 
-I../../iocore/net -I../../iocore/aio -I../../iocore/hostdb 
-I../../iocore/cache -I../../iocore/cluster -I../../iocore/utils 
-I../../iocore/dns -I../../proxy/api/ts -I../../proxy -I../../lib 
-I../../lib/records -I../../mgmt -I../../mgmt/utils -I../../proxy/hdrs 
-I../../proxy/shared -I../../proxy/http/remap -I../../proxy/logging 
-I../../proxy/http2 -Dlinux -D_LARGEFILE64_SOURCE=1 -D_COMPILE64BIT_SOURCE=1 
-D_GNU_SOURCE -D_REENTRANT -D__STDC_LIMIT_MACROS=1 -D__STDC_FORMAT_MACROS=1 
-DOPENSSL_NO_SSL_INTERN  -std=c++11 -g -pipe -Wall -O3 
-feliminate-unused-debug-symbols -fno-strict-aliasing -Werror 
-Wno-invalid-offsetof -mcx16 -MT HttpUpdateSM.o -MD -MP -MF $depbase.Tpo -c -o 
HttpUpdateSM.o HttpUpdateSM.cc &&\
mv -f $depbase.Tpo $depbase.Po
depbase=`echo HttpUpdateTester.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
ccache c++ -DHAVE_CONFIG_H -I. -I../../lib  -I../../iocore/eventsystem 
-I../../iocore/net -I../../iocore/aio -I../../iocore/hostdb 
-I../../iocore/cache -I../../iocore/cluster -I../../iocore/utils 
-I../../iocore/dns -I../../proxy/api/ts -I../../proxy -I../../lib 
-I../../lib/records -I../../mgmt -I../../mgmt/utils -I../../proxy/hdrs 
-I../../proxy/shared -I../../proxy/http/remap -I../../proxy/logging 
-I../../proxy/http2 -Dlinux -D_LARGEFILE64_SOURCE=1 -D_COMPILE64BIT_SOURCE=1 
-D_GNU_SOURCE -D_REENTRANT -D__STDC_LIMIT_MACROS=1 -D__STDC_FORMAT_MACROS=1 
-DOPENSSL_NO_SSL_INTERN  -std=c++11 -g -pipe -Wall -O3 
-feliminate-unused-debug-symbols -fno-strict-aliasing -Werror 
-Wno-invalid-offsetof -mcx16 -MT HttpUpdateTester.o -MD -MP -MF $depbase.Tpo -c 
-o HttpUpdateTester.o HttpUpdateTester.cc &&\
mv -f $depbase.Tpo $depbase.Po
depbase=`echo RegressionHttpTransact.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
ccache c++ -DHAVE_CONFIG_H -I. -I../../lib  

[jira] [Commented] (TS-4816) ATS 6.2.0 - crashing with broken pipe, sig11 segmentation fault

2016-09-05 Thread James Peach (JIRA)

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

James Peach commented on TS-4816:
-

Ah sorry for misleading you [~durd]. The backtrace stuff grovels around in 
{{/proc}} so it is fairly Linux-specific.

> ATS 6.2.0 - crashing with broken pipe, sig11 segmentation fault
> ---
>
> Key: TS-4816
> URL: https://issues.apache.org/jira/browse/TS-4816
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Manager
>Reporter: David Brodin
>  Labels: crash
> Fix For: 7.0.0
>
> Attachments: ats_gdb-160905.txt, crash-2016-09-05-075309.log
>
>
> Hi,
> We just upgraded to ATS 6.2.0 via FreeBSD ports:
> {noformat}
> [root@ ~]# uname -a
> FreeBSD  10.3-RELEASE-p7 FreeBSD 10.3-RELEASE-p7 #0: Thu Aug 11 
> 18:38:15 UTC 2016 
> r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64
> [root@ ~]# pkg info | grep traff
> trafficserver-6.2.0Fast, scalable and extensible HTTP proxy server
> {noformat}
> We are experiencing crashes, usually during the day, hardly any during "low" 
> loads, but the mest affecting crashes occur in the early mornings. Along with 
> this we can see a memory leak aswell
> We are using ATS as an enterprise proxy to the Internet, and as we have a 
> very good Internet-connection we have also disabled caching.
> I'm not sure how I would attach files so here goes :)
> manager.log
> {noformat}
> [Sep  2 11:48:28.017] Manager {0x804006400} ERROR: 
> [LocalManager::sendMgmtMsgToProcesses] Error writing message
> [Sep  2 11:48:28.017] Manager {0x804006400} ERROR:  (mgmt_elog)>  (last system error 32: Broken pipe)
> [Sep  2 11:48:38.305] {0x804006400} STATUS: opened 
> /var/log/trafficserver/manager.log
> [Sep  2 11:48:38.305] {0x804006400} NOTE:  (reconfigure_diags)> updated diags config
> [Sep  2 11:48:38.311] Manager {0x804006400} NOTE: [ClusterCom::ClusterCom] 
> Node running on OS: 'FreeBSD' Release: '10.3-RELEASE-p7'
> [Sep  2 11:48:38.312] Manager {0x804006400} NOTE: 
> [LocalManager::listenForProxy] Listening on port: 8080 (IPv4)
> [Sep  2 11:48:38.313] Manager {0x804006400} NOTE: 
> [LocalManager::listenForProxy] Listening on port: 8080 (IPv6)
> [Sep  2 11:48:38.313] Manager {0x804006400} NOTE: [TrafficManager] Setup 
> complete
> [Sep  2 11:48:39.321] Manager {0x804006400} NOTE: [LocalManager::startProxy] 
> Launching ts process
> [Sep  2 11:48:39.336] Manager {0x804006400} NOTE: 
> [LocalManager::pollMgmtProcessServer] New process connecting fd '17'
> [Sep  2 11:48:39.336] Manager {0x804006400} NOTE: [Alarms::signalAlarm] 
> Server Process born
> [Sep  2 11:51:32.574] Manager {0x804006400} ERROR: 
> [LocalManager::sendMgmtMsgToProcesses] Error writing message
> [Sep  2 11:51:32.574] Manager {0x804006400} ERROR:  (mgmt_elog)>  (last system error 32: Broken pipe)
> [Sep  2 11:51:32.669] Manager {0x804006400} ERROR: 
> [LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig 
> 11: Segmentation fault
> [Sep  2 11:51:32.669] Manager {0x804006400} ERROR: [Alarms::signalAlarm] 
> Server Process was reset
> [Sep  2 11:51:33.674] Manager {0x804006400} NOTE: [LocalManager::startProxy] 
> Launching ts process
> [Sep  2 11:51:33.689] Manager {0x804006400} NOTE: 
> [LocalManager::pollMgmtProcessServer] New process connecting fd '13'
> [Sep  2 11:51:33.690] Manager {0x804006400} NOTE: [Alarms::signalAlarm] 
> Server Process born
> [Sep  3 04:14:35.380] Manager {0x804006400} ERROR: 
> [LocalManager::sendMgmtMsgToProcesses] Error writing message
> [Sep  3 04:14:35.380] Manager {0x804006400} ERROR:  (mgmt_elog)>  (last system error 32: Broken pipe)
> [Sep  3 04:14:35.748] Manager {0x804006400} ERROR: 
> [LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig 
> 11: Segmentation fault
> [Sep  3 04:14:35.748] Manager {0x804006400} ERROR: [Alarms::signalAlarm] 
> Server Process was reset
> [Sep  3 04:14:36.814] Manager {0x804006400} NOTE: [LocalManager::startProxy] 
> Launching ts process
> [Sep  3 04:14:36.828] Manager {0x804006400} NOTE: 
> [LocalManager::pollMgmtProcessServer] New process connecting fd '13'
> [Sep  3 04:14:36.829] Manager {0x804006400} NOTE: [Alarms::signalAlarm] 
> Server Process born
> {noformat}
> traffic.out - since this isnt timestamped I'm not sure if I'm leaving some of 
> the stacktrace out:
> {noformat}
> traffic_server[TrafficManager] ==> Cleaning up and reissuing signal #15
> : Terminated
> traffic_server: Terminatedtraffic_servertraffic_servertraffic_server: 
> Segmentation fault
> traffic_server - STACK TRACE:
> 0x4af409 <_Z19crash_logger_invokeiP9__siginfoPv+0x69> at 
> /usr/local/bin/traffic_server
> 0x802735b37  at /lib/libthr.so.3
> 0x80273522c  at 

[jira] [Work logged] (TS-4532) Static type checking for time units

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

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

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

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

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



Issue Time Tracking
---

Worklog Id: (was: 28137)
Time Spent: 3h 20m  (was: 3h 10m)

> Static type checking for time units
> ---
>
> Key: TS-4532
> URL: https://issues.apache.org/jira/browse/TS-4532
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: James Peach
>Assignee: Alan M. Carroll
> Fix For: 7.0.0
>
>  Time Spent: 3h 20m
>  Remaining Estimate: 0h
>
> Since the various time units {{ink_time_t}}, {{time_t}}, {{ink_hrtime}} are 
> all typedefs of C integral types, it is very hard to ensure that units are 
> being converted and compared correctly.
> Consider wrapping these in trivial classes as part of making the time APIs 
> more straightforward. Alternatively, if we move to {{C++11}} investigate 
> {{std::chrono}} for this.



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


[jira] [Work logged] (TS-4532) Static type checking for time units

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

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

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

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

https://github.com/apache/trafficserver/pull/965
  
FreeBSD build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/704/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 28136)
Time Spent: 3h 10m  (was: 3h)

> Static type checking for time units
> ---
>
> Key: TS-4532
> URL: https://issues.apache.org/jira/browse/TS-4532
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: James Peach
>Assignee: Alan M. Carroll
> Fix For: 7.0.0
>
>  Time Spent: 3h 10m
>  Remaining Estimate: 0h
>
> Since the various time units {{ink_time_t}}, {{time_t}}, {{ink_hrtime}} are 
> all typedefs of C integral types, it is very hard to ensure that units are 
> being converted and compared correctly.
> Consider wrapping these in trivial classes as part of making the time APIs 
> more straightforward. Alternatively, if we move to {{C++11}} investigate 
> {{std::chrono}} for this.



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


[GitHub] trafficserver issue #965: TS-4532: Static type checking for time.

2016-09-05 Thread atsci
Github user atsci commented on the issue:

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



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


[GitHub] trafficserver issue #965: TS-4532: Static type checking for time.

2016-09-05 Thread atsci
Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/965
  
FreeBSD build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/704/ 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-4532) Static type checking for time units

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

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

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

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

https://github.com/apache/trafficserver/pull/965#discussion_r77548123
  
--- Diff: iocore/eventsystem/PQ-List.cc ---
@@ -22,18 +22,31 @@
  */
 
 #include "P_EventSystem.h"
+typedef std::chrono::duration > bucket_time;
--- End diff --

I think this is wrong. The ratio should be something like ``<5,1000>`` not 
``<1, 5000>``.


Issue Time Tracking
---

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

> Static type checking for time units
> ---
>
> Key: TS-4532
> URL: https://issues.apache.org/jira/browse/TS-4532
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: James Peach
>Assignee: Alan M. Carroll
> Fix For: 7.0.0
>
>  Time Spent: 3h
>  Remaining Estimate: 0h
>
> Since the various time units {{ink_time_t}}, {{time_t}}, {{ink_hrtime}} are 
> all typedefs of C integral types, it is very hard to ensure that units are 
> being converted and compared correctly.
> Consider wrapping these in trivial classes as part of making the time APIs 
> more straightforward. Alternatively, if we move to {{C++11}} investigate 
> {{std::chrono}} for this.



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


[GitHub] trafficserver pull request #965: TS-4532: Static type checking for time.

2016-09-05 Thread SolidWallOfCode
Github user SolidWallOfCode commented on a diff in the pull request:

https://github.com/apache/trafficserver/pull/965#discussion_r77548123
  
--- Diff: iocore/eventsystem/PQ-List.cc ---
@@ -22,18 +22,31 @@
  */
 
 #include "P_EventSystem.h"
+typedef std::chrono::duration > bucket_time;
--- End diff --

I think this is wrong. The ratio should be something like ``<5,1000>`` not 
``<1, 5000>``.


---
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-4816) ATS 6.2.0 - crashing with broken pipe, sig11 segmentation fault

2016-09-05 Thread David Brodin (JIRA)

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

David Brodin commented on TS-4816:
--

Ok, for some reason I thought libunwind was a linux-thing, TIL I guess :)
Should it matter if I compiled ATS from ports and not from source downloaded 
from apache.org?
I installed libunwind and rebuilt ATS from ports, but got the below when 
running {{traffic_ctl server backtrace}}:
{noformat}traffic_ctl: server backtrace failed: [12] Operation not supported on 
this platform.{noformat}

I'll reproduce while gdb is attached to the process and remember to do the rest 
of the steps.

> ATS 6.2.0 - crashing with broken pipe, sig11 segmentation fault
> ---
>
> Key: TS-4816
> URL: https://issues.apache.org/jira/browse/TS-4816
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Manager
>Reporter: David Brodin
>  Labels: crash
> Fix For: 7.0.0
>
> Attachments: ats_gdb-160905.txt, crash-2016-09-05-075309.log
>
>
> Hi,
> We just upgraded to ATS 6.2.0 via FreeBSD ports:
> {noformat}
> [root@ ~]# uname -a
> FreeBSD  10.3-RELEASE-p7 FreeBSD 10.3-RELEASE-p7 #0: Thu Aug 11 
> 18:38:15 UTC 2016 
> r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64
> [root@ ~]# pkg info | grep traff
> trafficserver-6.2.0Fast, scalable and extensible HTTP proxy server
> {noformat}
> We are experiencing crashes, usually during the day, hardly any during "low" 
> loads, but the mest affecting crashes occur in the early mornings. Along with 
> this we can see a memory leak aswell
> We are using ATS as an enterprise proxy to the Internet, and as we have a 
> very good Internet-connection we have also disabled caching.
> I'm not sure how I would attach files so here goes :)
> manager.log
> {noformat}
> [Sep  2 11:48:28.017] Manager {0x804006400} ERROR: 
> [LocalManager::sendMgmtMsgToProcesses] Error writing message
> [Sep  2 11:48:28.017] Manager {0x804006400} ERROR:  (mgmt_elog)>  (last system error 32: Broken pipe)
> [Sep  2 11:48:38.305] {0x804006400} STATUS: opened 
> /var/log/trafficserver/manager.log
> [Sep  2 11:48:38.305] {0x804006400} NOTE:  (reconfigure_diags)> updated diags config
> [Sep  2 11:48:38.311] Manager {0x804006400} NOTE: [ClusterCom::ClusterCom] 
> Node running on OS: 'FreeBSD' Release: '10.3-RELEASE-p7'
> [Sep  2 11:48:38.312] Manager {0x804006400} NOTE: 
> [LocalManager::listenForProxy] Listening on port: 8080 (IPv4)
> [Sep  2 11:48:38.313] Manager {0x804006400} NOTE: 
> [LocalManager::listenForProxy] Listening on port: 8080 (IPv6)
> [Sep  2 11:48:38.313] Manager {0x804006400} NOTE: [TrafficManager] Setup 
> complete
> [Sep  2 11:48:39.321] Manager {0x804006400} NOTE: [LocalManager::startProxy] 
> Launching ts process
> [Sep  2 11:48:39.336] Manager {0x804006400} NOTE: 
> [LocalManager::pollMgmtProcessServer] New process connecting fd '17'
> [Sep  2 11:48:39.336] Manager {0x804006400} NOTE: [Alarms::signalAlarm] 
> Server Process born
> [Sep  2 11:51:32.574] Manager {0x804006400} ERROR: 
> [LocalManager::sendMgmtMsgToProcesses] Error writing message
> [Sep  2 11:51:32.574] Manager {0x804006400} ERROR:  (mgmt_elog)>  (last system error 32: Broken pipe)
> [Sep  2 11:51:32.669] Manager {0x804006400} ERROR: 
> [LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig 
> 11: Segmentation fault
> [Sep  2 11:51:32.669] Manager {0x804006400} ERROR: [Alarms::signalAlarm] 
> Server Process was reset
> [Sep  2 11:51:33.674] Manager {0x804006400} NOTE: [LocalManager::startProxy] 
> Launching ts process
> [Sep  2 11:51:33.689] Manager {0x804006400} NOTE: 
> [LocalManager::pollMgmtProcessServer] New process connecting fd '13'
> [Sep  2 11:51:33.690] Manager {0x804006400} NOTE: [Alarms::signalAlarm] 
> Server Process born
> [Sep  3 04:14:35.380] Manager {0x804006400} ERROR: 
> [LocalManager::sendMgmtMsgToProcesses] Error writing message
> [Sep  3 04:14:35.380] Manager {0x804006400} ERROR:  (mgmt_elog)>  (last system error 32: Broken pipe)
> [Sep  3 04:14:35.748] Manager {0x804006400} ERROR: 
> [LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig 
> 11: Segmentation fault
> [Sep  3 04:14:35.748] Manager {0x804006400} ERROR: [Alarms::signalAlarm] 
> Server Process was reset
> [Sep  3 04:14:36.814] Manager {0x804006400} NOTE: [LocalManager::startProxy] 
> Launching ts process
> [Sep  3 04:14:36.828] Manager {0x804006400} NOTE: 
> [LocalManager::pollMgmtProcessServer] New process connecting fd '13'
> [Sep  3 04:14:36.829] Manager {0x804006400} NOTE: [Alarms::signalAlarm] 
> Server Process born
> {noformat}
> traffic.out - since this isnt timestamped I'm not sure if I'm leaving some of 
> the stacktrace out:
> {noformat}
> traffic_server[TrafficManager] ==> Cleaning up and 

[GitHub] trafficserver issue #965: TS-4532: Static type checking for time.

2016-09-05 Thread atsci
Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/965
  
FreeBSD build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/703/ 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-4532) Static type checking for time units

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

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

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

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

https://github.com/apache/trafficserver/pull/965
  
FreeBSD build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/703/ for details.
 



Issue Time Tracking
---

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

> Static type checking for time units
> ---
>
> Key: TS-4532
> URL: https://issues.apache.org/jira/browse/TS-4532
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: James Peach
>Assignee: Alan M. Carroll
> Fix For: 7.0.0
>
>  Time Spent: 2h 50m
>  Remaining Estimate: 0h
>
> Since the various time units {{ink_time_t}}, {{time_t}}, {{ink_hrtime}} are 
> all typedefs of C integral types, it is very hard to ensure that units are 
> being converted and compared correctly.
> Consider wrapping these in trivial classes as part of making the time APIs 
> more straightforward. Alternatively, if we move to {{C++11}} investigate 
> {{std::chrono}} for this.



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


[jira] [Work logged] (TS-4532) Static type checking for time units

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

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

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

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

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



Issue Time Tracking
---

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

> Static type checking for time units
> ---
>
> Key: TS-4532
> URL: https://issues.apache.org/jira/browse/TS-4532
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: James Peach
>Assignee: Alan M. Carroll
> Fix For: 7.0.0
>
>  Time Spent: 2h 40m
>  Remaining Estimate: 0h
>
> Since the various time units {{ink_time_t}}, {{time_t}}, {{ink_hrtime}} are 
> all typedefs of C integral types, it is very hard to ensure that units are 
> being converted and compared correctly.
> Consider wrapping these in trivial classes as part of making the time APIs 
> more straightforward. Alternatively, if we move to {{C++11}} investigate 
> {{std::chrono}} for this.



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


[GitHub] trafficserver issue #965: TS-4532: Static type checking for time.

2016-09-05 Thread atsci
Github user atsci commented on the issue:

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



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


[GitHub] trafficserver issue #965: TS-4532: Static type checking for time.

2016-09-05 Thread atsci
Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/965
  
FreeBSD build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/702/ 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 #965: TS-4532: Static type checking for time.

2016-09-05 Thread SolidWallOfCode
Github user SolidWallOfCode commented on a diff in the pull request:

https://github.com/apache/trafficserver/pull/965#discussion_r77541569
  
--- Diff: iocore/eventsystem/UnixEThread.cc ---
@@ -149,10 +149,10 @@ EThread::process_event(Event *e, int calling_code)
 ink_assert(!e->in_the_priority_queue);
 ink_assert(c_temp == e->continuation);
 MUTEX_RELEASE(lock);
-if (e->period) {
+if (e->period.count()) {
   if (!e->in_the_prot_queue && !e->in_the_priority_queue) {
-if (e->period < 0)
-  e->timeout_at = e->period;
+if (e->period.count() < 0)
+  e->timeout_at = ts_hrtick::min() + e->period;
--- End diff --

Change to ``e->timeout_at = TS_HRTICK_ZERO + e->period``.


---
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-4532) Static type checking for time units

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

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

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

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

https://github.com/apache/trafficserver/pull/965#discussion_r77541520
  
--- Diff: iocore/eventsystem/UnixEThread.cc ---
@@ -149,10 +149,10 @@ EThread::process_event(Event *e, int calling_code)
 ink_assert(!e->in_the_priority_queue);
 ink_assert(c_temp == e->continuation);
 MUTEX_RELEASE(lock);
-if (e->period) {
+if (e->period.count()) {
   if (!e->in_the_prot_queue && !e->in_the_priority_queue) {
-if (e->period < 0)
-  e->timeout_at = e->period;
+if (e->period.count() < 0)
--- End diff --

Or ``e->period < e->period.zero()`` ?


Issue Time Tracking
---

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

> Static type checking for time units
> ---
>
> Key: TS-4532
> URL: https://issues.apache.org/jira/browse/TS-4532
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: James Peach
>Assignee: Alan M. Carroll
> Fix For: 7.0.0
>
>  Time Spent: 2h 10m
>  Remaining Estimate: 0h
>
> Since the various time units {{ink_time_t}}, {{time_t}}, {{ink_hrtime}} are 
> all typedefs of C integral types, it is very hard to ensure that units are 
> being converted and compared correctly.
> Consider wrapping these in trivial classes as part of making the time APIs 
> more straightforward. Alternatively, if we move to {{C++11}} investigate 
> {{std::chrono}} for this.



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


[jira] [Work logged] (TS-4532) Static type checking for time units

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

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

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

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

https://github.com/apache/trafficserver/pull/965#discussion_r77541569
  
--- Diff: iocore/eventsystem/UnixEThread.cc ---
@@ -149,10 +149,10 @@ EThread::process_event(Event *e, int calling_code)
 ink_assert(!e->in_the_priority_queue);
 ink_assert(c_temp == e->continuation);
 MUTEX_RELEASE(lock);
-if (e->period) {
+if (e->period.count()) {
   if (!e->in_the_prot_queue && !e->in_the_priority_queue) {
-if (e->period < 0)
-  e->timeout_at = e->period;
+if (e->period.count() < 0)
+  e->timeout_at = ts_hrtick::min() + e->period;
--- End diff --

Change to ``e->timeout_at = TS_HRTICK_ZERO + e->period``.


Issue Time Tracking
---

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

> Static type checking for time units
> ---
>
> Key: TS-4532
> URL: https://issues.apache.org/jira/browse/TS-4532
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: James Peach
>Assignee: Alan M. Carroll
> Fix For: 7.0.0
>
>  Time Spent: 2h 20m
>  Remaining Estimate: 0h
>
> Since the various time units {{ink_time_t}}, {{time_t}}, {{ink_hrtime}} are 
> all typedefs of C integral types, it is very hard to ensure that units are 
> being converted and compared correctly.
> Consider wrapping these in trivial classes as part of making the time APIs 
> more straightforward. Alternatively, if we move to {{C++11}} investigate 
> {{std::chrono}} for this.



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


[GitHub] trafficserver pull request #965: TS-4532: Static type checking for time.

2016-09-05 Thread SolidWallOfCode
Github user SolidWallOfCode commented on a diff in the pull request:

https://github.com/apache/trafficserver/pull/965#discussion_r77541520
  
--- Diff: iocore/eventsystem/UnixEThread.cc ---
@@ -149,10 +149,10 @@ EThread::process_event(Event *e, int calling_code)
 ink_assert(!e->in_the_priority_queue);
 ink_assert(c_temp == e->continuation);
 MUTEX_RELEASE(lock);
-if (e->period) {
+if (e->period.count()) {
   if (!e->in_the_prot_queue && !e->in_the_priority_queue) {
-if (e->period < 0)
-  e->timeout_at = e->period;
+if (e->period.count() < 0)
--- End diff --

Or ``e->period < e->period.zero()`` ?


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


[GitHub] trafficserver issue #965: TS-4532: Static type checking for time.

2016-09-05 Thread atsci
Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/965
  
Linux build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/597/ 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-4532) Static type checking for time units

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

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

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

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

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



Issue Time Tracking
---

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

> Static type checking for time units
> ---
>
> Key: TS-4532
> URL: https://issues.apache.org/jira/browse/TS-4532
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: James Peach
>Assignee: Alan M. Carroll
> Fix For: 7.0.0
>
>  Time Spent: 2h
>  Remaining Estimate: 0h
>
> Since the various time units {{ink_time_t}}, {{time_t}}, {{ink_hrtime}} are 
> all typedefs of C integral types, it is very hard to ensure that units are 
> being converted and compared correctly.
> Consider wrapping these in trivial classes as part of making the time APIs 
> more straightforward. Alternatively, if we move to {{C++11}} investigate 
> {{std::chrono}} for this.



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


[jira] [Work logged] (TS-4532) Static type checking for time units

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

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

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

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

https://github.com/apache/trafficserver/pull/965
  
FreeBSD build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/701/ for details.
 



Issue Time Tracking
---

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

> Static type checking for time units
> ---
>
> Key: TS-4532
> URL: https://issues.apache.org/jira/browse/TS-4532
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: James Peach
>Assignee: Alan M. Carroll
> Fix For: 7.0.0
>
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> Since the various time units {{ink_time_t}}, {{time_t}}, {{ink_hrtime}} are 
> all typedefs of C integral types, it is very hard to ensure that units are 
> being converted and compared correctly.
> Consider wrapping these in trivial classes as part of making the time APIs 
> more straightforward. Alternatively, if we move to {{C++11}} investigate 
> {{std::chrono}} for this.



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


[GitHub] trafficserver issue #965: TS-4532: Static type checking for time.

2016-09-05 Thread atsci
Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/965
  
FreeBSD build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/701/ 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-4532) Static type checking for time units

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

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

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

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

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



Issue Time Tracking
---

Worklog Id: (was: 28125)
Time Spent: 1h 40m  (was: 1.5h)

> Static type checking for time units
> ---
>
> Key: TS-4532
> URL: https://issues.apache.org/jira/browse/TS-4532
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: James Peach
>Assignee: Alan M. Carroll
> Fix For: 7.0.0
>
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> Since the various time units {{ink_time_t}}, {{time_t}}, {{ink_hrtime}} are 
> all typedefs of C integral types, it is very hard to ensure that units are 
> being converted and compared correctly.
> Consider wrapping these in trivial classes as part of making the time APIs 
> more straightforward. Alternatively, if we move to {{C++11}} investigate 
> {{std::chrono}} for this.



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


[GitHub] trafficserver issue #965: TS-4532: Static type checking for time.

2016-09-05 Thread atsci
Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/965
  
Linux build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/596/ 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-4532) Static type checking for time units

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

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

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

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

https://github.com/apache/trafficserver/pull/965
  
FreeBSD build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/700/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 28124)
Time Spent: 1.5h  (was: 1h 20m)

> Static type checking for time units
> ---
>
> Key: TS-4532
> URL: https://issues.apache.org/jira/browse/TS-4532
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: James Peach
>Assignee: Alan M. Carroll
> Fix For: 7.0.0
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> Since the various time units {{ink_time_t}}, {{time_t}}, {{ink_hrtime}} are 
> all typedefs of C integral types, it is very hard to ensure that units are 
> being converted and compared correctly.
> Consider wrapping these in trivial classes as part of making the time APIs 
> more straightforward. Alternatively, if we move to {{C++11}} investigate 
> {{std::chrono}} for this.



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


[GitHub] trafficserver issue #965: TS-4532: Static type checking for time.

2016-09-05 Thread atsci
Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/965
  
FreeBSD build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/700/ 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-4532) Static type checking for time units

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

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

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

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

https://github.com/apache/trafficserver/pull/965#discussion_r77540649
  
--- Diff: iocore/eventsystem/I_Thread.h ---
@@ -168,21 +168,21 @@ class Thread
 
   @note This also updates the cached time.
   */
-  static ink_hrtime get_hrtime_updated();
+  static ts_hrtick get_hrtime_updated();
 };
 
 extern Thread *this_thread();
 
-TS_INLINE ink_hrtime
+TS_INLINE ts_hrtick
 Thread::get_hrtime()
 {
   return cur_time;
 }
 
-TS_INLINE ink_hrtime
+TS_INLINE ts_hrtick
 Thread::get_hrtime_updated()
 {
-  return cur_time = ink_get_hrtime_internal();
+  return cur_time = std::chrono::high_resolution_clock::now();
--- End diff --

Wrong. Should be ``ts_hrtick::clock::now()``.


Issue Time Tracking
---

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

> Static type checking for time units
> ---
>
> Key: TS-4532
> URL: https://issues.apache.org/jira/browse/TS-4532
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: James Peach
>Assignee: Alan M. Carroll
> Fix For: 7.0.0
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> Since the various time units {{ink_time_t}}, {{time_t}}, {{ink_hrtime}} are 
> all typedefs of C integral types, it is very hard to ensure that units are 
> being converted and compared correctly.
> Consider wrapping these in trivial classes as part of making the time APIs 
> more straightforward. Alternatively, if we move to {{C++11}} investigate 
> {{std::chrono}} for this.



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


[GitHub] trafficserver pull request #965: TS-4532: Static type checking for time.

2016-09-05 Thread SolidWallOfCode
Github user SolidWallOfCode commented on a diff in the pull request:

https://github.com/apache/trafficserver/pull/965#discussion_r77540649
  
--- Diff: iocore/eventsystem/I_Thread.h ---
@@ -168,21 +168,21 @@ class Thread
 
   @note This also updates the cached time.
   */
-  static ink_hrtime get_hrtime_updated();
+  static ts_hrtick get_hrtime_updated();
 };
 
 extern Thread *this_thread();
 
-TS_INLINE ink_hrtime
+TS_INLINE ts_hrtick
 Thread::get_hrtime()
 {
   return cur_time;
 }
 
-TS_INLINE ink_hrtime
+TS_INLINE ts_hrtick
 Thread::get_hrtime_updated()
 {
-  return cur_time = ink_get_hrtime_internal();
+  return cur_time = std::chrono::high_resolution_clock::now();
--- End diff --

Wrong. Should be ``ts_hrtick::clock::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.
---


[GitHub] trafficserver issue #965: TS-4532: Static type checking for time.

2016-09-05 Thread atsci
Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/965
  
Linux build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/595/ 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-4532) Static type checking for time units

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

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

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

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

https://github.com/apache/trafficserver/pull/965
  
FreeBSD build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/699/ for details.
 



Issue Time Tracking
---

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

> Static type checking for time units
> ---
>
> Key: TS-4532
> URL: https://issues.apache.org/jira/browse/TS-4532
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: James Peach
>Assignee: Alan M. Carroll
> Fix For: 7.0.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> Since the various time units {{ink_time_t}}, {{time_t}}, {{ink_hrtime}} are 
> all typedefs of C integral types, it is very hard to ensure that units are 
> being converted and compared correctly.
> Consider wrapping these in trivial classes as part of making the time APIs 
> more straightforward. Alternatively, if we move to {{C++11}} investigate 
> {{std::chrono}} for this.



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


[jira] [Work logged] (TS-4532) Static type checking for time units

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

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

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

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

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



Issue Time Tracking
---

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

> Static type checking for time units
> ---
>
> Key: TS-4532
> URL: https://issues.apache.org/jira/browse/TS-4532
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: James Peach
>Assignee: Alan M. Carroll
> Fix For: 7.0.0
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> Since the various time units {{ink_time_t}}, {{time_t}}, {{ink_hrtime}} are 
> all typedefs of C integral types, it is very hard to ensure that units are 
> being converted and compared correctly.
> Consider wrapping these in trivial classes as part of making the time APIs 
> more straightforward. Alternatively, if we move to {{C++11}} investigate 
> {{std::chrono}} for this.



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


[GitHub] trafficserver issue #965: TS-4532: Static type checking for time.

2016-09-05 Thread atsci
Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/965
  
FreeBSD build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/699/ 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-4532) Static type checking for time units

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

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

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

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

https://github.com/apache/trafficserver/pull/965#discussion_r77540451
  
--- Diff: iocore/eventsystem/I_Lock.h ---
@@ -241,7 +241,7 @@ class ProxyMutex : public RefCountObj
 thread_holding  = NULL;
 nthread_holding = 0;
 #ifdef DEBUG
-hold_time = 0;
+hold_time = hold_time.min();
--- End diff --

SHould be ``hold_time = TS_HRTICK_ZERO;``.


Issue Time Tracking
---

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

> Static type checking for time units
> ---
>
> Key: TS-4532
> URL: https://issues.apache.org/jira/browse/TS-4532
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: James Peach
>Assignee: Alan M. Carroll
> Fix For: 7.0.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> Since the various time units {{ink_time_t}}, {{time_t}}, {{ink_hrtime}} are 
> all typedefs of C integral types, it is very hard to ensure that units are 
> being converted and compared correctly.
> Consider wrapping these in trivial classes as part of making the time APIs 
> more straightforward. Alternatively, if we move to {{C++11}} investigate 
> {{std::chrono}} for this.



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


[GitHub] trafficserver pull request #965: TS-4532: Static type checking for time.

2016-09-05 Thread SolidWallOfCode
Github user SolidWallOfCode commented on a diff in the pull request:

https://github.com/apache/trafficserver/pull/965#discussion_r77540451
  
--- Diff: iocore/eventsystem/I_Lock.h ---
@@ -241,7 +241,7 @@ class ProxyMutex : public RefCountObj
 thread_holding  = NULL;
 nthread_holding = 0;
 #ifdef DEBUG
-hold_time = 0;
+hold_time = hold_time.min();
--- End diff --

SHould be ``hold_time = TS_HRTICK_ZERO;``.


---
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-4532) Static type checking for time units

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

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

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

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

https://github.com/apache/trafficserver/pull/965#discussion_r77540321
  
--- Diff: iocore/eventsystem/I_Lock.h ---
@@ -28,7 +28,7 @@
 #include "ts/Diags.h"
 #include "I_Thread.h"
 
-#define MAX_LOCK_TIME HRTIME_MSECONDS(200)
+static const ts_microseconds MAX_LOCK_TIME(200);
--- End diff --

This could also be
{{code}}
static const ts_nanoseconds MAX_LOCK_TIME(ts_microseconds(200));
{{code}}
That style is used elsewhere, I'm not sure which is better. Denoting this 
value in nanoseconds avoids conversions later.


Issue Time Tracking
---

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

> Static type checking for time units
> ---
>
> Key: TS-4532
> URL: https://issues.apache.org/jira/browse/TS-4532
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: James Peach
>Assignee: Alan M. Carroll
> Fix For: 7.0.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Since the various time units {{ink_time_t}}, {{time_t}}, {{ink_hrtime}} are 
> all typedefs of C integral types, it is very hard to ensure that units are 
> being converted and compared correctly.
> Consider wrapping these in trivial classes as part of making the time APIs 
> more straightforward. Alternatively, if we move to {{C++11}} investigate 
> {{std::chrono}} for this.



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


[GitHub] trafficserver pull request #965: TS-4532: Static type checking for time.

2016-09-05 Thread SolidWallOfCode
Github user SolidWallOfCode commented on a diff in the pull request:

https://github.com/apache/trafficserver/pull/965#discussion_r77540321
  
--- Diff: iocore/eventsystem/I_Lock.h ---
@@ -28,7 +28,7 @@
 #include "ts/Diags.h"
 #include "I_Thread.h"
 
-#define MAX_LOCK_TIME HRTIME_MSECONDS(200)
+static const ts_microseconds MAX_LOCK_TIME(200);
--- End diff --

This could also be
{{code}}
static const ts_nanoseconds MAX_LOCK_TIME(ts_microseconds(200));
{{code}}
That style is used elsewhere, I'm not sure which is better. Denoting this 
value in nanoseconds avoids conversions later.


---
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-4532) Static type checking for time units

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

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

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

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

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



Issue Time Tracking
---

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

> Static type checking for time units
> ---
>
> Key: TS-4532
> URL: https://issues.apache.org/jira/browse/TS-4532
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: James Peach
>Assignee: Alan M. Carroll
> Fix For: 7.0.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Since the various time units {{ink_time_t}}, {{time_t}}, {{ink_hrtime}} are 
> all typedefs of C integral types, it is very hard to ensure that units are 
> being converted and compared correctly.
> Consider wrapping these in trivial classes as part of making the time APIs 
> more straightforward. Alternatively, if we move to {{C++11}} investigate 
> {{std::chrono}} for this.



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


[GitHub] trafficserver issue #965: TS-4532: Static type checking for time.

2016-09-05 Thread atsci
Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/965
  
Linux build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/594/ 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-4532) Static type checking for time units

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

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

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

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

https://github.com/apache/trafficserver/pull/965
  
FreeBSD build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/698/ for details.
 



Issue Time Tracking
---

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

> Static type checking for time units
> ---
>
> Key: TS-4532
> URL: https://issues.apache.org/jira/browse/TS-4532
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: James Peach
>Assignee: Alan M. Carroll
> Fix For: 7.0.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Since the various time units {{ink_time_t}}, {{time_t}}, {{ink_hrtime}} are 
> all typedefs of C integral types, it is very hard to ensure that units are 
> being converted and compared correctly.
> Consider wrapping these in trivial classes as part of making the time APIs 
> more straightforward. Alternatively, if we move to {{C++11}} investigate 
> {{std::chrono}} for this.



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


[GitHub] trafficserver issue #965: TS-4532: Static type checking for time.

2016-09-05 Thread atsci
Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/965
  
FreeBSD build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/698/ 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-4532) Static type checking for time units

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

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

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

Author: ASF GitHub Bot
Created on: 05/Sep/16 16:00
Start Date: 05/Sep/16 16:00
Worklog Time Spent: 10m 
  Work Description: GitHub user SolidWallOfCode opened a pull request:

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

TS-4532: Static type checking for time.

Rough first pass just for iocore/eventsystem to get a feel for the changes.

THIS WILL NOT RUN - it's just an experiment to be verified before further 
work is done.

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

$ git pull https://github.com/SolidWallOfCode/trafficserver ts-4532

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

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


commit c96fdecad810ee680475377faf9fca2bdbf817b4
Author: Alan M. Carroll 
Date:   2016-09-05T15:58:14Z

TS-4532: Static type checking for time.
Rough first pass just for iocore/eventsystem to get a feel for the changes.




Issue Time Tracking
---

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

> Static type checking for time units
> ---
>
> Key: TS-4532
> URL: https://issues.apache.org/jira/browse/TS-4532
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: James Peach
>Assignee: Alan M. Carroll
> Fix For: 7.0.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Since the various time units {{ink_time_t}}, {{time_t}}, {{ink_hrtime}} are 
> all typedefs of C integral types, it is very hard to ensure that units are 
> being converted and compared correctly.
> Consider wrapping these in trivial classes as part of making the time APIs 
> more straightforward. Alternatively, if we move to {{C++11}} investigate 
> {{std::chrono}} for this.



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


[GitHub] trafficserver pull request #965: TS-4532: Static type checking for time.

2016-09-05 Thread SolidWallOfCode
GitHub user SolidWallOfCode opened a pull request:

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

TS-4532: Static type checking for time.

Rough first pass just for iocore/eventsystem to get a feel for the changes.

THIS WILL NOT RUN - it's just an experiment to be verified before further 
work is done.

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

$ git pull https://github.com/SolidWallOfCode/trafficserver ts-4532

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

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


commit c96fdecad810ee680475377faf9fca2bdbf817b4
Author: Alan M. Carroll 
Date:   2016-09-05T15:58:14Z

TS-4532: Static type checking for time.
Rough first pass just for iocore/eventsystem to get a feel for the changes.




---
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-4816) ATS 6.2.0 - crashing with broken pipe, sig11 segmentation fault

2016-09-05 Thread James Peach (JIRA)

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

James Peach commented on TS-4816:
-

If you install the libunwind port and rebuild Traffic Server, then it should 
automatically be able to generate a backtrace in the crash log. You can test 
whether that support works with the {{traffic_ctl server backtrace}} command.

If you are able to reproduce under {{gdb}} again, when the program stops with 
SEGV, type {{bt\n}} and then {{info locals\n}} to show additional information 
about the crashing context.

> ATS 6.2.0 - crashing with broken pipe, sig11 segmentation fault
> ---
>
> Key: TS-4816
> URL: https://issues.apache.org/jira/browse/TS-4816
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Manager
>Reporter: David Brodin
>  Labels: crash
> Fix For: 7.0.0
>
> Attachments: ats_gdb-160905.txt, crash-2016-09-05-075309.log
>
>
> Hi,
> We just upgraded to ATS 6.2.0 via FreeBSD ports:
> {noformat}
> [root@ ~]# uname -a
> FreeBSD  10.3-RELEASE-p7 FreeBSD 10.3-RELEASE-p7 #0: Thu Aug 11 
> 18:38:15 UTC 2016 
> r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64
> [root@ ~]# pkg info | grep traff
> trafficserver-6.2.0Fast, scalable and extensible HTTP proxy server
> {noformat}
> We are experiencing crashes, usually during the day, hardly any during "low" 
> loads, but the mest affecting crashes occur in the early mornings. Along with 
> this we can see a memory leak aswell
> We are using ATS as an enterprise proxy to the Internet, and as we have a 
> very good Internet-connection we have also disabled caching.
> I'm not sure how I would attach files so here goes :)
> manager.log
> {noformat}
> [Sep  2 11:48:28.017] Manager {0x804006400} ERROR: 
> [LocalManager::sendMgmtMsgToProcesses] Error writing message
> [Sep  2 11:48:28.017] Manager {0x804006400} ERROR:  (mgmt_elog)>  (last system error 32: Broken pipe)
> [Sep  2 11:48:38.305] {0x804006400} STATUS: opened 
> /var/log/trafficserver/manager.log
> [Sep  2 11:48:38.305] {0x804006400} NOTE:  (reconfigure_diags)> updated diags config
> [Sep  2 11:48:38.311] Manager {0x804006400} NOTE: [ClusterCom::ClusterCom] 
> Node running on OS: 'FreeBSD' Release: '10.3-RELEASE-p7'
> [Sep  2 11:48:38.312] Manager {0x804006400} NOTE: 
> [LocalManager::listenForProxy] Listening on port: 8080 (IPv4)
> [Sep  2 11:48:38.313] Manager {0x804006400} NOTE: 
> [LocalManager::listenForProxy] Listening on port: 8080 (IPv6)
> [Sep  2 11:48:38.313] Manager {0x804006400} NOTE: [TrafficManager] Setup 
> complete
> [Sep  2 11:48:39.321] Manager {0x804006400} NOTE: [LocalManager::startProxy] 
> Launching ts process
> [Sep  2 11:48:39.336] Manager {0x804006400} NOTE: 
> [LocalManager::pollMgmtProcessServer] New process connecting fd '17'
> [Sep  2 11:48:39.336] Manager {0x804006400} NOTE: [Alarms::signalAlarm] 
> Server Process born
> [Sep  2 11:51:32.574] Manager {0x804006400} ERROR: 
> [LocalManager::sendMgmtMsgToProcesses] Error writing message
> [Sep  2 11:51:32.574] Manager {0x804006400} ERROR:  (mgmt_elog)>  (last system error 32: Broken pipe)
> [Sep  2 11:51:32.669] Manager {0x804006400} ERROR: 
> [LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig 
> 11: Segmentation fault
> [Sep  2 11:51:32.669] Manager {0x804006400} ERROR: [Alarms::signalAlarm] 
> Server Process was reset
> [Sep  2 11:51:33.674] Manager {0x804006400} NOTE: [LocalManager::startProxy] 
> Launching ts process
> [Sep  2 11:51:33.689] Manager {0x804006400} NOTE: 
> [LocalManager::pollMgmtProcessServer] New process connecting fd '13'
> [Sep  2 11:51:33.690] Manager {0x804006400} NOTE: [Alarms::signalAlarm] 
> Server Process born
> [Sep  3 04:14:35.380] Manager {0x804006400} ERROR: 
> [LocalManager::sendMgmtMsgToProcesses] Error writing message
> [Sep  3 04:14:35.380] Manager {0x804006400} ERROR:  (mgmt_elog)>  (last system error 32: Broken pipe)
> [Sep  3 04:14:35.748] Manager {0x804006400} ERROR: 
> [LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig 
> 11: Segmentation fault
> [Sep  3 04:14:35.748] Manager {0x804006400} ERROR: [Alarms::signalAlarm] 
> Server Process was reset
> [Sep  3 04:14:36.814] Manager {0x804006400} NOTE: [LocalManager::startProxy] 
> Launching ts process
> [Sep  3 04:14:36.828] Manager {0x804006400} NOTE: 
> [LocalManager::pollMgmtProcessServer] New process connecting fd '13'
> [Sep  3 04:14:36.829] Manager {0x804006400} NOTE: [Alarms::signalAlarm] 
> Server Process born
> {noformat}
> traffic.out - since this isnt timestamped I'm not sure if I'm leaving some of 
> the stacktrace out:
> {noformat}
> traffic_server[TrafficManager] ==> Cleaning up and reissuing signal #15
> : Terminated
> traffic_server: 

[jira] [Work logged] (TS-4769) TSSslServerContextCreate always returns null

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

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

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

Author: ASF GitHub Bot
Created on: 05/Sep/16 15:10
Start Date: 05/Sep/16 15:10
Worklog Time Spent: 10m 
  Work Description: Github user biilmann closed the pull request at:

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


Issue Time Tracking
---

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

> TSSslServerContextCreate always returns null
> 
>
> Key: TS-4769
> URL: https://issues.apache.org/jira/browse/TS-4769
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SSL, TS API
>Reporter: Mathias Biilmann Christensen
>Assignee: Susan Hinrichs
>Priority: Blocker
> Fix For: 7.0.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> The change to SSLInitServerContext in 
> https://github.com/apache/trafficserver/pull/810 breaks the 
> TSSslServerContextCreate API method, since this one calls 
> TSSslServerContextCreate with an empty sslMultCertSettings.
> This means plugins can't create a fresh SSL context and set the certificates 
> themselves.



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


[GitHub] trafficserver pull request #964: Fix SSLCreateServerContext always returning...

2016-09-05 Thread biilmann
Github user biilmann closed the pull request at:

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


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


[GitHub] trafficserver issue #964: Fix SSLCreateServerContext always returning null

2016-09-05 Thread biilmann
Github user biilmann commented on the issue:

https://github.com/apache/trafficserver/pull/964
  
After some more testing this doesn't work correctly - setting 
`SSLCertContext::OPT_TUNNEL` does seem to have other unintended side effects.


---
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-2981) Add HTTP session id to all HTTP debug log messages

2016-09-05 Thread bwahn (JIRA)

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

bwahn commented on TS-2981:
---

[~bcall]
Thanks for your feedback, I will patch with . 

> Add HTTP session id to all HTTP debug log messages
> --
>
> Key: TS-2981
> URL: https://issues.apache.org/jira/browse/TS-2981
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Logging
>Reporter: Bryan Call
>  Labels: newbie
> Fix For: sometime
>
>
> Trying to debug an event system with interleaved debugging messages can make 
> you crazy...



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


[GitHub] trafficserver pull request #947: TS-4796 Change UnixNetHandler to always bub...

2016-09-05 Thread oknet
Github user oknet commented on a diff in the pull request:

https://github.com/apache/trafficserver/pull/947#discussion_r77499140
  
--- Diff: iocore/net/UnixNet.cc ---
@@ -542,7 +555,14 @@ NetHandler::mainNetEvent(int event, Event *e)
   close_UnixNetVConnection(vc, trigger_event->ethread);
 else if (vc->write.enabled && vc->write.triggered)
   write_to_net(this, vc, trigger_event->ethread);
-else if (!vc->write.enabled) {
+else if (vc->write.error) {
+  int err = 0, errlen = sizeof(int);
+  if (getsockopt(vc->con.fd, SOL_SOCKET, SO_ERROR, , (socklen_t 
*)) == -1) {
+err = errno;
+  }
+  if (err != EAGAIN && err != EINTR)
+vc->writeSignalError(this, err);
+} else if (!vc->write.enabled) {
--- End diff --

suggest code: 
```
else {
  if (vc->write.error) {
  ...
if (err && err != EAGAIN && err != EINTR)
  vc->writeSignalError(this, err);
else
  vc->write.error = 0;
  }
  if (!vc->write.enabled) {
  ...
  }
}
```
the same to READ.


---
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-4796) ATS not closing origin connections on first RST from client

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

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

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

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

https://github.com/apache/trafficserver/pull/947#discussion_r77499140
  
--- Diff: iocore/net/UnixNet.cc ---
@@ -542,7 +555,14 @@ NetHandler::mainNetEvent(int event, Event *e)
   close_UnixNetVConnection(vc, trigger_event->ethread);
 else if (vc->write.enabled && vc->write.triggered)
   write_to_net(this, vc, trigger_event->ethread);
-else if (!vc->write.enabled) {
+else if (vc->write.error) {
+  int err = 0, errlen = sizeof(int);
+  if (getsockopt(vc->con.fd, SOL_SOCKET, SO_ERROR, , (socklen_t 
*)) == -1) {
+err = errno;
+  }
+  if (err != EAGAIN && err != EINTR)
+vc->writeSignalError(this, err);
+} else if (!vc->write.enabled) {
--- End diff --

suggest code: 
```
else {
  if (vc->write.error) {
  ...
if (err && err != EAGAIN && err != EINTR)
  vc->writeSignalError(this, err);
else
  vc->write.error = 0;
  }
  if (!vc->write.enabled) {
  ...
  }
}
```
the same to READ.


Issue Time Tracking
---

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

> ATS not closing origin connections on first RST from client
> ---
>
> Key: TS-4796
> URL: https://issues.apache.org/jira/browse/TS-4796
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
>  Time Spent: 4h 10m
>  Remaining Estimate: 0h
>
> *TLDR; similar to TS-4720 -- slower to close than it should, instead of never 
> closing*
> As a continuation of TS-4720, while testing that the session is closed when 
> we expect-- I found that it isn't.
> Although we are now closing the sessions, we aren't doing it as quickly as we 
> should. In this client abort case we expect the client to abort, and ATS 
> should initially continue to send bytes to the client-- as we are in the 
> half-open state. After the first set of bytes are sent to the client-- the 
> client will send an RST-- which should signal ATS to stop sending the request 
> (and tear down the origin connection etc.).
> I'm able to reproduce this locally, and the debug output (with some 
> additional comments) looks like below:
> {code}
> < FIN FROM CLIENT >
> [Aug 29 18:25:07.491] Server {0x7effa538a800} DEBUG:  (main_handler)> (http) [0] [HttpSM::main_handler, VC_EVENT_EOS]
> [Aug 29 18:25:07.491] Server {0x7effa538a800} DEBUG:  (state_watch_for_client_abort)> (http) [0] 
> [::state_watch_for_client_abort, VC_EVENT_EOS]
> < RST FROM CLIENT >
> Got an HttpTunnel event 100 
> [Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG:  (producer_handler)> (http_tunnel) [0] producer_handler [http server 
> VC_EVENT_READ_READY]
> [Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG:  (producer_handler_chunked)> (http_tunnel) [0] producer_handler_chunked [http 
> server VC_EVENT_READ_READY]
> [Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG:  (read_size)> (http_chunk) read chunk size of 15 bytes
> [Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG:  (read_chunk)> (http_chunk) completed read of chunk of 15 bytes
> [Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG:  (producer_handler)> (http_redirect) [HttpTunnel::producer_handler] 
> enable_redirection: [1 0 0] event: 100
> Got an HttpTunnel event 101 
> [Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG:  (consumer_handler)> (http_tunnel) [0] consumer_handler [user agent 
> VC_EVENT_WRITE_READY]
> write ready consumer_handler
> {code}
> In this situation the connection doesn't close here at the RST-- but rather 
> on the next set of bytes from the origin to send-- which end up tripping a 
> VC_EVENT_ERROR-- and tearing down the connection.
> When the client sends the first RST epoll returns a WRITE_READY event -- 
> which the HTTPTunnel consumer ignores completely. It seems then that when we 
> recieve the WRITE_READY event we need to determine if we are already in the 
> writing state-- and if so, then we should stop the transaction (since we are 
> already edge-triggered).



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


[jira] [Work logged] (TS-4769) TSSslServerContextCreate always returns null

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

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

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

Author: ASF GitHub Bot
Created on: 05/Sep/16 08:42
Start Date: 05/Sep/16 08:42
Worklog Time Spent: 10m 
  Work Description: GitHub user biilmann opened a pull request:

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

Fix SSLCreateServerContext always returning null

This fixes TS-4769 but would like @shinrich's thoughts on whether this 
makes sense semantically.

The fix is to let the `SSLCreateServerContext` set the 
`SSLCertContext::OPT_TUNNEL` option on the `sslMultCertSettings` object, which 
in this case makes the call to `SSLInitServerContext` do the right thing and 
not look for any certificates in the multicert settings object and just 
initialize the context. 

What I'm not certain of is whether using OPT_TUNNEL for this could cause 
any confusion in the future...

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

$ git pull https://github.com/biilmann/trafficserver 
fix-ssl-create-server-context

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

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


commit d0850c662fd192518aab2ec96332c4ab9cdb1ea5
Author: Mathias Biilmann Christensen 
Date:   2016-09-05T08:34:05Z

Fix SSLCreateServerContext always returning null




Issue Time Tracking
---

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

> TSSslServerContextCreate always returns null
> 
>
> Key: TS-4769
> URL: https://issues.apache.org/jira/browse/TS-4769
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SSL, TS API
>Reporter: Mathias Biilmann Christensen
>Assignee: Susan Hinrichs
>Priority: Blocker
> Fix For: 7.0.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The change to SSLInitServerContext in 
> https://github.com/apache/trafficserver/pull/810 breaks the 
> TSSslServerContextCreate API method, since this one calls 
> TSSslServerContextCreate with an empty sslMultCertSettings.
> This means plugins can't create a fresh SSL context and set the certificates 
> themselves.



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


[GitHub] trafficserver pull request #964: Fix SSLCreateServerContext always returning...

2016-09-05 Thread biilmann
GitHub user biilmann opened a pull request:

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

Fix SSLCreateServerContext always returning null

This fixes TS-4769 but would like @shinrich's thoughts on whether this 
makes sense semantically.

The fix is to let the `SSLCreateServerContext` set the 
`SSLCertContext::OPT_TUNNEL` option on the `sslMultCertSettings` object, which 
in this case makes the call to `SSLInitServerContext` do the right thing and 
not look for any certificates in the multicert settings object and just 
initialize the context. 

What I'm not certain of is whether using OPT_TUNNEL for this could cause 
any confusion in the future...

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

$ git pull https://github.com/biilmann/trafficserver 
fix-ssl-create-server-context

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

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


commit d0850c662fd192518aab2ec96332c4ab9cdb1ea5
Author: Mathias Biilmann Christensen 
Date:   2016-09-05T08:34:05Z

Fix SSLCreateServerContext always returning null




---
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-4195) out of traffic_manager causes a double free in traffic_server

2016-09-05 Thread Dimitry Andric (JIRA)

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

Dimitry Andric commented on TS-4195:


Possibly related to the fix for TS-3863.

> out of traffic_manager causes a double free in traffic_server
> -
>
> Key: TS-4195
> URL: https://issues.apache.org/jira/browse/TS-4195
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Leif Hedstrom
>Assignee: Bryan Call
>Priority: Blocker
> Fix For: 7.0.0
>
>
> While testing stuff, I was running traffic_manager from command line, and 
> then I get a crash from traffic_server:
> {code}
> root@loki 407/0 # ./bin/traffic_manager
> [E. Mgmt] log ==> [TrafficManager] using root directory '/opt/ats'
> traffic_server: using root directory '/opt/ats'
> ^C[TrafficManager] ==> Cleaning up and reissuing signal #2
> traffic_server: Interrupt (Signal sent by the kernel 0 0)
> 9083 sent by kill()*** Error in `/opt/ats/bin/traffic_server': corrupted 
> double-linked list: 0x028f8940 ***
> === Backtrace: =
> /lib64/libc.so.6(+0x77da5)[0x2ad58f3fcda5]
> /lib64/libc.so.6(+0x80c06)[0x2ad58f405c06]
> /lib64/libc.so.6(cfree+0x4c)[0x2ad58f408cac]
> /lib64/libc.so.6(+0x39685)[0x2ad58f3be685]
> /lib64/libc.so.6(+0x396a5)[0x2ad58f3be6a5]
> /opt/ats/bin/traffic_server[0x4e300atraffic_server: Segmentation fault 
> (Address not mapped to object [0x55b02140])
> traffic_server - STACK TRACE:
> /lib64/libc.so.6(nanosleep+0x2d)[0x2ad58f44d7ad]
> /opt/ats/bin/traffic_server(_Z19crash_logger_invokeiP9siginfo_tPv+0x8e)[0x4abece]
> /lib64/libpthread.so.0(+0x109f0)[0x2ad58e3709f0]
> /lib64/libc.so.6(sleep+0xd4)[0x2ad58f44d644]
> /opt/ats/bin/traffic_server(_Z19startProcessManagerPv+0xb1)[0x69b8a1]
> /lib64/libpthread.so.0(+0x760a)[0x2ad58e36760a]
> /lib64/libc.so.6(clone+0x6d)[0x2ad58f487a4d]
> === Memory map: 
> /lib64/libc.so.6(+0x395ad)[0x2ad58f3be5ad]
> 0040-008a6000 r-xp  00:24 1775473
> /opt/ats/bin/traffic_server
> 00aa6000-00ab3000 r--p 004a6000 00:24 1775473
> /opt/ats/bin/traffic_server
> 00ab3000-00ab9000 rw-p 004b3000 00:24 1775473
> /opt/ats/bin/traffic_server
> 00ab9000-01097000 rw-p  00:00 0
> 028dd000-02cb9000 rw-p  00:00 0  
> [heap]
> 2ad58c52c000-2ad58c54d000 r-xp  00:24 1389899
> /usr/lib64/ld-2.22.so
> 2ad58c54d000-2ad58c55 rw-p  00:00 0
> 2ad58c55-2ad58c56 rwxp  00:00 0
> 2ad58c56b000-2ad58c6ed000 rw-p  00:00 0
> 2ad58c6ed000-2ad58c6fd000 rwxp  00:00 0
> 2ad58c6fd000-2ad58c748000 rw-p  00:00 0
> 2ad58c74c000-2ad58c74d000 r--p 0002 00:24 1389899
> /usr/lib64/ld-2.22.so
> 2ad58c74d000-2ad58c74e000 rw-p 00021000 00:24 1389899
> /usr/lib64/ld-2.22.so
> 2ad58c74e000-2ad58c74f000 rw-p  00:00 0
> 2ad58c74f000-2ad58c79 r-xp  00:24 1775306
> /opt/ats/lib/libtsutil.so.6.2.0
> 2ad58c79-2ad58c99 ---p 00041000 00:24 1775306
> /opt/ats/lib/libtsutil.so.6.2.0
> 2ad58c99-2ad58c991000 r--p 00041000 00:24 1775306
> /opt/ats/lib/libtsutil.so.6.2.0
> 2ad58c991000-2ad58c993000 rw-p 00042000 00:24 1775306
> /opt/ats/lib/libtsutil.so.6.2.0
> 2ad58c993000-2ad58c994000 rw-p  00:00 0
> 2ad58c994000-2ad58c9cb000 r-xp  00:24 1393339
> /usr/lib64/libhwloc.so.5.6.6
> 2ad58c9cb000-2ad58cbcb000 ---p 00037000 00:24 1393339
> /usr/lib64/libhwloc.so.5.6.6
> 2ad58cbcb000-2ad58cbcc000 r--p 00037000 00:24 1393339
> /usr/lib64/libhwloc.so.5.6.6
> 2ad58cbcc000-2ad58cbcd000 rw-p 00038000 00:24 1393339
> /usr/lib64/libhwloc.so.5.6.6
> 2ad58cbcd000-2ad58cd77000 r-xp  00:24 1441754
> /usr/lib64/libtcl8.6.so
> 2ad58cd77000-2ad58cf77000 ---p 001aa000 00:24 1441754  
> /lib64/libc.so.6(  /usr/lib64/libtcl8.6.so
> 2ad58cf77000-2ad58cf86000 r--p 001aa000 00:24 1441754
> /usr/lib64/libtcl8.6.so
> 2ad58cf86000-2ad58cf87000 rw-p 001b9000 00:24 1441754
> /usr/lib64/libtcl8.6.so
> 2ad58cf87000-2ad58cf88000 rw-p  00:00 0
> 2ad58cf88000-2ad58cf9f000 r-xp  00:24 1389936
> /usr/lib64/libresolv-2.22.so
> 2ad58cf9f000-2ad58d19f000 ---p 00017000 00:24 1389936
> /usr/lib64/libresolv-2.22.so
> 2ad58d19f000-2ad58d1a r--p 00017000 00:24 1389936
> /usr/lib64/libresolv-2.22.so
> 2ad58d1a-2ad58d1a1000 rw-p 00018000 00:24 1389936
> 

[jira] [Work logged] (TS-4797) Backslash-escape is not allowed in rewriting rules

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

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

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

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

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



Issue Time Tracking
---

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

> Backslash-escape is not allowed in rewriting rules
> --
>
> Key: TS-4797
> URL: https://issues.apache.org/jira/browse/TS-4797
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: Masaori Koshiba
> Fix For: 7.0.0
>
>  Time Spent: 2h
>  Remaining Estimate: 0h
>
> I noticed that backslash-escape in quoted-string is not allowed in 
> header-rewrite plugin rules. IIRC, this is allowed in 5.3.x.
> e.g.
> {noformat}
> cond %{SEND_RESPONSE_HDR_HOOK}
> add-header Public-Key-Pins 
> "pin-sha256=\"UgXZQmS15cJoBeWTvbmCE+PGw5/oHV00e+MMyuXr0YQ=\"; 
> pin-sha256=\"eYKlKmvqHnR4CsglcYuNzvro7rrmFINrje5nSAxnEsc=\"; max-age=600; 
> includeSubDomains" [L]
> {noformat}
> I got below error
> {noformat}
> 20160830.16h19m34s [header_rewrite] malformed line "add-header 
> Public-Key-Pins "pin-sha256=\"UgXZQmS15cJoBeWTvbmCE+PGw5/oHV00e+MMyuXr0YQ=\"; 
> pin-sha256=\"eYKlKmvqHnR4CsglcYuNzvro7rrmFINrje5nSAxnEsc=\"; max-age=600; 
> includeSubDomains" [L]" ignoring...
> {noformat}



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


[GitHub] trafficserver issue #951: TS-4797: Allow backslash-escape in header_rewrite ...

2016-09-05 Thread atsci
Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/951
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/697/ 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-4797) Backslash-escape is not allowed in rewriting rules

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

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

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

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

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



Issue Time Tracking
---

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

> Backslash-escape is not allowed in rewriting rules
> --
>
> Key: TS-4797
> URL: https://issues.apache.org/jira/browse/TS-4797
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: Masaori Koshiba
> Fix For: 7.0.0
>
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> I noticed that backslash-escape in quoted-string is not allowed in 
> header-rewrite plugin rules. IIRC, this is allowed in 5.3.x.
> e.g.
> {noformat}
> cond %{SEND_RESPONSE_HDR_HOOK}
> add-header Public-Key-Pins 
> "pin-sha256=\"UgXZQmS15cJoBeWTvbmCE+PGw5/oHV00e+MMyuXr0YQ=\"; 
> pin-sha256=\"eYKlKmvqHnR4CsglcYuNzvro7rrmFINrje5nSAxnEsc=\"; max-age=600; 
> includeSubDomains" [L]
> {noformat}
> I got below error
> {noformat}
> 20160830.16h19m34s [header_rewrite] malformed line "add-header 
> Public-Key-Pins "pin-sha256=\"UgXZQmS15cJoBeWTvbmCE+PGw5/oHV00e+MMyuXr0YQ=\"; 
> pin-sha256=\"eYKlKmvqHnR4CsglcYuNzvro7rrmFINrje5nSAxnEsc=\"; max-age=600; 
> includeSubDomains" [L]" ignoring...
> {noformat}



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


[GitHub] trafficserver issue #951: TS-4797: Allow backslash-escape in header_rewrite ...

2016-09-05 Thread atsci
Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/951
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/593/ 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-4797) Backslash-escape is not allowed in rewriting rules

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

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

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

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

https://github.com/apache/trafficserver/pull/951
  
Please take another look. 
I added test cases which @maskit pointed out. And allow backslash-escape 
outside of quoted-string too.


Issue Time Tracking
---

Worklog Id: (was: 28103)
Time Spent: 1h 40m  (was: 1.5h)

> Backslash-escape is not allowed in rewriting rules
> --
>
> Key: TS-4797
> URL: https://issues.apache.org/jira/browse/TS-4797
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: Masaori Koshiba
> Fix For: 7.0.0
>
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> I noticed that backslash-escape in quoted-string is not allowed in 
> header-rewrite plugin rules. IIRC, this is allowed in 5.3.x.
> e.g.
> {noformat}
> cond %{SEND_RESPONSE_HDR_HOOK}
> add-header Public-Key-Pins 
> "pin-sha256=\"UgXZQmS15cJoBeWTvbmCE+PGw5/oHV00e+MMyuXr0YQ=\"; 
> pin-sha256=\"eYKlKmvqHnR4CsglcYuNzvro7rrmFINrje5nSAxnEsc=\"; max-age=600; 
> includeSubDomains" [L]
> {noformat}
> I got below error
> {noformat}
> 20160830.16h19m34s [header_rewrite] malformed line "add-header 
> Public-Key-Pins "pin-sha256=\"UgXZQmS15cJoBeWTvbmCE+PGw5/oHV00e+MMyuXr0YQ=\"; 
> pin-sha256=\"eYKlKmvqHnR4CsglcYuNzvro7rrmFINrje5nSAxnEsc=\"; max-age=600; 
> includeSubDomains" [L]" ignoring...
> {noformat}



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


[GitHub] trafficserver issue #951: TS-4797: Allow backslash-escape in header_rewrite ...

2016-09-05 Thread masaori335
Github user masaori335 commented on the issue:

https://github.com/apache/trafficserver/pull/951
  
Please take another look. 
I added test cases which @maskit pointed out. And allow backslash-escape 
outside of quoted-string too.


---
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-4797) Backslash-escape is not allowed in rewriting rules

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

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

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

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

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



Issue Time Tracking
---

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

> Backslash-escape is not allowed in rewriting rules
> --
>
> Key: TS-4797
> URL: https://issues.apache.org/jira/browse/TS-4797
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: Masaori Koshiba
> Fix For: 7.0.0
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> I noticed that backslash-escape in quoted-string is not allowed in 
> header-rewrite plugin rules. IIRC, this is allowed in 5.3.x.
> e.g.
> {noformat}
> cond %{SEND_RESPONSE_HDR_HOOK}
> add-header Public-Key-Pins 
> "pin-sha256=\"UgXZQmS15cJoBeWTvbmCE+PGw5/oHV00e+MMyuXr0YQ=\"; 
> pin-sha256=\"eYKlKmvqHnR4CsglcYuNzvro7rrmFINrje5nSAxnEsc=\"; max-age=600; 
> includeSubDomains" [L]
> {noformat}
> I got below error
> {noformat}
> 20160830.16h19m34s [header_rewrite] malformed line "add-header 
> Public-Key-Pins "pin-sha256=\"UgXZQmS15cJoBeWTvbmCE+PGw5/oHV00e+MMyuXr0YQ=\"; 
> pin-sha256=\"eYKlKmvqHnR4CsglcYuNzvro7rrmFINrje5nSAxnEsc=\"; max-age=600; 
> includeSubDomains" [L]" ignoring...
> {noformat}



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


[jira] [Work logged] (TS-4797) Backslash-escape is not allowed in rewriting rules

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

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

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

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

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



Issue Time Tracking
---

Worklog Id: (was: 28102)
Time Spent: 1.5h  (was: 1h 20m)

> Backslash-escape is not allowed in rewriting rules
> --
>
> Key: TS-4797
> URL: https://issues.apache.org/jira/browse/TS-4797
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: Masaori Koshiba
> Fix For: 7.0.0
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> I noticed that backslash-escape in quoted-string is not allowed in 
> header-rewrite plugin rules. IIRC, this is allowed in 5.3.x.
> e.g.
> {noformat}
> cond %{SEND_RESPONSE_HDR_HOOK}
> add-header Public-Key-Pins 
> "pin-sha256=\"UgXZQmS15cJoBeWTvbmCE+PGw5/oHV00e+MMyuXr0YQ=\"; 
> pin-sha256=\"eYKlKmvqHnR4CsglcYuNzvro7rrmFINrje5nSAxnEsc=\"; max-age=600; 
> includeSubDomains" [L]
> {noformat}
> I got below error
> {noformat}
> 20160830.16h19m34s [header_rewrite] malformed line "add-header 
> Public-Key-Pins "pin-sha256=\"UgXZQmS15cJoBeWTvbmCE+PGw5/oHV00e+MMyuXr0YQ=\"; 
> pin-sha256=\"eYKlKmvqHnR4CsglcYuNzvro7rrmFINrje5nSAxnEsc=\"; max-age=600; 
> includeSubDomains" [L]" ignoring...
> {noformat}



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


[GitHub] trafficserver issue #951: TS-4797: Allow backslash-escape in header_rewrite ...

2016-09-05 Thread atsci
Github user atsci commented on the issue:

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



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


[GitHub] trafficserver issue #951: TS-4797: Allow backslash-escape in header_rewrite ...

2016-09-05 Thread atsci
Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/951
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/592/ 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] [Updated] (TS-4816) ATS 6.2.0 - crashing with broken pipe, sig11 segmentation fault

2016-09-05 Thread David Brodin (JIRA)

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

David Brodin updated TS-4816:
-
Attachment: ats_gdb-160905.txt

Attached is the output from gdb.
Nothing super-exciting to me, but maybe to you.

Anything else I can do to get better logs?

> ATS 6.2.0 - crashing with broken pipe, sig11 segmentation fault
> ---
>
> Key: TS-4816
> URL: https://issues.apache.org/jira/browse/TS-4816
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Manager
>Reporter: David Brodin
>  Labels: crash
> Fix For: 7.0.0
>
> Attachments: ats_gdb-160905.txt, crash-2016-09-05-075309.log
>
>
> Hi,
> We just upgraded to ATS 6.2.0 via FreeBSD ports:
> {noformat}
> [root@ ~]# uname -a
> FreeBSD  10.3-RELEASE-p7 FreeBSD 10.3-RELEASE-p7 #0: Thu Aug 11 
> 18:38:15 UTC 2016 
> r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64
> [root@ ~]# pkg info | grep traff
> trafficserver-6.2.0Fast, scalable and extensible HTTP proxy server
> {noformat}
> We are experiencing crashes, usually during the day, hardly any during "low" 
> loads, but the mest affecting crashes occur in the early mornings. Along with 
> this we can see a memory leak aswell
> We are using ATS as an enterprise proxy to the Internet, and as we have a 
> very good Internet-connection we have also disabled caching.
> I'm not sure how I would attach files so here goes :)
> manager.log
> {noformat}
> [Sep  2 11:48:28.017] Manager {0x804006400} ERROR: 
> [LocalManager::sendMgmtMsgToProcesses] Error writing message
> [Sep  2 11:48:28.017] Manager {0x804006400} ERROR:  (mgmt_elog)>  (last system error 32: Broken pipe)
> [Sep  2 11:48:38.305] {0x804006400} STATUS: opened 
> /var/log/trafficserver/manager.log
> [Sep  2 11:48:38.305] {0x804006400} NOTE:  (reconfigure_diags)> updated diags config
> [Sep  2 11:48:38.311] Manager {0x804006400} NOTE: [ClusterCom::ClusterCom] 
> Node running on OS: 'FreeBSD' Release: '10.3-RELEASE-p7'
> [Sep  2 11:48:38.312] Manager {0x804006400} NOTE: 
> [LocalManager::listenForProxy] Listening on port: 8080 (IPv4)
> [Sep  2 11:48:38.313] Manager {0x804006400} NOTE: 
> [LocalManager::listenForProxy] Listening on port: 8080 (IPv6)
> [Sep  2 11:48:38.313] Manager {0x804006400} NOTE: [TrafficManager] Setup 
> complete
> [Sep  2 11:48:39.321] Manager {0x804006400} NOTE: [LocalManager::startProxy] 
> Launching ts process
> [Sep  2 11:48:39.336] Manager {0x804006400} NOTE: 
> [LocalManager::pollMgmtProcessServer] New process connecting fd '17'
> [Sep  2 11:48:39.336] Manager {0x804006400} NOTE: [Alarms::signalAlarm] 
> Server Process born
> [Sep  2 11:51:32.574] Manager {0x804006400} ERROR: 
> [LocalManager::sendMgmtMsgToProcesses] Error writing message
> [Sep  2 11:51:32.574] Manager {0x804006400} ERROR:  (mgmt_elog)>  (last system error 32: Broken pipe)
> [Sep  2 11:51:32.669] Manager {0x804006400} ERROR: 
> [LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig 
> 11: Segmentation fault
> [Sep  2 11:51:32.669] Manager {0x804006400} ERROR: [Alarms::signalAlarm] 
> Server Process was reset
> [Sep  2 11:51:33.674] Manager {0x804006400} NOTE: [LocalManager::startProxy] 
> Launching ts process
> [Sep  2 11:51:33.689] Manager {0x804006400} NOTE: 
> [LocalManager::pollMgmtProcessServer] New process connecting fd '13'
> [Sep  2 11:51:33.690] Manager {0x804006400} NOTE: [Alarms::signalAlarm] 
> Server Process born
> [Sep  3 04:14:35.380] Manager {0x804006400} ERROR: 
> [LocalManager::sendMgmtMsgToProcesses] Error writing message
> [Sep  3 04:14:35.380] Manager {0x804006400} ERROR:  (mgmt_elog)>  (last system error 32: Broken pipe)
> [Sep  3 04:14:35.748] Manager {0x804006400} ERROR: 
> [LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig 
> 11: Segmentation fault
> [Sep  3 04:14:35.748] Manager {0x804006400} ERROR: [Alarms::signalAlarm] 
> Server Process was reset
> [Sep  3 04:14:36.814] Manager {0x804006400} NOTE: [LocalManager::startProxy] 
> Launching ts process
> [Sep  3 04:14:36.828] Manager {0x804006400} NOTE: 
> [LocalManager::pollMgmtProcessServer] New process connecting fd '13'
> [Sep  3 04:14:36.829] Manager {0x804006400} NOTE: [Alarms::signalAlarm] 
> Server Process born
> {noformat}
> traffic.out - since this isnt timestamped I'm not sure if I'm leaving some of 
> the stacktrace out:
> {noformat}
> traffic_server[TrafficManager] ==> Cleaning up and reissuing signal #15
> : Terminated
> traffic_server: Terminatedtraffic_servertraffic_servertraffic_server: 
> Segmentation fault
> traffic_server - STACK TRACE:
> 0x4af409 <_Z19crash_logger_invokeiP9__siginfoPv+0x69> at 
> /usr/local/bin/traffic_server
> 0x802735b37  at /lib/libthr.so.3
> 0x80273522c  at 

[jira] [Commented] (TS-4813) HttpTunnel.cc:1215: failed assertion `p->alive == true || event == HTTP_TUNNEL_EVENT_PRECOMPLETE ...

2016-09-05 Thread Masaori Koshiba (JIRA)

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

Masaori Koshiba commented on TS-4813:
-

On frame #6, {{VC_EVENT_ACTIVE_TIMEOUT}} (event=106) is happened. Recently, 
some changes around active timeout is added in H2 by TS-4167.
I doubt that TS-4167 exposed some hidden bugs.

> HttpTunnel.cc:1215: failed assertion `p->alive == true || event == 
> HTTP_TUNNEL_EVENT_PRECOMPLETE ...
> 
>
> Key: TS-4813
> URL: https://issues.apache.org/jira/browse/TS-4813
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Network
>Reporter: Leif Hedstrom
>Priority: Critical
> Fix For: 7.0.0
>
>
> Seeing this with current (as of right now) master, on docs.trafficserver:
> {code}
> FATAL: HttpTunnel.cc:1215: failed assertion `p->alive == true || event == 
> HTTP_TUNNEL_EVENT_PRECOMPLETE || event == VC_EVENT_EOS || 
> sm->enable_redirection || (p->self_consumer && p->self_consumer->alive == 
> true)`
> traffic_server: using root directory '/opt/ats'
> traffic_server: Aborted (Signal sent by tkill() 13188 99)
> traffic_server - STACK TRACE:
> /opt/ats/lib/libtsutil.so.7(signal_crash_handler(int, siginfo_t*, 
> void*)+0x18)[0x2b6d1031729e]
> /opt/ats/bin/traffic_server(crash_logger_invoke(int, siginfo_t*, 
> void*)+0x155)[0x534104]
> /lib64/libpthread.so.0(+0xf100)[0x2b6d1240f100]
> /lib64/libc.so.6(gsignal+0x37)[0x2b6d12d6e5f7]
> /lib64/libc.so.6(abort+0x148)[0x2b6d12d6fce8]
> /opt/ats/lib/libtsutil.so.7(ink_warning(char const*, ...)+0x0)[0x2b6d102f6f4d]
> /opt/ats/lib/libtsutil.so.7(+0x733a7)[0x2b6d102f13a7]
> /opt/ats/bin/traffic_server(HttpTunnel::producer_handler(int, 
> HttpTunnelProducer*)+0xd14)[0x768a12]
> /opt/ats/bin/traffic_server(HttpTunnel::main_handler(int, 
> void*)+0x13b)[0x76b6e1]
> /opt/ats/bin/traffic_server(Continuation::handleEvent(int, 
> void*)+0x149)[0x53a621]
> /opt/ats/bin/traffic_server(HttpSM::state_watch_for_client_abort(int, 
> void*)+0x9fe)[0x68c5e6]
> /opt/ats/bin/traffic_server(HttpSM::main_handler(int, void*)+0x58e)[0x69b7ec]
> /opt/ats/bin/traffic_server(Continuation::handleEvent(int, 
> void*)+0x149)[0x53a621]
> /opt/ats/bin/traffic_server(Http2Stream::main_event_handler(int, 
> void*)+0x59f)[0x79c1df]
> /opt/ats/bin/traffic_server(Continuation::handleEvent(int, 
> void*)+0x149)[0x53a621]
> /opt/ats/bin/traffic_server(EThread::process_event(Event*, 
> int)+0x2cf)[0xa809fb]
> /opt/ats/bin/traffic_server(EThread::execute()+0x671)[0xa8140f]
> /opt/ats/bin/traffic_server[0xa7f407]
> /lib64/libpthread.so.0(+0x7dc5)[0x2b6d12407dc5]
> /lib64/libc.so.6(clone+0x6d)[0x2b6d12e2fced]
> {code}



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


[jira] [Commented] (TS-4813) HttpTunnel.cc:1215: failed assertion `p->alive == true || event == HTTP_TUNNEL_EVENT_PRECOMPLETE ...

2016-09-05 Thread Masakazu Kitajo (JIRA)

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

Masakazu Kitajo commented on TS-4813:
-

I have no idea. I looked into it but I couldn't reproduce the situation.

> HttpTunnel.cc:1215: failed assertion `p->alive == true || event == 
> HTTP_TUNNEL_EVENT_PRECOMPLETE ...
> 
>
> Key: TS-4813
> URL: https://issues.apache.org/jira/browse/TS-4813
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Network
>Reporter: Leif Hedstrom
>Priority: Critical
> Fix For: 7.0.0
>
>
> Seeing this with current (as of right now) master, on docs.trafficserver:
> {code}
> FATAL: HttpTunnel.cc:1215: failed assertion `p->alive == true || event == 
> HTTP_TUNNEL_EVENT_PRECOMPLETE || event == VC_EVENT_EOS || 
> sm->enable_redirection || (p->self_consumer && p->self_consumer->alive == 
> true)`
> traffic_server: using root directory '/opt/ats'
> traffic_server: Aborted (Signal sent by tkill() 13188 99)
> traffic_server - STACK TRACE:
> /opt/ats/lib/libtsutil.so.7(signal_crash_handler(int, siginfo_t*, 
> void*)+0x18)[0x2b6d1031729e]
> /opt/ats/bin/traffic_server(crash_logger_invoke(int, siginfo_t*, 
> void*)+0x155)[0x534104]
> /lib64/libpthread.so.0(+0xf100)[0x2b6d1240f100]
> /lib64/libc.so.6(gsignal+0x37)[0x2b6d12d6e5f7]
> /lib64/libc.so.6(abort+0x148)[0x2b6d12d6fce8]
> /opt/ats/lib/libtsutil.so.7(ink_warning(char const*, ...)+0x0)[0x2b6d102f6f4d]
> /opt/ats/lib/libtsutil.so.7(+0x733a7)[0x2b6d102f13a7]
> /opt/ats/bin/traffic_server(HttpTunnel::producer_handler(int, 
> HttpTunnelProducer*)+0xd14)[0x768a12]
> /opt/ats/bin/traffic_server(HttpTunnel::main_handler(int, 
> void*)+0x13b)[0x76b6e1]
> /opt/ats/bin/traffic_server(Continuation::handleEvent(int, 
> void*)+0x149)[0x53a621]
> /opt/ats/bin/traffic_server(HttpSM::state_watch_for_client_abort(int, 
> void*)+0x9fe)[0x68c5e6]
> /opt/ats/bin/traffic_server(HttpSM::main_handler(int, void*)+0x58e)[0x69b7ec]
> /opt/ats/bin/traffic_server(Continuation::handleEvent(int, 
> void*)+0x149)[0x53a621]
> /opt/ats/bin/traffic_server(Http2Stream::main_event_handler(int, 
> void*)+0x59f)[0x79c1df]
> /opt/ats/bin/traffic_server(Continuation::handleEvent(int, 
> void*)+0x149)[0x53a621]
> /opt/ats/bin/traffic_server(EThread::process_event(Event*, 
> int)+0x2cf)[0xa809fb]
> /opt/ats/bin/traffic_server(EThread::execute()+0x671)[0xa8140f]
> /opt/ats/bin/traffic_server[0xa7f407]
> /lib64/libpthread.so.0(+0x7dc5)[0x2b6d12407dc5]
> /lib64/libc.so.6(clone+0x6d)[0x2b6d12e2fced]
> {code}



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

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

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

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

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

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



Issue Time Tracking
---

Worklog Id: (was: 28100)
Time Spent: 2h 40m  (was: 2.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
>Assignee: Jari Alhonen
>  Labels: newbie
> Fix For: 7.0.0
>
>  Time Spent: 2h 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 issue #887: TS-2258: Mark whether configs are reloadable (part...

2016-09-05 Thread atsci
Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/887
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/591/ 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-2258) Verify that all fields are correct in RecordsConfig.cc

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

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

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

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

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



Issue Time Tracking
---

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

> 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.0.0
>
>  Time Spent: 2.5h
>  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 issue #887: TS-2258: Mark whether configs are reloadable (part...

2016-09-05 Thread atsci
Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/887
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/695/ 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-2258) Verify that all fields are correct in RecordsConfig.cc

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

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

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

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

https://github.com/apache/trafficserver/pull/887
  
Just pushed a version to resolve the merge conflict, and also a change for 
the ui_enabled, which testing proved to be dynamic.


Issue Time Tracking
---

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

> 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.0.0
>
>  Time Spent: 2h 20m
>  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 issue #887: TS-2258: Mark whether configs are reloadable (part...

2016-09-05 Thread alhonen
Github user alhonen commented on the issue:

https://github.com/apache/trafficserver/pull/887
  
Just pushed a version to resolve the merge conflict, and also a change for 
the ui_enabled, which testing proved to be dynamic.


---
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] [Comment Edited] (TS-4816) ATS 6.2.0 - crashing with broken pipe, sig11 segmentation fault

2016-09-05 Thread David Brodin (JIRA)

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

David Brodin edited comment on TS-4816 at 9/5/16 6:07 AM:
--

Found the traffic_crashlog command.
ATS crashed again this morning, but no coredump even with the records.config 
set.
I'll try to attach gdb to the process instead as according to the wiki.



> ATS 6.2.0 - crashing with broken pipe, sig11 segmentation fault
> ---
>
> Key: TS-4816
> URL: https://issues.apache.org/jira/browse/TS-4816
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Manager
>Reporter: David Brodin
>  Labels: crash
> Fix For: 7.0.0
>
> Attachments: crash-2016-09-05-075309.log
>
>
> Hi,
> We just upgraded to ATS 6.2.0 via FreeBSD ports:
> {noformat}
> [root@ ~]# uname -a
> FreeBSD  10.3-RELEASE-p7 FreeBSD 10.3-RELEASE-p7 #0: Thu Aug 11 
> 18:38:15 UTC 2016 
> r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64
> [root@ ~]# pkg info | grep traff
> trafficserver-6.2.0Fast, scalable and extensible HTTP proxy server
> {noformat}
> We are experiencing crashes, usually during the day, hardly any during "low" 
> loads, but the mest affecting crashes occur in the early mornings. Along with 
> this we can see a memory leak aswell
> We are using ATS as an enterprise proxy to the Internet, and as we have a 
> very good Internet-connection we have also disabled caching.
> I'm not sure how I would attach files so here goes :)
> manager.log
> {noformat}
> [Sep  2 11:48:28.017] Manager {0x804006400} ERROR: 
> [LocalManager::sendMgmtMsgToProcesses] Error writing message
> [Sep  2 11:48:28.017] Manager {0x804006400} ERROR:  (mgmt_elog)>  (last system error 32: Broken pipe)
> [Sep  2 11:48:38.305] {0x804006400} STATUS: opened 
> /var/log/trafficserver/manager.log
> [Sep  2 11:48:38.305] {0x804006400} NOTE:  (reconfigure_diags)> updated diags config
> [Sep  2 11:48:38.311] Manager {0x804006400} NOTE: [ClusterCom::ClusterCom] 
> Node running on OS: 'FreeBSD' Release: '10.3-RELEASE-p7'
> [Sep  2 11:48:38.312] Manager {0x804006400} NOTE: 
> [LocalManager::listenForProxy] Listening on port: 8080 (IPv4)
> [Sep  2 11:48:38.313] Manager {0x804006400} NOTE: 
> [LocalManager::listenForProxy] Listening on port: 8080 (IPv6)
> [Sep  2 11:48:38.313] Manager {0x804006400} NOTE: [TrafficManager] Setup 
> complete
> [Sep  2 11:48:39.321] Manager {0x804006400} NOTE: [LocalManager::startProxy] 
> Launching ts process
> [Sep  2 11:48:39.336] Manager {0x804006400} NOTE: 
> [LocalManager::pollMgmtProcessServer] New process connecting fd '17'
> [Sep  2 11:48:39.336] Manager {0x804006400} NOTE: [Alarms::signalAlarm] 
> Server Process born
> [Sep  2 11:51:32.574] Manager {0x804006400} ERROR: 
> [LocalManager::sendMgmtMsgToProcesses] Error writing message
> [Sep  2 11:51:32.574] Manager {0x804006400} ERROR:  (mgmt_elog)>  (last system error 32: Broken pipe)
> [Sep  2 11:51:32.669] Manager {0x804006400} ERROR: 
> [LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig 
> 11: Segmentation fault
> [Sep  2 11:51:32.669] Manager {0x804006400} ERROR: [Alarms::signalAlarm] 
> Server Process was reset
> [Sep  2 11:51:33.674] Manager {0x804006400} NOTE: [LocalManager::startProxy] 
> Launching ts process
> [Sep  2 11:51:33.689] Manager {0x804006400} NOTE: 
> [LocalManager::pollMgmtProcessServer] New process connecting fd '13'
> [Sep  2 11:51:33.690] Manager {0x804006400} NOTE: [Alarms::signalAlarm] 
> Server Process born
> [Sep  3 04:14:35.380] Manager {0x804006400} ERROR: 
> [LocalManager::sendMgmtMsgToProcesses] Error writing message
> [Sep  3 04:14:35.380] Manager {0x804006400} ERROR:  (mgmt_elog)>  (last system error 32: Broken pipe)
> [Sep  3 04:14:35.748] Manager {0x804006400} ERROR: 
> [LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig 
> 11: Segmentation fault
> [Sep  3 04:14:35.748] Manager {0x804006400} ERROR: [Alarms::signalAlarm] 
> Server Process was reset
> [Sep  3 04:14:36.814] Manager {0x804006400} NOTE: [LocalManager::startProxy] 
> Launching ts process
> [Sep  3 04:14:36.828] Manager {0x804006400} NOTE: 
> [LocalManager::pollMgmtProcessServer] New process connecting fd '13'
> [Sep  3 04:14:36.829] Manager {0x804006400} NOTE: [Alarms::signalAlarm] 
> Server Process born
> {noformat}
> traffic.out - since this isnt timestamped I'm not sure if I'm leaving some of 
> the stacktrace out:
> {noformat}
> traffic_server[TrafficManager] ==> Cleaning up and reissuing signal #15
> : Terminated
> traffic_server: Terminatedtraffic_servertraffic_servertraffic_server: 
> Segmentation fault
> traffic_server - STACK TRACE:
> 0x4af409 <_Z19crash_logger_invokeiP9__siginfoPv+0x69> at 
> /usr/local/bin/traffic_server
> 0x802735b37