[jira] [Commented] (TS-3539) Close FD's before exec'ing crash logger "helper" app

2016-01-08 Thread James Peach (JIRA)

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

James Peach commented on TS-3539:
-

Yeh +1. There are also linux-specific extensions to accept(2), socket(2) and 
friends that add O_CLOEXEC.

> Close FD's before exec'ing crash logger "helper" app
> 
>
> Key: TS-3539
> URL: https://issues.apache.org/jira/browse/TS-3539
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: Leif Hedstrom
>Assignee: James Peach
> Fix For: 6.0.0
>
>




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


[jira] [Commented] (TS-3539) Close FD's before exec'ing crash logger "helper" app

2016-01-08 Thread Leif Hedstrom (JIRA)

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

Leif Hedstrom commented on TS-3539:
---

Please open a new Jira with these suggestions, since this is already closed and 
in 6.0.0.

> Close FD's before exec'ing crash logger "helper" app
> 
>
> Key: TS-3539
> URL: https://issues.apache.org/jira/browse/TS-3539
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: Leif Hedstrom
>Assignee: James Peach
> Fix For: 6.0.0
>
>




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


[jira] [Commented] (TS-3539) Close FD's before exec'ing crash logger "helper" app

2016-01-08 Thread Alan M. Carroll (JIRA)

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

Alan M. Carroll commented on TS-3539:
-

I've looked at this and I think rather than closing the files explicitly we 
should have {{traffic_server}} mark all of the HTTP proxy port sockets as 
"close on exec" {{FD_CLOEXEC}}. This could easily be done during the proxy port 
handling and would, IMHO< be a more robust solution.

> Close FD's before exec'ing crash logger "helper" app
> 
>
> Key: TS-3539
> URL: https://issues.apache.org/jira/browse/TS-3539
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: Leif Hedstrom
>Assignee: James Peach
> Fix For: 6.0.0
>
>




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


[jira] [Commented] (TS-3478) Indexing header representations on HPACK encoder

2016-01-08 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on TS-3478:


Github user masaori335 commented on the pull request:

https://github.com/apache/trafficserver/pull/391#issuecomment-170200715
  
I'm fine to ship this.

1. Actually I'm not big fun of names of classes and functions in HPACK 
starting with 'HTTP2'. But those confusions are going to be fixed in 
[TS-3967](https://issues.apache.org/jira/browse/TS-3967) with others.
2. Regression tests worked.


> Indexing header representations on HPACK encoder
> 
>
> Key: TS-3478
> URL: https://issues.apache.org/jira/browse/TS-3478
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HTTP/2
>Reporter: Ryo Okubo
>Assignee: Ryo Okubo
>  Labels: review
> Fix For: 6.1.0
>
> Attachments: indexing.patch
>
>
> Support other header field representations on HPACK encoder.
> http://tools.ietf.org/html/draft-ietf-httpbis-header-compression-12#section-6
> Currently the encoder supports only [Literal Header Field never 
> Indexed|http://tools.ietf.org/html/draft-ietf-httpbis-header-compression-12#section-6.2.3].



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


[jira] [Updated] (TS-3361) Plugin stats will randomly spike

2016-01-08 Thread Leif Hedstrom (JIRA)

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

Leif Hedstrom updated TS-3361:
--
Fix Version/s: (was: 6.1.0)

> Plugin stats will randomly spike
> 
>
> Key: TS-3361
> URL: https://issues.apache.org/jira/browse/TS-3361
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Metrics, Plugins
>Affects Versions: 4.2.0
>Reporter: Phil Sorber
>Assignee: Phil Sorber
>  Labels: C
>
> We are seeing some cases where stats from a plugin will randomly spike 
> unrealistically high. The specific place we see this is the remap_stats 
> plugin.



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


[jira] [Updated] (TS-3943) ATS 6 crash over and over again on restart under load

2016-01-08 Thread Leif Hedstrom (JIRA)

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

Leif Hedstrom updated TS-3943:
--
Fix Version/s: (was: 6.1.0)
   6.2.0

> ATS 6 crash over and over again on restart under load
> -
>
> Key: TS-3943
> URL: https://issues.apache.org/jira/browse/TS-3943
> Project: Traffic Server
>  Issue Type: Bug
>  Components: ICP
>Affects Versions: 6.0.0
>Reporter: Luca Rea
>Assignee: Leif Hedstrom
>  Labels: regresion
> Fix For: 6.2.0
>
>
> Hi,
> when ICP is enabled and ATS is under huge load a "service trafficserver stop" 
> followed by a "service trafficserver start" cause a crashing loop (ATS crash, 
> restart, crash again, restart, crash again... )
> {code}
> [E. Mgmt] log ==> [TrafficManager] using root directory '/usr/local'
> traffic_server: using root directory '/usr/local'
> traffic_server: Segmentation fault (Address not mapped to object 
> [(nil)])traffic_server - STACK TRACE:
> traffic_server: Segmentation fault (Address not mapped to object 
> [(nil)])traffic_server - STACK TRACE:
> /usr/local/bin/traffic_server(_Z19crash_logger_invokeiP7siginfoPv+0x99)[0x4a5809]
> /usr/local/bin/traffic_server(_Z19crash_logger_invokeiP7siginfoPv+0x99)[0x4a5809]
> /lib64/libc.so.6[0x31866326a0]
> /usr/local/bin/traffic_server(_ZN12ICPProcessor8ICPQueryEP12ContinuationP3URL+0xb6)[0x4aca16]
> /usr/local/bin/traffic_server(_ZN6HttpSM13do_icp_lookupEv+0x2c)[0x582c7c]
> /usr/local/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x28e)[0x59c3fe]
> /lib64/libc.so.6[0x31866326a0]
> /usr/local/bin/traffic_server(_ZN12ICPProcessor8ICPQueryEP12ContinuationP3URL+0xb6)[0x4aca16]
> /usr/local/bin/traffic_server(_ZN6HttpSM13do_icp_lookupEv+0x2c)[0x582c7c]
> /usr/local/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x28e)[0x59c3fe]
> /usr/local/bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x2ef)[0x595b5f]
> /usr/local/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x52e)[0x59c69e]
> /usr/local/bin/traffic_server(_ZN6HttpSM16do_hostdb_lookupEv+0x33a)[0x588a4a]
> /usr/local/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0xbde)[0x59cd4e]
> /usr/local/bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x2ef)[0x595b5f]
> /usr/local/bin/traffic_server(_ZN6HttpSM21state_cache_open_readEiPv+0x15c)[0x59a3fc]
> /usr/local/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0xd8)[0x5984f8]
> /usr/local/bin/traffic_server(_ZN11HttpCacheSM21state_cache_open_readEiPv+0x152)[0x5760a2]
> /usr/local/bin/traffic_server(_ZN5Cache9open_readEP12ContinuationPKN3ats10CryptoHashEP7HTTPHdrP21CacheLookupHttpConfig13CacheFragTypePKci+0x2b1)[0x6e26c1]
> /usr/local/bin/traffic_server(_ZN11HttpCacheSM9open_readEPK12HttpCacheKeyP3URLP7HTTPHdrP21CacheLookupHttpConfigl+0xbd)[0x57574d]
> /usr/local/bin/traffic_server(_ZN6HttpSM24do_cache_lookup_and_readEv+0x142)[0x5831d2]
> /usr/local/bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x2ef)[0x595b5f]
> /usr/local/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x7b6)[0x59c926]
> /usr/local/bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x2ef)[0x595b5f]
> /usr/local/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x52e)[0x59c69e]
> /usr/local/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x229)[0x59c399]
> /usr/local/bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x2ef)[0x595b5f]
> /usr/local/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x52e)[0x59c69e]
> /usr/local/bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x2ef)[0x595b5f]
> /usr/local/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x52e)[0x59c69e]
> /usr/local/bin/traffic_server(_ZN6HttpSM32state_read_client_request_headerEiPv+0x3dc)[0x59371c]
> /usr/local/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0xd8)[0x5984f8]
> /usr/local/bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x2b2)[0x595b22]
> /usr/local/bin/traffic_server(_ZN6HttpSM21attach_client_sessionEP17HttpClientSessionP14IOBufferReader+0x75f)[0x59d8cf]
> /usr/local/bin/traffic_server(_ZN17HttpClientSession15new_transactionEv+0xec)[0x5769dc]
> /usr/local/bin/traffic_server(_ZN18ProxyClientSession14do_api_calloutE12TSHttpHookID+0x14d)[0x4e585d]
> /usr/local/bin/traffic_server(_ZN17HttpClientSession14new_connectionEP14NetVConnectionP9MIOBufferP14IOBufferReaderb+0x224)[0x578654]
> /usr/local/bin/traffic_server(_ZN17HttpSessionAccept6acceptEP14NetVConnectionP9MIOBufferP14IOBufferReader+0x1ea)[0x5729ea]
> /usr/local/bin/traffic_server(_ZN23ProtocolProbeTrampoline17ioCompletionEventEiPv+0x483)[0x4e5343]
> /usr/local/bin/traffic_server[0x71eaf9]
> /usr/local/bin/traffic_server[0x723c0e]
> /usr/local/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x1f2)[0x7151d2]
> /usr/local/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x125)[0x742d05]
> 

[jira] [Resolved] (TS-3361) Plugin stats will randomly spike

2016-01-08 Thread Leif Hedstrom (JIRA)

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

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

> Plugin stats will randomly spike
> 
>
> Key: TS-3361
> URL: https://issues.apache.org/jira/browse/TS-3361
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Metrics, Plugins
>Affects Versions: 4.2.0
>Reporter: Phil Sorber
>Assignee: Phil Sorber
>  Labels: C
> Fix For: 6.1.0
>
>
> We are seeing some cases where stats from a plugin will randomly spike 
> unrealistically high. The specific place we see this is the remap_stats 
> plugin.



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