[jira] [Commented] (TS-4947) Collation Server is broken?

[bettydramit (JIRA)]

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

bettydramit commented on TS-4947:
-

yeah! Good jobs! It works!

> Collation Server is broken?
> ---
>
> Key: TS-4947
> URL: https://issues.apache.org/jira/browse/TS-4947
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Affects Versions: 7.0.0
>Reporter: bettydramit
>Assignee: James Peach
>Priority: Critical
> Fix For: 7.1.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> from gitmaster(github.com/apache/trafficserver)
> config Collation Client 
> {code:xml}
> CONFIG proxy.config.url_remap.filename STRING remap.config
> CONFIG proxy.config.log.config.filename STRING logging.config
> CONFIG proxy.config.log.collation_host STRING 192.168.2.33
> CONFIG proxy.config.log.collation_secret STRING testlog
> LOCAL proxy.local.log.collation_mode INT 2
> CONFIG proxy.config.log.collation_port INT 8085
> {code}
> config Collation Server
> {code:xml}
> CONFIG proxy.local.log.collation_mode INT 1
> CONFIG proxy.config.log.collation_port INT 8085
> CONFIG proxy.config.log.collation_secret STRING testlog
> {code}
> logging.config
> {code:xml}
> w3c = format {
>   Format='% %<{Cdn-Real-Ip}cqh> - % [%] \"% % 
> %\" % % \"%<{Referer}cqh>\" \"%<{user-agent}cqh>\" % 
> % % % % % %'
> }
> log.ascii {
>   Filename = 'c11',
>   Format = w3c,
>   CollationHosts = { '192.168.2.33:8085' }
> }
> {code}
> It still flush log to local disk not to remote collation server



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

[jira] [Resolved] (TS-4592) ts_lua: Add support for the UUID and HttpSM ID tags

[Kit Chan (JIRA)]

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

Kit Chan resolved TS-4592.
--
Resolution: Fixed

> ts_lua: Add support for the UUID and HttpSM ID tags
> ---
>
> Key: TS-4592
> URL: https://issues.apache.org/jira/browse/TS-4592
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Lua, Plugins
>Reporter: Kit Chan
>Assignee: Kit Chan
> Fix For: 7.1.0
>
>  Time Spent: 2.5h
>  Remaining Estimate: 0h
>
> Just like TS-4520
> we want a similar support in ts_lua



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

[jira] [Work started] (TS-4592) ts_lua: Add support for the UUID and HttpSM ID tags

[Kit Chan (JIRA)]

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

Work on TS-4592 started by Kit Chan.

> ts_lua: Add support for the UUID and HttpSM ID tags
> ---
>
> Key: TS-4592
> URL: https://issues.apache.org/jira/browse/TS-4592
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Lua, Plugins
>Reporter: Kit Chan
>Assignee: Kit Chan
> Fix For: 7.1.0
>
>  Time Spent: 2.5h
>  Remaining Estimate: 0h
>
> Just like TS-4520
> we want a similar support in ts_lua



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

Build failed in Jenkins: clang-analyzer #2704

[jenkins]

See 

Changes:

[amc] TS-4966: Fix process manager thread to support TS API.

[Kit Chan] TS-4592: Add support for process ID and txn ID in ts_lua

[Kit Chan] change to ts.process.uuid() and add error handling for it

--
[...truncated 5404 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... [ 70%] 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... [ 77%] 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/TSStatPeristence.en
reading sources... [ 79%] developer-guide/api/types/TSStatSync.en
reading sources... [ 79%] developer-guide/api/types/TSThreadPool.en
reading sources... [ 79%] developer-guide/api/types/TSUuid.en
reading sources... [ 80%] 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... [ 81%] 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... [ 82%] 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... [ 83%] developer-guide/debugging/debug-tags.en
reading sources... [ 83%] developer-guide/debugging/index.en
reading sources... [ 83%] developer-guide/debugging/memory-leaks.en
reading

[jira] [Work logged] (TS-4592) ts_lua: Add support for the UUID and HttpSM ID tags

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 14/Oct/16 01:59
Start Date: 14/Oct/16 01:59
Worklog Time Spent: 10m 
  Work Description: Github user shukitchan closed the pull request at:

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


Issue Time Tracking
---

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

> ts_lua: Add support for the UUID and HttpSM ID tags
> ---
>
> Key: TS-4592
> URL: https://issues.apache.org/jira/browse/TS-4592
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Lua, Plugins
>Reporter: Kit Chan
>Assignee: Kit Chan
> Fix For: 7.1.0
>
>  Time Spent: 2.5h
>  Remaining Estimate: 0h
>
> Just like TS-4520
> we want a similar support in ts_lua



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

[GitHub] trafficserver pull request #1089: TS-4592: Add support for process ID and tx...

[shukitchan]

Github user shukitchan closed the pull request at:

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


---
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 #1109: TS-4970: Crash in INKVConnInternal when handle_ev...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1109
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/901/ 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-4970) Crash in INKVConnInternal when handle_event is called after destroy()

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Crash in INKVConnInternal when handle_event is called after destroy()
> -
>
> Key: TS-4970
> URL: https://issues.apache.org/jira/browse/TS-4970
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> We've noticed a few crashes for requests using SPDY (on ATS 5.2.x and 6..x) 
> where the downstream origin is down with a backtrace that looks something 
> like:
> {code}
> (gdb) bt
> #0  0x in ?? ()
> #1  0x004cfe54 in set_continuation (this=0x2afe63a93530, event=1, 
> edata=0x2afe6399fc40) at ../iocore/eventsystem/P_VIO.h:104
> #2  INKVConnInternal::handle_event (this=0x2afe63a93530, event=1, 
> edata=0x2afe6399fc40) at InkAPI.cc:1060
> #3  0x006f8e65 in handleEvent (this=0x2afe3dd07000, e=0x2afe6399fc40, 
> calling_code=1) at I_Continuation.h:146
> #4  EThread::process_event (this=0x2afe3dd07000, e=0x2afe6399fc40, 
> calling_code=1) at UnixEThread.cc:144
> #5  0x006f993b in EThread::execute (this=0x2afe3dd07000)
> at UnixEThread.cc:195
> #6  0x006f832a in spawn_thread_internal (a=0x2afe3badf400)
> at Thread.cc:88
> #7  0x003861c079d1 in start_thread () from /lib64/libpthread.so.0
> #8  0x0038614e8b5d in clone () from /lib64/libc.so.6
> {code}
> Which looks a bit odd-- as frame 0 is missing. From digging into it a bit 
> more (with the help of [~amc]) we found that the VC we where calling was an 
> INKContInternal (meaning an INKVConnInternal):
> {code}
> (gdb) p (INKVConnInternal) *vc_server
> $5 = { = { = { = 
> { = { = {_vptr.force_VFPT_to_top = 
> 0x2afe63a93170}, 
>   handler = (int (Continuation::*)(Continuation *, int, 
> void *)) 0x4cfd90 , mutex = {
> m_ptr = 0x0}, link = {> = {next = 0x0}, 
> prev = 0x0}}, lerrno = 20600}, }, 
> mdata = 0xdeaddead, m_event_func = 0x2afe43c18490
>  <(anonymous namespace)::handleTransformationPluginEvents(TSCont, 
> TSEvent, void*)>, m_event_count = 0, m_closed = -1, m_deletable = 1, 
> m_deleted = 1, 
> m_free_magic = INKCONT_INTERN_MAGIC_ALIVE}, m_read_vio = {_cont = 0x0, 
> nbytes = 0, ndone = 0, op = 0, buffer = {mbuf = 0x0, entry = 0x0}, 
> vc_server = 0x0, mutex = {m_ptr = 0x0}}, m_write_vio = {_cont = 0x0, 
> nbytes = 122, ndone = 0, op = 0, buffer = {mbuf = 0x0, entry = 0x0}, 
> vc_server = 0x2afe63a93530, mutex = {m_ptr = 0x0}}, 
>   m_output_vc = 0x2afe63091a88}
> {code}
> From looking at the debug logs that lead up to the crash, I'm seeing that 
> some events (namely timeout events) are being called after the VConn has been 
> destroy()'d . This lead me to find that INKVConnInternal::handle_event is 
> actually checking if that is the case-- and then re-destroying everything, 
> which makes no sense.
> So although the ideal would be to not call handle_event on a closed VConn, 
> crashing is definitely not acceptable. My solution is to continue to only 
> call the event handler if the VConn hasn't been deleted-- but instead of 
> attempting to re-destroy the connection, we'll leave it be (unless we are in 
> debug mode-- where I'll throw in an assert).
> I did some looking at this on ATS7 and it looks like this is all fixed by the 
> cleanup of the whole free-ing stuff for VConns 
> (https://github.com/apache/trafficserver/pull/752/files).



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

[jira] [Work logged] (TS-4970) Crash in INKVConnInternal when handle_event is called after destroy()

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Crash in INKVConnInternal when handle_event is called after destroy()
> -
>
> Key: TS-4970
> URL: https://issues.apache.org/jira/browse/TS-4970
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> We've noticed a few crashes for requests using SPDY (on ATS 5.2.x and 6..x) 
> where the downstream origin is down with a backtrace that looks something 
> like:
> {code}
> (gdb) bt
> #0  0x in ?? ()
> #1  0x004cfe54 in set_continuation (this=0x2afe63a93530, event=1, 
> edata=0x2afe6399fc40) at ../iocore/eventsystem/P_VIO.h:104
> #2  INKVConnInternal::handle_event (this=0x2afe63a93530, event=1, 
> edata=0x2afe6399fc40) at InkAPI.cc:1060
> #3  0x006f8e65 in handleEvent (this=0x2afe3dd07000, e=0x2afe6399fc40, 
> calling_code=1) at I_Continuation.h:146
> #4  EThread::process_event (this=0x2afe3dd07000, e=0x2afe6399fc40, 
> calling_code=1) at UnixEThread.cc:144
> #5  0x006f993b in EThread::execute (this=0x2afe3dd07000)
> at UnixEThread.cc:195
> #6  0x006f832a in spawn_thread_internal (a=0x2afe3badf400)
> at Thread.cc:88
> #7  0x003861c079d1 in start_thread () from /lib64/libpthread.so.0
> #8  0x0038614e8b5d in clone () from /lib64/libc.so.6
> {code}
> Which looks a bit odd-- as frame 0 is missing. From digging into it a bit 
> more (with the help of [~amc]) we found that the VC we where calling was an 
> INKContInternal (meaning an INKVConnInternal):
> {code}
> (gdb) p (INKVConnInternal) *vc_server
> $5 = { = { = { = 
> { = { = {_vptr.force_VFPT_to_top = 
> 0x2afe63a93170}, 
>   handler = (int (Continuation::*)(Continuation *, int, 
> void *)) 0x4cfd90 , mutex = {
> m_ptr = 0x0}, link = {> = {next = 0x0}, 
> prev = 0x0}}, lerrno = 20600}, }, 
> mdata = 0xdeaddead, m_event_func = 0x2afe43c18490
>  <(anonymous namespace)::handleTransformationPluginEvents(TSCont, 
> TSEvent, void*)>, m_event_count = 0, m_closed = -1, m_deletable = 1, 
> m_deleted = 1, 
> m_free_magic = INKCONT_INTERN_MAGIC_ALIVE}, m_read_vio = {_cont = 0x0, 
> nbytes = 0, ndone = 0, op = 0, buffer = {mbuf = 0x0, entry = 0x0}, 
> vc_server = 0x0, mutex = {m_ptr = 0x0}}, m_write_vio = {_cont = 0x0, 
> nbytes = 122, ndone = 0, op = 0, buffer = {mbuf = 0x0, entry = 0x0}, 
> vc_server = 0x2afe63a93530, mutex = {m_ptr = 0x0}}, 
>   m_output_vc = 0x2afe63091a88}
> {code}
> From looking at the debug logs that lead up to the crash, I'm seeing that 
> some events (namely timeout events) are being called after the VConn has been 
> destroy()'d . This lead me to find that INKVConnInternal::handle_event is 
> actually checking if that is the case-- and then re-destroying everything, 
> which makes no sense.
> So although the ideal would be to not call handle_event on a closed VConn, 
> crashing is definitely not acceptable. My solution is to continue to only 
> call the event handler if the VConn hasn't been deleted-- but instead of 
> attempting to re-destroy the connection, we'll leave it be (unless we are in 
> debug mode-- where I'll throw in an assert).
> I did some looking at this on ATS7 and it looks like this is all fixed by the 
> cleanup of the whole free-ing stuff for VConns 
> (https://github.com/apache/trafficserver/pull/752/files).



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

[GitHub] trafficserver issue #1109: TS-4970: Crash in INKVConnInternal when handle_ev...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1109
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/1009/ 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-4970) Crash in INKVConnInternal when handle_event is called after destroy()

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Crash in INKVConnInternal when handle_event is called after destroy()
> -
>
> Key: TS-4970
> URL: https://issues.apache.org/jira/browse/TS-4970
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> We've noticed a few crashes for requests using SPDY (on ATS 5.2.x and 6..x) 
> where the downstream origin is down with a backtrace that looks something 
> like:
> {code}
> (gdb) bt
> #0  0x in ?? ()
> #1  0x004cfe54 in set_continuation (this=0x2afe63a93530, event=1, 
> edata=0x2afe6399fc40) at ../iocore/eventsystem/P_VIO.h:104
> #2  INKVConnInternal::handle_event (this=0x2afe63a93530, event=1, 
> edata=0x2afe6399fc40) at InkAPI.cc:1060
> #3  0x006f8e65 in handleEvent (this=0x2afe3dd07000, e=0x2afe6399fc40, 
> calling_code=1) at I_Continuation.h:146
> #4  EThread::process_event (this=0x2afe3dd07000, e=0x2afe6399fc40, 
> calling_code=1) at UnixEThread.cc:144
> #5  0x006f993b in EThread::execute (this=0x2afe3dd07000)
> at UnixEThread.cc:195
> #6  0x006f832a in spawn_thread_internal (a=0x2afe3badf400)
> at Thread.cc:88
> #7  0x003861c079d1 in start_thread () from /lib64/libpthread.so.0
> #8  0x0038614e8b5d in clone () from /lib64/libc.so.6
> {code}
> Which looks a bit odd-- as frame 0 is missing. From digging into it a bit 
> more (with the help of [~amc]) we found that the VC we where calling was an 
> INKContInternal (meaning an INKVConnInternal):
> {code}
> (gdb) p (INKVConnInternal) *vc_server
> $5 = { = { = { = 
> { = { = {_vptr.force_VFPT_to_top = 
> 0x2afe63a93170}, 
>   handler = (int (Continuation::*)(Continuation *, int, 
> void *)) 0x4cfd90 , mutex = {
> m_ptr = 0x0}, link = {> = {next = 0x0}, 
> prev = 0x0}}, lerrno = 20600}, }, 
> mdata = 0xdeaddead, m_event_func = 0x2afe43c18490
>  <(anonymous namespace)::handleTransformationPluginEvents(TSCont, 
> TSEvent, void*)>, m_event_count = 0, m_closed = -1, m_deletable = 1, 
> m_deleted = 1, 
> m_free_magic = INKCONT_INTERN_MAGIC_ALIVE}, m_read_vio = {_cont = 0x0, 
> nbytes = 0, ndone = 0, op = 0, buffer = {mbuf = 0x0, entry = 0x0}, 
> vc_server = 0x0, mutex = {m_ptr = 0x0}}, m_write_vio = {_cont = 0x0, 
> nbytes = 122, ndone = 0, op = 0, buffer = {mbuf = 0x0, entry = 0x0}, 
> vc_server = 0x2afe63a93530, mutex = {m_ptr = 0x0}}, 
>   m_output_vc = 0x2afe63091a88}
> {code}
> From looking at the debug logs that lead up to the crash, I'm seeing that 
> some events (namely timeout events) are being called after the VConn has been 
> destroy()'d . This lead me to find that INKVConnInternal::handle_event is 
> actually checking if that is the case-- and then re-destroying everything, 
> which makes no sense.
> So although the ideal would be to not call handle_event on a closed VConn, 
> crashing is definitely not acceptable. My solution is to continue to only 
> call the event handler if the VConn hasn't been deleted-- but instead of 
> attempting to re-destroy the connection, we'll leave it be (unless we are in 
> debug mode-- where I'll throw in an assert).
> I did some looking at this on ATS7 and it looks like this is all fixed by the 
> cleanup of the whole free-ing stuff for VConns 
> (https://github.com/apache/trafficserver/pull/752/files).



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

[GitHub] trafficserver issue #1108: TS-4970: Crash in INKVConnInternal when handle_ev...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1108
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/1008/ 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-4970) Crash in INKVConnInternal when handle_event is called after destroy()

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Crash in INKVConnInternal when handle_event is called after destroy()
> -
>
> Key: TS-4970
> URL: https://issues.apache.org/jira/browse/TS-4970
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> We've noticed a few crashes for requests using SPDY (on ATS 5.2.x and 6..x) 
> where the downstream origin is down with a backtrace that looks something 
> like:
> {code}
> (gdb) bt
> #0  0x in ?? ()
> #1  0x004cfe54 in set_continuation (this=0x2afe63a93530, event=1, 
> edata=0x2afe6399fc40) at ../iocore/eventsystem/P_VIO.h:104
> #2  INKVConnInternal::handle_event (this=0x2afe63a93530, event=1, 
> edata=0x2afe6399fc40) at InkAPI.cc:1060
> #3  0x006f8e65 in handleEvent (this=0x2afe3dd07000, e=0x2afe6399fc40, 
> calling_code=1) at I_Continuation.h:146
> #4  EThread::process_event (this=0x2afe3dd07000, e=0x2afe6399fc40, 
> calling_code=1) at UnixEThread.cc:144
> #5  0x006f993b in EThread::execute (this=0x2afe3dd07000)
> at UnixEThread.cc:195
> #6  0x006f832a in spawn_thread_internal (a=0x2afe3badf400)
> at Thread.cc:88
> #7  0x003861c079d1 in start_thread () from /lib64/libpthread.so.0
> #8  0x0038614e8b5d in clone () from /lib64/libc.so.6
> {code}
> Which looks a bit odd-- as frame 0 is missing. From digging into it a bit 
> more (with the help of [~amc]) we found that the VC we where calling was an 
> INKContInternal (meaning an INKVConnInternal):
> {code}
> (gdb) p (INKVConnInternal) *vc_server
> $5 = { = { = { = 
> { = { = {_vptr.force_VFPT_to_top = 
> 0x2afe63a93170}, 
>   handler = (int (Continuation::*)(Continuation *, int, 
> void *)) 0x4cfd90 , mutex = {
> m_ptr = 0x0}, link = {> = {next = 0x0}, 
> prev = 0x0}}, lerrno = 20600}, }, 
> mdata = 0xdeaddead, m_event_func = 0x2afe43c18490
>  <(anonymous namespace)::handleTransformationPluginEvents(TSCont, 
> TSEvent, void*)>, m_event_count = 0, m_closed = -1, m_deletable = 1, 
> m_deleted = 1, 
> m_free_magic = INKCONT_INTERN_MAGIC_ALIVE}, m_read_vio = {_cont = 0x0, 
> nbytes = 0, ndone = 0, op = 0, buffer = {mbuf = 0x0, entry = 0x0}, 
> vc_server = 0x0, mutex = {m_ptr = 0x0}}, m_write_vio = {_cont = 0x0, 
> nbytes = 122, ndone = 0, op = 0, buffer = {mbuf = 0x0, entry = 0x0}, 
> vc_server = 0x2afe63a93530, mutex = {m_ptr = 0x0}}, 
>   m_output_vc = 0x2afe63091a88}
> {code}
> From looking at the debug logs that lead up to the crash, I'm seeing that 
> some events (namely timeout events) are being called after the VConn has been 
> destroy()'d . This lead me to find that INKVConnInternal::handle_event is 
> actually checking if that is the case-- and then re-destroying everything, 
> which makes no sense.
> So although the ideal would be to not call handle_event on a closed VConn, 
> crashing is definitely not acceptable. My solution is to continue to only 
> call the event handler if the VConn hasn't been deleted-- but instead of 
> attempting to re-destroy the connection, we'll leave it be (unless we are in 
> debug mode-- where I'll throw in an assert).
> I did some looking at this on ATS7 and it looks like this is all fixed by the 
> cleanup of the whole free-ing stuff for VConns 
> (https://github.com/apache/trafficserver/pull/752/files).



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

[GitHub] trafficserver issue #1108: TS-4970: Crash in INKVConnInternal when handle_ev...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1108
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/900/ 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-4970) Crash in INKVConnInternal when handle_event is called after destroy()

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Crash in INKVConnInternal when handle_event is called after destroy()
> -
>
> Key: TS-4970
> URL: https://issues.apache.org/jira/browse/TS-4970
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> We've noticed a few crashes for requests using SPDY (on ATS 5.2.x and 6..x) 
> where the downstream origin is down with a backtrace that looks something 
> like:
> {code}
> (gdb) bt
> #0  0x in ?? ()
> #1  0x004cfe54 in set_continuation (this=0x2afe63a93530, event=1, 
> edata=0x2afe6399fc40) at ../iocore/eventsystem/P_VIO.h:104
> #2  INKVConnInternal::handle_event (this=0x2afe63a93530, event=1, 
> edata=0x2afe6399fc40) at InkAPI.cc:1060
> #3  0x006f8e65 in handleEvent (this=0x2afe3dd07000, e=0x2afe6399fc40, 
> calling_code=1) at I_Continuation.h:146
> #4  EThread::process_event (this=0x2afe3dd07000, e=0x2afe6399fc40, 
> calling_code=1) at UnixEThread.cc:144
> #5  0x006f993b in EThread::execute (this=0x2afe3dd07000)
> at UnixEThread.cc:195
> #6  0x006f832a in spawn_thread_internal (a=0x2afe3badf400)
> at Thread.cc:88
> #7  0x003861c079d1 in start_thread () from /lib64/libpthread.so.0
> #8  0x0038614e8b5d in clone () from /lib64/libc.so.6
> {code}
> Which looks a bit odd-- as frame 0 is missing. From digging into it a bit 
> more (with the help of [~amc]) we found that the VC we where calling was an 
> INKContInternal (meaning an INKVConnInternal):
> {code}
> (gdb) p (INKVConnInternal) *vc_server
> $5 = { = { = { = 
> { = { = {_vptr.force_VFPT_to_top = 
> 0x2afe63a93170}, 
>   handler = (int (Continuation::*)(Continuation *, int, 
> void *)) 0x4cfd90 , mutex = {
> m_ptr = 0x0}, link = {> = {next = 0x0}, 
> prev = 0x0}}, lerrno = 20600}, }, 
> mdata = 0xdeaddead, m_event_func = 0x2afe43c18490
>  <(anonymous namespace)::handleTransformationPluginEvents(TSCont, 
> TSEvent, void*)>, m_event_count = 0, m_closed = -1, m_deletable = 1, 
> m_deleted = 1, 
> m_free_magic = INKCONT_INTERN_MAGIC_ALIVE}, m_read_vio = {_cont = 0x0, 
> nbytes = 0, ndone = 0, op = 0, buffer = {mbuf = 0x0, entry = 0x0}, 
> vc_server = 0x0, mutex = {m_ptr = 0x0}}, m_write_vio = {_cont = 0x0, 
> nbytes = 122, ndone = 0, op = 0, buffer = {mbuf = 0x0, entry = 0x0}, 
> vc_server = 0x2afe63a93530, mutex = {m_ptr = 0x0}}, 
>   m_output_vc = 0x2afe63091a88}
> {code}
> From looking at the debug logs that lead up to the crash, I'm seeing that 
> some events (namely timeout events) are being called after the VConn has been 
> destroy()'d . This lead me to find that INKVConnInternal::handle_event is 
> actually checking if that is the case-- and then re-destroying everything, 
> which makes no sense.
> So although the ideal would be to not call handle_event on a closed VConn, 
> crashing is definitely not acceptable. My solution is to continue to only 
> call the event handler if the VConn hasn't been deleted-- but instead of 
> attempting to re-destroy the connection, we'll leave it be (unless we are in 
> debug mode-- where I'll throw in an assert).
> I did some looking at this on ATS7 and it looks like this is all fixed by the 
> cleanup of the whole free-ing stuff for VConns 
> (https://github.com/apache/trafficserver/pull/752/files).



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

[GitHub] trafficserver issue #1109: TS-4970: Crash in INKVConnInternal when handle_ev...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1109
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/1007/ 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] [Closed] (TS-4969) Add log field for number of retries against origin

[Thomas Jackson (JIRA)]

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

Thomas Jackson closed TS-4969.
--
Resolution: Duplicate

> Add log field for number of retries against origin
> --
>
> Key: TS-4969
> URL: https://issues.apache.org/jira/browse/TS-4969
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HTTP
>Reporter: Thomas Jackson
>
> We have configuration options for retries, but I don't see a mechanism to log 
> the number of retries that have happened. This would be immensely helpful in 
> debugging origin issues.



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

[jira] [Work logged] (TS-4148) Add a log field for connection attempts made to origin

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/1106
  
Seems that this does already exists from TS-4148, just couldn't find it ;)


Issue Time Tracking
---

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

> Add a log field for connection attempts made to origin
> --
>
> Key: TS-4148
> URL: https://issues.apache.org/jira/browse/TS-4148
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Logging
>Reporter: Daniel Xu
>Assignee: Leif Hedstrom
> Fix For: 6.2.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> This field could be useful for traffic analysis.



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

[GitHub] trafficserver pull request #1106: Add prr proxy_request_retries log field

[jacksontj]

Github user jacksontj closed the pull request at:

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


---
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 #1106: Add prr proxy_request_retries log field

[jacksontj]

Github user jacksontj commented on the issue:

https://github.com/apache/trafficserver/pull/1106
  
Seems that this does already exists from TS-4148, just couldn't find it ;)


---
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 #1109: TS-4970: Crash in INKVConnInternal when handle_ev...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1109
  
Linux build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/899/ 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-4970) Crash in INKVConnInternal when handle_event is called after destroy()

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Crash in INKVConnInternal when handle_event is called after destroy()
> -
>
> Key: TS-4970
> URL: https://issues.apache.org/jira/browse/TS-4970
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> We've noticed a few crashes for requests using SPDY (on ATS 5.2.x and 6..x) 
> where the downstream origin is down with a backtrace that looks something 
> like:
> {code}
> (gdb) bt
> #0  0x in ?? ()
> #1  0x004cfe54 in set_continuation (this=0x2afe63a93530, event=1, 
> edata=0x2afe6399fc40) at ../iocore/eventsystem/P_VIO.h:104
> #2  INKVConnInternal::handle_event (this=0x2afe63a93530, event=1, 
> edata=0x2afe6399fc40) at InkAPI.cc:1060
> #3  0x006f8e65 in handleEvent (this=0x2afe3dd07000, e=0x2afe6399fc40, 
> calling_code=1) at I_Continuation.h:146
> #4  EThread::process_event (this=0x2afe3dd07000, e=0x2afe6399fc40, 
> calling_code=1) at UnixEThread.cc:144
> #5  0x006f993b in EThread::execute (this=0x2afe3dd07000)
> at UnixEThread.cc:195
> #6  0x006f832a in spawn_thread_internal (a=0x2afe3badf400)
> at Thread.cc:88
> #7  0x003861c079d1 in start_thread () from /lib64/libpthread.so.0
> #8  0x0038614e8b5d in clone () from /lib64/libc.so.6
> {code}
> Which looks a bit odd-- as frame 0 is missing. From digging into it a bit 
> more (with the help of [~amc]) we found that the VC we where calling was an 
> INKContInternal (meaning an INKVConnInternal):
> {code}
> (gdb) p (INKVConnInternal) *vc_server
> $5 = { = { = { = 
> { = { = {_vptr.force_VFPT_to_top = 
> 0x2afe63a93170}, 
>   handler = (int (Continuation::*)(Continuation *, int, 
> void *)) 0x4cfd90 , mutex = {
> m_ptr = 0x0}, link = {> = {next = 0x0}, 
> prev = 0x0}}, lerrno = 20600}, }, 
> mdata = 0xdeaddead, m_event_func = 0x2afe43c18490
>  <(anonymous namespace)::handleTransformationPluginEvents(TSCont, 
> TSEvent, void*)>, m_event_count = 0, m_closed = -1, m_deletable = 1, 
> m_deleted = 1, 
> m_free_magic = INKCONT_INTERN_MAGIC_ALIVE}, m_read_vio = {_cont = 0x0, 
> nbytes = 0, ndone = 0, op = 0, buffer = {mbuf = 0x0, entry = 0x0}, 
> vc_server = 0x0, mutex = {m_ptr = 0x0}}, m_write_vio = {_cont = 0x0, 
> nbytes = 122, ndone = 0, op = 0, buffer = {mbuf = 0x0, entry = 0x0}, 
> vc_server = 0x2afe63a93530, mutex = {m_ptr = 0x0}}, 
>   m_output_vc = 0x2afe63091a88}
> {code}
> From looking at the debug logs that lead up to the crash, I'm seeing that 
> some events (namely timeout events) are being called after the VConn has been 
> destroy()'d . This lead me to find that INKVConnInternal::handle_event is 
> actually checking if that is the case-- and then re-destroying everything, 
> which makes no sense.
> So although the ideal would be to not call handle_event on a closed VConn, 
> crashing is definitely not acceptable. My solution is to continue to only 
> call the event handler if the VConn hasn't been deleted-- but instead of 
> attempting to re-destroy the connection, we'll leave it be (unless we are in 
> debug mode-- where I'll throw in an assert).
> I did some looking at this on ATS7 and it looks like this is all fixed by the 
> cleanup of the whole free-ing stuff for VConns 
> (https://github.com/apache/trafficserver/pull/752/files).



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

[jira] [Work logged] (TS-4970) Crash in INKVConnInternal when handle_event is called after destroy()

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 14/Oct/16 00:25
Start Date: 14/Oct/16 00:25
Worklog Time Spent: 10m 
  Work Description: GitHub user jacksontj opened a pull request:

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

TS-4970: Crash in INKVConnInternal when handle_event is called after 
destroy()



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

$ git pull https://github.com/jacksontj/trafficserver TS-4970_ATS6

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

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


commit d9998523404d2f3dcc5061e7636d4dfe5d81882d
Author: Thomas Jackson 
Date:   2016-10-14T00:23:50Z

TS-4970: Crash in INKVConnInternal when handle_event is called after 
destroy()




Issue Time Tracking
---

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

> Crash in INKVConnInternal when handle_event is called after destroy()
> -
>
> Key: TS-4970
> URL: https://issues.apache.org/jira/browse/TS-4970
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> We've noticed a few crashes for requests using SPDY (on ATS 5.2.x and 6..x) 
> where the downstream origin is down with a backtrace that looks something 
> like:
> {code}
> (gdb) bt
> #0  0x in ?? ()
> #1  0x004cfe54 in set_continuation (this=0x2afe63a93530, event=1, 
> edata=0x2afe6399fc40) at ../iocore/eventsystem/P_VIO.h:104
> #2  INKVConnInternal::handle_event (this=0x2afe63a93530, event=1, 
> edata=0x2afe6399fc40) at InkAPI.cc:1060
> #3  0x006f8e65 in handleEvent (this=0x2afe3dd07000, e=0x2afe6399fc40, 
> calling_code=1) at I_Continuation.h:146
> #4  EThread::process_event (this=0x2afe3dd07000, e=0x2afe6399fc40, 
> calling_code=1) at UnixEThread.cc:144
> #5  0x006f993b in EThread::execute (this=0x2afe3dd07000)
> at UnixEThread.cc:195
> #6  0x006f832a in spawn_thread_internal (a=0x2afe3badf400)
> at Thread.cc:88
> #7  0x003861c079d1 in start_thread () from /lib64/libpthread.so.0
> #8  0x0038614e8b5d in clone () from /lib64/libc.so.6
> {code}
> Which looks a bit odd-- as frame 0 is missing. From digging into it a bit 
> more (with the help of [~amc]) we found that the VC we where calling was an 
> INKContInternal (meaning an INKVConnInternal):
> {code}
> (gdb) p (INKVConnInternal) *vc_server
> $5 = { = { = { = 
> { = { = {_vptr.force_VFPT_to_top = 
> 0x2afe63a93170}, 
>   handler = (int (Continuation::*)(Continuation *, int, 
> void *)) 0x4cfd90 , mutex = {
> m_ptr = 0x0}, link = {> = {next = 0x0}, 
> prev = 0x0}}, lerrno = 20600}, }, 
> mdata = 0xdeaddead, m_event_func = 0x2afe43c18490
>  <(anonymous namespace)::handleTransformationPluginEvents(TSCont, 
> TSEvent, void*)>, m_event_count = 0, m_closed = -1, m_deletable = 1, 
> m_deleted = 1, 
> m_free_magic = INKCONT_INTERN_MAGIC_ALIVE}, m_read_vio = {_cont = 0x0, 
> nbytes = 0, ndone = 0, op = 0, buffer = {mbuf = 0x0, entry = 0x0}, 
> vc_server = 0x0, mutex = {m_ptr = 0x0}}, m_write_vio = {_cont = 0x0, 
> nbytes = 122, ndone = 0, op = 0, buffer = {mbuf = 0x0, entry = 0x0}, 
> vc_server = 0x2afe63a93530, mutex = {m_ptr = 0x0}}, 
>   m_output_vc = 0x2afe63091a88}
> {code}
> From looking at the debug logs that lead up to the crash, I'm seeing that 
> some events (namely timeout events) are being called after the VConn has been 
> destroy()'d . This lead me to find that INKVConnInternal::handle_event is 
> actually checking if that is the case-- and then re-destroying everything, 
> which makes no sense.
> So although the ideal would be to not call handle_event on a closed VConn, 
> crashing is definitely not acceptable. My solution is to continue to only 
> call the event handler if the VConn hasn't been deleted-- but instead of 
> attempting to re-destroy the connection, we'll leave it be (unless we are in 
> debug mode-- where I'll throw in an assert).
> I did some looking at this on ATS7 and it looks like this is all fixed by the 
> cleanup of the whole free-ing stuff for VConns 
> (https://github.com/apache/trafficserver/pull/752/files).



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

[GitHub] trafficserver pull request #1109: TS-4970: Crash in INKVConnInternal when ha...

[jacksontj]

GitHub user jacksontj opened a pull request:

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

TS-4970: Crash in INKVConnInternal when handle_event is called after 
destroy()



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

$ git pull https://github.com/jacksontj/trafficserver TS-4970_ATS6

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

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


commit d9998523404d2f3dcc5061e7636d4dfe5d81882d
Author: Thomas Jackson 
Date:   2016-10-14T00:23:50Z

TS-4970: Crash in INKVConnInternal when handle_event is called after 
destroy()




---
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 #1108: TS-4970: Crash in INKVConnInternal when ha...

[jacksontj]

GitHub user jacksontj opened a pull request:

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

TS-4970: Crash in INKVConnInternal when handle_event is called after 
destroy()



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

$ git pull https://github.com/jacksontj/trafficserver TS-4970_ATS5

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

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


commit 1210ad96278ccb29a0614b3234a2ed3743c3f6f6
Author: Thomas Jackson 
Date:   2016-10-14T00:22:42Z

TS-4970: Crash in INKVConnInternal when handle_event is called after 
destroy()




---
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-4970) Crash in INKVConnInternal when handle_event is called after destroy()

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 14/Oct/16 00:24
Start Date: 14/Oct/16 00:24
Worklog Time Spent: 10m 
  Work Description: GitHub user jacksontj opened a pull request:

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

TS-4970: Crash in INKVConnInternal when handle_event is called after 
destroy()



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

$ git pull https://github.com/jacksontj/trafficserver TS-4970_ATS5

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

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


commit 1210ad96278ccb29a0614b3234a2ed3743c3f6f6
Author: Thomas Jackson 
Date:   2016-10-14T00:22:42Z

TS-4970: Crash in INKVConnInternal when handle_event is called after 
destroy()




Issue Time Tracking
---

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

> Crash in INKVConnInternal when handle_event is called after destroy()
> -
>
> Key: TS-4970
> URL: https://issues.apache.org/jira/browse/TS-4970
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> We've noticed a few crashes for requests using SPDY (on ATS 5.2.x and 6..x) 
> where the downstream origin is down with a backtrace that looks something 
> like:
> {code}
> (gdb) bt
> #0  0x in ?? ()
> #1  0x004cfe54 in set_continuation (this=0x2afe63a93530, event=1, 
> edata=0x2afe6399fc40) at ../iocore/eventsystem/P_VIO.h:104
> #2  INKVConnInternal::handle_event (this=0x2afe63a93530, event=1, 
> edata=0x2afe6399fc40) at InkAPI.cc:1060
> #3  0x006f8e65 in handleEvent (this=0x2afe3dd07000, e=0x2afe6399fc40, 
> calling_code=1) at I_Continuation.h:146
> #4  EThread::process_event (this=0x2afe3dd07000, e=0x2afe6399fc40, 
> calling_code=1) at UnixEThread.cc:144
> #5  0x006f993b in EThread::execute (this=0x2afe3dd07000)
> at UnixEThread.cc:195
> #6  0x006f832a in spawn_thread_internal (a=0x2afe3badf400)
> at Thread.cc:88
> #7  0x003861c079d1 in start_thread () from /lib64/libpthread.so.0
> #8  0x0038614e8b5d in clone () from /lib64/libc.so.6
> {code}
> Which looks a bit odd-- as frame 0 is missing. From digging into it a bit 
> more (with the help of [~amc]) we found that the VC we where calling was an 
> INKContInternal (meaning an INKVConnInternal):
> {code}
> (gdb) p (INKVConnInternal) *vc_server
> $5 = { = { = { = 
> { = { = {_vptr.force_VFPT_to_top = 
> 0x2afe63a93170}, 
>   handler = (int (Continuation::*)(Continuation *, int, 
> void *)) 0x4cfd90 , mutex = {
> m_ptr = 0x0}, link = {> = {next = 0x0}, 
> prev = 0x0}}, lerrno = 20600}, }, 
> mdata = 0xdeaddead, m_event_func = 0x2afe43c18490
>  <(anonymous namespace)::handleTransformationPluginEvents(TSCont, 
> TSEvent, void*)>, m_event_count = 0, m_closed = -1, m_deletable = 1, 
> m_deleted = 1, 
> m_free_magic = INKCONT_INTERN_MAGIC_ALIVE}, m_read_vio = {_cont = 0x0, 
> nbytes = 0, ndone = 0, op = 0, buffer = {mbuf = 0x0, entry = 0x0}, 
> vc_server = 0x0, mutex = {m_ptr = 0x0}}, m_write_vio = {_cont = 0x0, 
> nbytes = 122, ndone = 0, op = 0, buffer = {mbuf = 0x0, entry = 0x0}, 
> vc_server = 0x2afe63a93530, mutex = {m_ptr = 0x0}}, 
>   m_output_vc = 0x2afe63091a88}
> {code}
> From looking at the debug logs that lead up to the crash, I'm seeing that 
> some events (namely timeout events) are being called after the VConn has been 
> destroy()'d . This lead me to find that INKVConnInternal::handle_event is 
> actually checking if that is the case-- and then re-destroying everything, 
> which makes no sense.
> So although the ideal would be to not call handle_event on a closed VConn, 
> crashing is definitely not acceptable. My solution is to continue to only 
> call the event handler if the VConn hasn't been deleted-- but instead of 
> attempting to re-destroy the connection, we'll leave it be (unless we are in 
> debug mode-- where I'll throw in an assert).
> I did some looking at this on ATS7 and it looks like this is all fixed by the 
> cleanup of the whole free-ing stuff for VConns 
> (https://github.com/apache/trafficserver/pull/752/files).



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

[jira] [Updated] (TS-4970) Crash in INKVConnInternal when handle_event is called after destroy()

[Thomas Jackson (JIRA)]

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

Thomas Jackson updated TS-4970:
---
Summary: Crash in INKVConnInternal when handle_event is called after 
destroy()  (was: Crash in INKVConnInternal if handle_event is called after 
destroy())

> Crash in INKVConnInternal when handle_event is called after destroy()
> -
>
> Key: TS-4970
> URL: https://issues.apache.org/jira/browse/TS-4970
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
>
> We've noticed a few crashes for requests using SPDY (on ATS 5.2.x and 6..x) 
> where the downstream origin is down with a backtrace that looks something 
> like:
> {code}
> (gdb) bt
> #0  0x in ?? ()
> #1  0x004cfe54 in set_continuation (this=0x2afe63a93530, event=1, 
> edata=0x2afe6399fc40) at ../iocore/eventsystem/P_VIO.h:104
> #2  INKVConnInternal::handle_event (this=0x2afe63a93530, event=1, 
> edata=0x2afe6399fc40) at InkAPI.cc:1060
> #3  0x006f8e65 in handleEvent (this=0x2afe3dd07000, e=0x2afe6399fc40, 
> calling_code=1) at I_Continuation.h:146
> #4  EThread::process_event (this=0x2afe3dd07000, e=0x2afe6399fc40, 
> calling_code=1) at UnixEThread.cc:144
> #5  0x006f993b in EThread::execute (this=0x2afe3dd07000)
> at UnixEThread.cc:195
> #6  0x006f832a in spawn_thread_internal (a=0x2afe3badf400)
> at Thread.cc:88
> #7  0x003861c079d1 in start_thread () from /lib64/libpthread.so.0
> #8  0x0038614e8b5d in clone () from /lib64/libc.so.6
> {code}
> Which looks a bit odd-- as frame 0 is missing. From digging into it a bit 
> more (with the help of [~amc]) we found that the VC we where calling was an 
> INKContInternal (meaning an INKVConnInternal):
> {code}
> (gdb) p (INKVConnInternal) *vc_server
> $5 = { = { = { = 
> { = { = {_vptr.force_VFPT_to_top = 
> 0x2afe63a93170}, 
>   handler = (int (Continuation::*)(Continuation *, int, 
> void *)) 0x4cfd90 , mutex = {
> m_ptr = 0x0}, link = {> = {next = 0x0}, 
> prev = 0x0}}, lerrno = 20600}, }, 
> mdata = 0xdeaddead, m_event_func = 0x2afe43c18490
>  <(anonymous namespace)::handleTransformationPluginEvents(TSCont, 
> TSEvent, void*)>, m_event_count = 0, m_closed = -1, m_deletable = 1, 
> m_deleted = 1, 
> m_free_magic = INKCONT_INTERN_MAGIC_ALIVE}, m_read_vio = {_cont = 0x0, 
> nbytes = 0, ndone = 0, op = 0, buffer = {mbuf = 0x0, entry = 0x0}, 
> vc_server = 0x0, mutex = {m_ptr = 0x0}}, m_write_vio = {_cont = 0x0, 
> nbytes = 122, ndone = 0, op = 0, buffer = {mbuf = 0x0, entry = 0x0}, 
> vc_server = 0x2afe63a93530, mutex = {m_ptr = 0x0}}, 
>   m_output_vc = 0x2afe63091a88}
> {code}
> From looking at the debug logs that lead up to the crash, I'm seeing that 
> some events (namely timeout events) are being called after the VConn has been 
> destroy()'d . This lead me to find that INKVConnInternal::handle_event is 
> actually checking if that is the case-- and then re-destroying everything, 
> which makes no sense.
> So although the ideal would be to not call handle_event on a closed VConn, 
> crashing is definitely not acceptable. My solution is to continue to only 
> call the event handler if the VConn hasn't been deleted-- but instead of 
> attempting to re-destroy the connection, we'll leave it be (unless we are in 
> debug mode-- where I'll throw in an assert).
> I did some looking at this on ATS7 and it looks like this is all fixed by the 
> cleanup of the whole free-ing stuff for VConns 
> (https://github.com/apache/trafficserver/pull/752/files).



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

[jira] [Assigned] (TS-4970) Crash in INKVConnInternal if handle_event is called after destroy()

[Thomas Jackson (JIRA)]

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

Thomas Jackson reassigned TS-4970:
--

Assignee: Thomas Jackson

> Crash in INKVConnInternal if handle_event is called after destroy()
> ---
>
> Key: TS-4970
> URL: https://issues.apache.org/jira/browse/TS-4970
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
>
> We've noticed a few crashes for requests using SPDY (on ATS 5.2.x and 6..x) 
> where the downstream origin is down with a backtrace that looks something 
> like:
> {code}
> (gdb) bt
> #0  0x in ?? ()
> #1  0x004cfe54 in set_continuation (this=0x2afe63a93530, event=1, 
> edata=0x2afe6399fc40) at ../iocore/eventsystem/P_VIO.h:104
> #2  INKVConnInternal::handle_event (this=0x2afe63a93530, event=1, 
> edata=0x2afe6399fc40) at InkAPI.cc:1060
> #3  0x006f8e65 in handleEvent (this=0x2afe3dd07000, e=0x2afe6399fc40, 
> calling_code=1) at I_Continuation.h:146
> #4  EThread::process_event (this=0x2afe3dd07000, e=0x2afe6399fc40, 
> calling_code=1) at UnixEThread.cc:144
> #5  0x006f993b in EThread::execute (this=0x2afe3dd07000)
> at UnixEThread.cc:195
> #6  0x006f832a in spawn_thread_internal (a=0x2afe3badf400)
> at Thread.cc:88
> #7  0x003861c079d1 in start_thread () from /lib64/libpthread.so.0
> #8  0x0038614e8b5d in clone () from /lib64/libc.so.6
> {code}
> Which looks a bit odd-- as frame 0 is missing. From digging into it a bit 
> more (with the help of [~amc]) we found that the VC we where calling was an 
> INKContInternal (meaning an INKVConnInternal):
> {code}
> (gdb) p (INKVConnInternal) *vc_server
> $5 = { = { = { = 
> { = { = {_vptr.force_VFPT_to_top = 
> 0x2afe63a93170}, 
>   handler = (int (Continuation::*)(Continuation *, int, 
> void *)) 0x4cfd90 , mutex = {
> m_ptr = 0x0}, link = {> = {next = 0x0}, 
> prev = 0x0}}, lerrno = 20600}, }, 
> mdata = 0xdeaddead, m_event_func = 0x2afe43c18490
>  <(anonymous namespace)::handleTransformationPluginEvents(TSCont, 
> TSEvent, void*)>, m_event_count = 0, m_closed = -1, m_deletable = 1, 
> m_deleted = 1, 
> m_free_magic = INKCONT_INTERN_MAGIC_ALIVE}, m_read_vio = {_cont = 0x0, 
> nbytes = 0, ndone = 0, op = 0, buffer = {mbuf = 0x0, entry = 0x0}, 
> vc_server = 0x0, mutex = {m_ptr = 0x0}}, m_write_vio = {_cont = 0x0, 
> nbytes = 122, ndone = 0, op = 0, buffer = {mbuf = 0x0, entry = 0x0}, 
> vc_server = 0x2afe63a93530, mutex = {m_ptr = 0x0}}, 
>   m_output_vc = 0x2afe63091a88}
> {code}
> From looking at the debug logs that lead up to the crash, I'm seeing that 
> some events (namely timeout events) are being called after the VConn has been 
> destroy()'d . This lead me to find that INKVConnInternal::handle_event is 
> actually checking if that is the case-- and then re-destroying everything, 
> which makes no sense.
> So although the ideal would be to not call handle_event on a closed VConn, 
> crashing is definitely not acceptable. My solution is to continue to only 
> call the event handler if the VConn hasn't been deleted-- but instead of 
> attempting to re-destroy the connection, we'll leave it be (unless we are in 
> debug mode-- where I'll throw in an assert).
> I did some looking at this on ATS7 and it looks like this is all fixed by the 
> cleanup of the whole free-ing stuff for VConns 
> (https://github.com/apache/trafficserver/pull/752/files).



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

[jira] [Created] (TS-4970) Crash in INKVConnInternal if handle_event is called after destroy()

[Thomas Jackson (JIRA)]

Thomas Jackson created TS-4970:
--

 Summary: Crash in INKVConnInternal if handle_event is called after 
destroy()
 Key: TS-4970
 URL: https://issues.apache.org/jira/browse/TS-4970
 Project: Traffic Server
  Issue Type: Bug
  Components: HTTP
Reporter: Thomas Jackson


We've noticed a few crashes for requests using SPDY (on ATS 5.2.x and 6..x) 
where the downstream origin is down with a backtrace that looks something like:

{code}
(gdb) bt
#0  0x in ?? ()
#1  0x004cfe54 in set_continuation (this=0x2afe63a93530, event=1, 
edata=0x2afe6399fc40) at ../iocore/eventsystem/P_VIO.h:104
#2  INKVConnInternal::handle_event (this=0x2afe63a93530, event=1, 
edata=0x2afe6399fc40) at InkAPI.cc:1060
#3  0x006f8e65 in handleEvent (this=0x2afe3dd07000, e=0x2afe6399fc40, 
calling_code=1) at I_Continuation.h:146
#4  EThread::process_event (this=0x2afe3dd07000, e=0x2afe6399fc40, 
calling_code=1) at UnixEThread.cc:144
#5  0x006f993b in EThread::execute (this=0x2afe3dd07000)
at UnixEThread.cc:195
#6  0x006f832a in spawn_thread_internal (a=0x2afe3badf400)
at Thread.cc:88
#7  0x003861c079d1 in start_thread () from /lib64/libpthread.so.0
#8  0x0038614e8b5d in clone () from /lib64/libc.so.6
{code}

Which looks a bit odd-- as frame 0 is missing. From digging into it a bit more 
(with the help of [~amc]) we found that the VC we where calling was an 
INKContInternal (meaning an INKVConnInternal):

{code}
(gdb) p (INKVConnInternal) *vc_server
$5 = { = { = { = 
{ = { = {_vptr.force_VFPT_to_top = 
0x2afe63a93170}, 
  handler = (int (Continuation::*)(Continuation *, int, 
void *)) 0x4cfd90 , mutex = {
m_ptr = 0x0}, link = {> = {next = 0x0}, 
prev = 0x0}}, lerrno = 20600}, }, 
mdata = 0xdeaddead, m_event_func = 0x2afe43c18490
 <(anonymous namespace)::handleTransformationPluginEvents(TSCont, TSEvent, 
void*)>, m_event_count = 0, m_closed = -1, m_deletable = 1, m_deleted = 1, 
m_free_magic = INKCONT_INTERN_MAGIC_ALIVE}, m_read_vio = {_cont = 0x0, 
nbytes = 0, ndone = 0, op = 0, buffer = {mbuf = 0x0, entry = 0x0}, 
vc_server = 0x0, mutex = {m_ptr = 0x0}}, m_write_vio = {_cont = 0x0, 
nbytes = 122, ndone = 0, op = 0, buffer = {mbuf = 0x0, entry = 0x0}, 
vc_server = 0x2afe63a93530, mutex = {m_ptr = 0x0}}, 
  m_output_vc = 0x2afe63091a88}
{code}

>From looking at the debug logs that lead up to the crash, I'm seeing that some 
>events (namely timeout events) are being called after the VConn has been 
>destroy()'d . This lead me to find that INKVConnInternal::handle_event is 
>actually checking if that is the case-- and then re-destroying everything, 
>which makes no sense.

So although the ideal would be to not call handle_event on a closed VConn, 
crashing is definitely not acceptable. My solution is to continue to only call 
the event handler if the VConn hasn't been deleted-- but instead of attempting 
to re-destroy the connection, we'll leave it be (unless we are in debug mode-- 
where I'll throw in an assert).

I did some looking at this on ATS7 and it looks like this is all fixed by the 
cleanup of the whole free-ing stuff for VConns 
(https://github.com/apache/trafficserver/pull/752/files).



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

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

[SolidWallOfCode]

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

https://github.com/apache/trafficserver/pull/769#discussion_r83321096
  
--- Diff: proxy/IPAllow.cc ---
@@ -287,12 +298,16 @@ IpAllow::BuildTable()
 line = tokLine(NULL, &tok_state);
   }
 
-  if (_map.getCount() == 0) {
+  if (_src_map.getCount() == 0 && _dest_map.getCount() == 0) { // TODO: 
check
 Warning("%s No entries in %s. All IP Addresses will be blocked", 
module_name, config_file_path);
   } else {
 // convert the coloring from indices to pointers.
-for (IpMap::iterator spot(_map.begin()), limit(_map.end()); spot != 
limit; ++spot) {
-  spot->setData(&_acls[reinterpret_cast(spot->data())]);
+for (IpMap::iterator spot(_src_map.begin()), limit(_src_map.end()); 
spot != limit; ++spot) {
--- End diff --

Well, how about container style for loops?
```
for ( auto& item : _src_map )
  item.setData(&_acls[reinterpret_cast(item.data())]);
```


---
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 #1106: Add prr proxy_request_retries log field

[jacksontj]

Github user jacksontj commented on the issue:

https://github.com/apache/trafficserver/pull/1106
  
I'm not sure about the name (currently `prr`), anyone have opinions on the 
name?


---
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-4967) header_frequency plugin should allow logging data to a specific file

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> header_frequency plugin should allow logging data to a specific file
> 
>
> Key: TS-4967
> URL: https://issues.apache.org/jira/browse/TS-4967
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: Alan M. Carroll
>Assignee: Alan M. Carroll
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> Extend the command option to the plugin to specify an output file.



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

[GitHub] trafficserver issue #1107: TS-4967: Enable header_freq logging to a specific...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1107
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/898/ 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-4967) header_frequency plugin should allow logging data to a specific file

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> header_frequency plugin should allow logging data to a specific file
> 
>
> Key: TS-4967
> URL: https://issues.apache.org/jira/browse/TS-4967
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: Alan M. Carroll
>Assignee: Alan M. Carroll
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> Extend the command option to the plugin to specify an output file.



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

[GitHub] trafficserver issue #1107: TS-4967: Enable header_freq logging to a specific...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1107
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/1006/ 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 #1106: Add prr proxy_request_retries log field

[jpeach]

Github user jpeach commented on the issue:

https://github.com/apache/trafficserver/pull/1106
  
Also, we should have a Jira for this :)


---
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-4967) header_frequency plugin should allow logging data to a specific file

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/1107
  
Well, beyond that `TSTextLogObjectCreate` doesn't seem to be documented, it 
seems more work than is useful for a single write. Note that there's no 
guarantee multiple invocations will all use the same file.


Issue Time Tracking
---

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

> header_frequency plugin should allow logging data to a specific file
> 
>
> Key: TS-4967
> URL: https://issues.apache.org/jira/browse/TS-4967
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: Alan M. Carroll
>Assignee: Alan M. Carroll
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> Extend the command option to the plugin to specify an output file.



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

[GitHub] trafficserver issue #1107: TS-4967: Enable header_freq logging to a specific...

[SolidWallOfCode]

Github user SolidWallOfCode commented on the issue:

https://github.com/apache/trafficserver/pull/1107
  
Well, beyond that `TSTextLogObjectCreate` doesn't seem to be documented, it 
seems more work than is useful for a single write. Note that there's no 
guarantee multiple invocations will all use the same file.


---
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-4967) header_frequency plugin should allow logging data to a specific file

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/1107#discussion_r83306042
  
--- Diff: plugins/experimental/header_freq/header_freq.cc ---
@@ -46,18 +46,15 @@ static std::map client_freq;
 static std::map origin_freq;
 
 // for traffic_ctl, name is a convenient identifier
-static const char *ctl_tag = plugin_name;
-static const char *ctl_log = "log"; // log all data
+static const char *ctl_tag  = plugin_name;
+static const char CONTROL_MSG_LOG[] = "log"; // log all data
+static const size_t CONTROL_MSG_LOG_LEN = sizeof(CONTROL_MSG_LOG) - 1;
--- End diff --

Sure, why not?


Issue Time Tracking
---

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

> header_frequency plugin should allow logging data to a specific file
> 
>
> Key: TS-4967
> URL: https://issues.apache.org/jira/browse/TS-4967
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: Alan M. Carroll
>Assignee: Alan M. Carroll
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> Extend the command option to the plugin to specify an output file.



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

[GitHub] trafficserver pull request #1107: TS-4967: Enable header_freq logging to a s...

[SolidWallOfCode]

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

https://github.com/apache/trafficserver/pull/1107#discussion_r83306042
  
--- Diff: plugins/experimental/header_freq/header_freq.cc ---
@@ -46,18 +46,15 @@ static std::map client_freq;
 static std::map origin_freq;
 
 // for traffic_ctl, name is a convenient identifier
-static const char *ctl_tag = plugin_name;
-static const char *ctl_log = "log"; // log all data
+static const char *ctl_tag  = plugin_name;
+static const char CONTROL_MSG_LOG[] = "log"; // log all data
+static const size_t CONTROL_MSG_LOG_LEN = sizeof(CONTROL_MSG_LOG) - 1;
--- End diff --

Sure, why not?


---
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-4967) header_frequency plugin should allow logging data to a specific file

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/1107#discussion_r83305165
  
--- Diff: plugins/experimental/header_freq/header_freq.cc ---
@@ -46,18 +46,15 @@ static std::map client_freq;
 static std::map origin_freq;
 
 // for traffic_ctl, name is a convenient identifier
-static const char *ctl_tag = plugin_name;
-static const char *ctl_log = "log"; // log all data
+static const char *ctl_tag  = plugin_name;
+static const char CONTROL_MSG_LOG[] = "log"; // log all data
+static const size_t CONTROL_MSG_LOG_LEN = sizeof(CONTROL_MSG_LOG) - 1;
--- End diff --

Might as well move everything into the anonymous namespace?


Issue Time Tracking
---

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

> header_frequency plugin should allow logging data to a specific file
> 
>
> Key: TS-4967
> URL: https://issues.apache.org/jira/browse/TS-4967
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: Alan M. Carroll
>Assignee: Alan M. Carroll
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Extend the command option to the plugin to specify an output file.



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

[GitHub] trafficserver pull request #1107: TS-4967: Enable header_freq logging to a s...

[jpeach]

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

https://github.com/apache/trafficserver/pull/1107#discussion_r83305165
  
--- Diff: plugins/experimental/header_freq/header_freq.cc ---
@@ -46,18 +46,15 @@ static std::map client_freq;
 static std::map origin_freq;
 
 // for traffic_ctl, name is a convenient identifier
-static const char *ctl_tag = plugin_name;
-static const char *ctl_log = "log"; // log all data
+static const char *ctl_tag  = plugin_name;
+static const char CONTROL_MSG_LOG[] = "log"; // log all data
+static const size_t CONTROL_MSG_LOG_LEN = sizeof(CONTROL_MSG_LOG) - 1;
--- End diff --

Might as well move everything into the anonymous namespace?


---
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-4967) header_frequency plugin should allow logging data to a specific file

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> header_frequency plugin should allow logging data to a specific file
> 
>
> Key: TS-4967
> URL: https://issues.apache.org/jira/browse/TS-4967
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: Alan M. Carroll
>Assignee: Alan M. Carroll
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Extend the command option to the plugin to specify an output file.



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

[jira] [Commented] (TS-4930) Unfold request headers that are using obs continuations

[Alan M. Carroll (JIRA)]

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

Alan M. Carroll commented on TS-4930:
-

After massive amounts of discussion I think the path forward is to provide an 
API mechanism to unfold values in the outgoing request, rather than handle it 
during the parse. While doing it during the parse is clearly more efficient, 
it's unclear that the performance difference will be noticeable in practice. 
The disadvantages are

* Breaking {{const}} on the parser API.
* Breaking the read only guarantee of {{IOBuffer}}.
* Providing no flexibility.

If this is done on the outbound request, only those values that require 
unfolding would be changed and the copies put in the header heap which should 
affordable. If at all possible the parser should mark fields that have folded 
lines to improve efficiency later, to avoid doing any checks on fields that are 
not folded (which should be the vast majority of the time).

> Unfold request headers that are using obs continuations
> ---
>
> Key: TS-4930
> URL: https://issues.apache.org/jira/browse/TS-4930
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HTTP
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.1.0
>
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> In RFC 7230, we have
> {code}
>Header fields that span multiple lines ("line folding") are
>deprecated.  (Section 3.2.4)
> {code}
> Our recommendation is to unfold these into a single line for now, possibly 
> later add an option to make such request generate 40x errors.



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

[GitHub] trafficserver issue #1107: TS-4967: Enable header_freq logging to a specific...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1107
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/897/ 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-4967) header_frequency plugin should allow logging data to a specific file

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> header_frequency plugin should allow logging data to a specific file
> 
>
> Key: TS-4967
> URL: https://issues.apache.org/jira/browse/TS-4967
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: Alan M. Carroll
>Assignee: Alan M. Carroll
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Extend the command option to the plugin to specify an output file.



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

[GitHub] trafficserver issue #1107: TS-4967: Enable header_freq logging to a specific...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1107
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/1005/ 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] [Assigned] (TS-4967) header_frequency plugin should allow logging data to a specific file

[Alan M. Carroll (JIRA)]

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

Alan M. Carroll reassigned TS-4967:
---

Assignee: Alan M. Carroll

> header_frequency plugin should allow logging data to a specific file
> 
>
> Key: TS-4967
> URL: https://issues.apache.org/jira/browse/TS-4967
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: Alan M. Carroll
>Assignee: Alan M. Carroll
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Extend the command option to the plugin to specify an output file.



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

[jira] [Work logged] (TS-4967) header_frequency plugin should allow logging data to a specific file

[ASF GitHub Bot (JIRA)]

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

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

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

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

TS-4967: Enable header_freq logging to a specific file.



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

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

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

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


commit 91f3a857c8b1c7887e8506d286277783773e6ecd
Author: Alan M. Carroll 
Date:   2016-10-13T15:44:12Z

TS-4967: Enable header_freq logging to a specific file.




Issue Time Tracking
---

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

> header_frequency plugin should allow logging data to a specific file
> 
>
> Key: TS-4967
> URL: https://issues.apache.org/jira/browse/TS-4967
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: Alan M. Carroll
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Extend the command option to the plugin to specify an output file.



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

[GitHub] trafficserver pull request #1107: TS-4967: Enable header_freq logging to a s...

[SolidWallOfCode]

GitHub user SolidWallOfCode opened a pull request:

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

TS-4967: Enable header_freq logging to a specific file.



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

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

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

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


commit 91f3a857c8b1c7887e8506d286277783773e6ecd
Author: Alan M. Carroll 
Date:   2016-10-13T15:44:12Z

TS-4967: Enable header_freq logging to a specific file.




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

[jira] [Resolved] (TS-4966) Debug asserts fail when trying to schedule a continuation from a lifecycle plugin message hook

[Alan M. Carroll (JIRA)]

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

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

> Debug asserts fail when trying to schedule a continuation from a lifecycle 
> plugin message hook
> --
>
> Key: TS-4966
> URL: https://issues.apache.org/jira/browse/TS-4966
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: Alan M. Carroll
>Assignee: Alan M. Carroll
> Fix For: 7.1.0
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> The plugin message callback for the lifecycle hook is called from a special 
> core thread which is not an {{EThread}}. Because of this debug assertions 
> fail in {{TSContSchedule}} (and other API calls) because mutex operations 
> fail due to the lack of {{EThread}}.



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

[GitHub] trafficserver issue #1100: TS-4916: Fix for an H2-infinite-loop deadlock

[shinrich]

Github user shinrich commented on the issue:

https://github.com/apache/trafficserver/pull/1100
  
Not clear we want to move this to 7.0.  The main changes have already been 
applied (check to see if stream is still in list before deleting and 
appropriately signal that the stream should be removed from the 
Session/ConnState stream list).  May want to look at the backport of TS-4507 to 
6.2.


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

[jenkins]

See 

Changes:

[shinrich] TS-4915: Crash from hostdb in PriorityQueueLess

--
[...truncated 5404 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... [ 70%] 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... [ 77%] 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/TSStatPeristence.en
reading sources... [ 79%] developer-guide/api/types/TSStatSync.en
reading sources... [ 79%] developer-guide/api/types/TSThreadPool.en
reading sources... [ 79%] developer-guide/api/types/TSUuid.en
reading sources... [ 80%] 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... [ 81%] 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... [ 82%] 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... [ 83%] 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... [ 84%] developer-guide/debugging/using-tsassert.en
reading sourc

[jira] [Commented] (TS-4966) Debug asserts fail when trying to schedule a continuation from a lifecycle plugin message hook

[Alan M. Carroll (JIRA)]

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

Alan M. Carroll commented on TS-4966:
-

Commit 837d838b096f9ec6d1a663dac136f294c73cda66.

> Debug asserts fail when trying to schedule a continuation from a lifecycle 
> plugin message hook
> --
>
> Key: TS-4966
> URL: https://issues.apache.org/jira/browse/TS-4966
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: Alan M. Carroll
>Assignee: Alan M. Carroll
> Fix For: 7.1.0
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> The plugin message callback for the lifecycle hook is called from a special 
> core thread which is not an {{EThread}}. Because of this debug assertions 
> fail in {{TSContSchedule}} (and other API calls) because mutex operations 
> fail due to the lack of {{EThread}}.



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

[jira] [Work logged] (TS-4916) Http2ConnectionState::restart_streams infinite loop causes deadlock

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/1100
  
Not clear we want to move this to 7.0.  The main changes have already been 
applied (check to see if stream is still in list before deleting and 
appropriately signal that the stream should be removed from the 
Session/ConnState stream list).  May want to look at the backport of TS-4507 to 
6.2.


Issue Time Tracking
---

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

> Http2ConnectionState::restart_streams infinite loop causes deadlock 
> 
>
> Key: TS-4916
> URL: https://issues.apache.org/jira/browse/TS-4916
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, HTTP/2
>Reporter: Gancho Tenev
>Assignee: Gancho Tenev
>Priority: Blocker
> Fix For: 7.1.0
>
>  Time Spent: 4h 10m
>  Remaining Estimate: 0h
>
> Http2ConnectionState::restart_streams falls into an infinite loop while 
> holding a lock, which leads to cache updates to start failing.
> The infinite loop is caused by traversing a list whose last element “next” 
> points to the element itself and the traversal never finishes.
> {code}
> Thread 51 (Thread 0x2aaab3d04700 (LWP 34270)):
> #0  0x2acf3fee in Http2ConnectionState::restart_streams 
> (this=0x2ae6ba5284c8) at Http2ConnectionState.cc:913
> #1  rcv_window_update_frame (cstate=..., frame=...) at 
> Http2ConnectionState.cc:627
> #2  0x2acf9738 in Http2ConnectionState::main_event_handler 
> (this=0x2ae6ba5284c8, event=, edata=) at 
> Http2ConnectionState.cc:823
> #3  0x2acef1c3 in Continuation::handleEvent (data=0x2aaab3d039a0, 
> event=2253, this=0x2ae6ba5284c8) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #4  send_connection_event (cont=cont@entry=0x2ae6ba5284c8, 
> event=event@entry=2253, edata=edata@entry=0x2aaab3d039a0) at 
> Http2ClientSession.cc:58
> #5  0x2acef462 in Http2ClientSession::state_complete_frame_read 
> (this=0x2ae6ba528290, event=, edata=0x2aab7b237f18) at 
> Http2ClientSession.cc:426
> #6  0x2acf0982 in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=0x2ae6ba528290) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #7  Http2ClientSession::state_start_frame_read (this=0x2ae6ba528290, 
> event=, edata=0x2aab7b237f18) at Http2ClientSession.cc:399
> #8  0x2acef5a3 in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=0x2ae6ba528290) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #9  Http2ClientSession::state_complete_frame_read (this=0x2ae6ba528290, 
> event=, edata=0x2aab7b237f18) at Http2ClientSession.cc:431
> #10 0x2acf0982 in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=0x2ae6ba528290) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #11 Http2ClientSession::state_start_frame_read (this=0x2ae6ba528290, 
> event=, edata=0x2aab7b237f18) at Http2ClientSession.cc:399
> #12 0x2ae67e2b in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #13 read_signal_and_update (vc=0x2aab7b237e00, vc@entry=0x1, 
> event=event@entry=100) at UnixNetVConnection.cc:153
> #14 UnixNetVConnection::readSignalAndUpdate (this=this@entry=0x2aab7b237e00, 
> event=event@entry=100) at UnixNetVConnection.cc:1036
> #15 0x2ae47653 in SSLNetVConnection::net_read_io 
> (this=0x2aab7b237e00, nh=0x2aaab2409cc0, lthread=0x2aaab2406000) at 
> SSLNetVConnection.cc:595
> #16 0x2ae5558c in NetHandler::mainNetEvent (this=0x2aaab2409cc0, 
> event=, e=) at UnixNet.cc:513
> #17 0x2ae8d2e6 in Continuation::handleEvent (data=0x2aaab0bfa700, 
> event=5, this=) at I_Continuation.h:153
> #18 EThread::process_event (calling_code=5, e=0x2aaab0bfa700, 
> this=0x2aaab2406000) at UnixEThread.cc:148
> #19 EThread::execute (this=0x2aaab2406000) at UnixEThread.cc:275
> #20 0x2ae8c0e6 in spawn_thread_internal (a=0x2aaab0b25bb0) at 
> Thread.cc:86
> #21 0x2d6b3aa1 in start_thread (arg=0x2aaab3d04700) at 
> pthread_create.c:301
> #22 0x2e8bc93d in clone () at 
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:115
> {code}
> Here is the stream_list trace.
> {code}
> (gdb) thread 51
> [Switching to thread 51 (Thread 0x2aaab3d04700 (LWP 34270))]
> #0  0x2acf3fee in Http2ConnectionState::restart_streams 
> (this=0x2ae6ba5284c8) at Http2Conne

[GitHub] trafficserver issue #1106: Add prr proxy_request_retries log field

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1106
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/1004/ 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 #1097: Make the use of madvise() with MADV_DONTDU...

[jrushford]

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

https://github.com/apache/trafficserver/pull/1097#discussion_r83292609
  
--- Diff: iocore/eventsystem/EventSystem.cc ---
@@ -51,5 +51,15 @@ ink_event_system_init(ModuleVersion v)
   if (default_large_iobuffer_size > max_iobuffer_size) {
 default_large_iobuffer_size = max_iobuffer_size;
   }
+
+#ifdef MADV_DONTDUMP // This should only exist on Linux 3.4 and higher.
+  bool dont_dump_enabled;
--- End diff --

done


---
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 #1106: Add prr proxy_request_retries log field

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1106
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/896/ 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 #1100: TS-4916: Fix for an H2-infinite-loop deadl...

[shinrich]

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

https://github.com/apache/trafficserver/pull/1100#discussion_r83291135
  
--- Diff: proxy/http2/Http2ConnectionState.cc ---
@@ -1097,6 +1141,7 @@ void
 Http2ConnectionState::send_data_frames(Http2Stream *stream)
 {
   if (stream->get_state() == HTTP2_STREAM_STATE_CLOSED) {
+this->delete_stream(stream);
 return;
--- End diff --

Were we leaking a stream without a delete call? 


---
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-4916) Http2ConnectionState::restart_streams infinite loop causes deadlock

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/1100#discussion_r83290881
  
--- Diff: proxy/http2/Http2ConnectionState.cc ---
@@ -936,30 +940,70 @@ Http2ConnectionState::cleanup_streams()
 void
 Http2ConnectionState::delete_stream(Http2Stream *stream)
 {
+  // The following check allows the method to be called safely on already 
deleted streams.
+  if (deleted_from_active_streams(stream)) {
+return;
+  }
+
+  SCOPED_MUTEX_LOCK(lock, this->mutex, this_ethread());
+
--- End diff --

Why do you need to grab a lock here?  Given the mutex sharing between vc 
and session and ConnectionState, we should already be holding this mutex.


Issue Time Tracking
---

Worklog Id: (was: 30606)
Time Spent: 3h 40m  (was: 3.5h)

> Http2ConnectionState::restart_streams infinite loop causes deadlock 
> 
>
> Key: TS-4916
> URL: https://issues.apache.org/jira/browse/TS-4916
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, HTTP/2
>Reporter: Gancho Tenev
>Assignee: Gancho Tenev
>Priority: Blocker
> Fix For: 7.1.0
>
>  Time Spent: 3h 40m
>  Remaining Estimate: 0h
>
> Http2ConnectionState::restart_streams falls into an infinite loop while 
> holding a lock, which leads to cache updates to start failing.
> The infinite loop is caused by traversing a list whose last element “next” 
> points to the element itself and the traversal never finishes.
> {code}
> Thread 51 (Thread 0x2aaab3d04700 (LWP 34270)):
> #0  0x2acf3fee in Http2ConnectionState::restart_streams 
> (this=0x2ae6ba5284c8) at Http2ConnectionState.cc:913
> #1  rcv_window_update_frame (cstate=..., frame=...) at 
> Http2ConnectionState.cc:627
> #2  0x2acf9738 in Http2ConnectionState::main_event_handler 
> (this=0x2ae6ba5284c8, event=, edata=) at 
> Http2ConnectionState.cc:823
> #3  0x2acef1c3 in Continuation::handleEvent (data=0x2aaab3d039a0, 
> event=2253, this=0x2ae6ba5284c8) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #4  send_connection_event (cont=cont@entry=0x2ae6ba5284c8, 
> event=event@entry=2253, edata=edata@entry=0x2aaab3d039a0) at 
> Http2ClientSession.cc:58
> #5  0x2acef462 in Http2ClientSession::state_complete_frame_read 
> (this=0x2ae6ba528290, event=, edata=0x2aab7b237f18) at 
> Http2ClientSession.cc:426
> #6  0x2acf0982 in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=0x2ae6ba528290) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #7  Http2ClientSession::state_start_frame_read (this=0x2ae6ba528290, 
> event=, edata=0x2aab7b237f18) at Http2ClientSession.cc:399
> #8  0x2acef5a3 in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=0x2ae6ba528290) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #9  Http2ClientSession::state_complete_frame_read (this=0x2ae6ba528290, 
> event=, edata=0x2aab7b237f18) at Http2ClientSession.cc:431
> #10 0x2acf0982 in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=0x2ae6ba528290) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #11 Http2ClientSession::state_start_frame_read (this=0x2ae6ba528290, 
> event=, edata=0x2aab7b237f18) at Http2ClientSession.cc:399
> #12 0x2ae67e2b in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #13 read_signal_and_update (vc=0x2aab7b237e00, vc@entry=0x1, 
> event=event@entry=100) at UnixNetVConnection.cc:153
> #14 UnixNetVConnection::readSignalAndUpdate (this=this@entry=0x2aab7b237e00, 
> event=event@entry=100) at UnixNetVConnection.cc:1036
> #15 0x2ae47653 in SSLNetVConnection::net_read_io 
> (this=0x2aab7b237e00, nh=0x2aaab2409cc0, lthread=0x2aaab2406000) at 
> SSLNetVConnection.cc:595
> #16 0x2ae5558c in NetHandler::mainNetEvent (this=0x2aaab2409cc0, 
> event=, e=) at UnixNet.cc:513
> #17 0x2ae8d2e6 in Continuation::handleEvent (data=0x2aaab0bfa700, 
> event=5, this=) at I_Continuation.h:153
> #18 EThread::process_event (calling_code=5, e=0x2aaab0bfa700, 
> this=0x2aaab2406000) at UnixEThread.cc:148
> #19 EThread::execute (this=0x2aaab2406000) at UnixEThread.cc:275
> #20 0x2ae8c0e6 in spawn_thread_internal (a=0x2aaab0b25bb0) at 
> Thread.cc:86
> #21 0x2d6b3aa1 in start_thread (arg=0x2aaa

[jira] [Work logged] (TS-4966) Debug asserts fail when trying to schedule a continuation from a lifecycle plugin message hook

[ASF GitHub Bot (JIRA)]

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

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

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

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


Issue Time Tracking
---

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

> Debug asserts fail when trying to schedule a continuation from a lifecycle 
> plugin message hook
> --
>
> Key: TS-4966
> URL: https://issues.apache.org/jira/browse/TS-4966
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: Alan M. Carroll
>Assignee: Alan M. Carroll
> Fix For: 7.1.0
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> The plugin message callback for the lifecycle hook is called from a special 
> core thread which is not an {{EThread}}. Because of this debug assertions 
> fail in {{TSContSchedule}} (and other API calls) because mutex operations 
> fail due to the lack of {{EThread}}.



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

[GitHub] trafficserver pull request #1103: TS-4966: Fix process manager thread to sup...

[SolidWallOfCode]

Github user SolidWallOfCode closed the pull request at:

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


---
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-4916) Http2ConnectionState::restart_streams infinite loop causes deadlock

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/1100#discussion_r83291283
  
--- Diff: proxy/http2/Http2Stream.cc ---
@@ -267,10 +267,12 @@ Http2Stream::do_io_close(int /* flags */)
   // Make sure any trailing end of stream frames are sent
   // Ourselve will be removed at send_data_frames or closing 
connection phase
   static_cast(parent)->connection_state.send_data_frames(this);
+
+  // Make sure the stream is deleted at this point since next step is 
self destroy.
+  this->delete_stream();
--- End diff --

It isn't clear to me that this delete_stream is necessary either.


Issue Time Tracking
---

Worklog Id: (was: 30608)
Time Spent: 4h  (was: 3h 50m)

> Http2ConnectionState::restart_streams infinite loop causes deadlock 
> 
>
> Key: TS-4916
> URL: https://issues.apache.org/jira/browse/TS-4916
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, HTTP/2
>Reporter: Gancho Tenev
>Assignee: Gancho Tenev
>Priority: Blocker
> Fix For: 7.1.0
>
>  Time Spent: 4h
>  Remaining Estimate: 0h
>
> Http2ConnectionState::restart_streams falls into an infinite loop while 
> holding a lock, which leads to cache updates to start failing.
> The infinite loop is caused by traversing a list whose last element “next” 
> points to the element itself and the traversal never finishes.
> {code}
> Thread 51 (Thread 0x2aaab3d04700 (LWP 34270)):
> #0  0x2acf3fee in Http2ConnectionState::restart_streams 
> (this=0x2ae6ba5284c8) at Http2ConnectionState.cc:913
> #1  rcv_window_update_frame (cstate=..., frame=...) at 
> Http2ConnectionState.cc:627
> #2  0x2acf9738 in Http2ConnectionState::main_event_handler 
> (this=0x2ae6ba5284c8, event=, edata=) at 
> Http2ConnectionState.cc:823
> #3  0x2acef1c3 in Continuation::handleEvent (data=0x2aaab3d039a0, 
> event=2253, this=0x2ae6ba5284c8) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #4  send_connection_event (cont=cont@entry=0x2ae6ba5284c8, 
> event=event@entry=2253, edata=edata@entry=0x2aaab3d039a0) at 
> Http2ClientSession.cc:58
> #5  0x2acef462 in Http2ClientSession::state_complete_frame_read 
> (this=0x2ae6ba528290, event=, edata=0x2aab7b237f18) at 
> Http2ClientSession.cc:426
> #6  0x2acf0982 in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=0x2ae6ba528290) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #7  Http2ClientSession::state_start_frame_read (this=0x2ae6ba528290, 
> event=, edata=0x2aab7b237f18) at Http2ClientSession.cc:399
> #8  0x2acef5a3 in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=0x2ae6ba528290) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #9  Http2ClientSession::state_complete_frame_read (this=0x2ae6ba528290, 
> event=, edata=0x2aab7b237f18) at Http2ClientSession.cc:431
> #10 0x2acf0982 in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=0x2ae6ba528290) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #11 Http2ClientSession::state_start_frame_read (this=0x2ae6ba528290, 
> event=, edata=0x2aab7b237f18) at Http2ClientSession.cc:399
> #12 0x2ae67e2b in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #13 read_signal_and_update (vc=0x2aab7b237e00, vc@entry=0x1, 
> event=event@entry=100) at UnixNetVConnection.cc:153
> #14 UnixNetVConnection::readSignalAndUpdate (this=this@entry=0x2aab7b237e00, 
> event=event@entry=100) at UnixNetVConnection.cc:1036
> #15 0x2ae47653 in SSLNetVConnection::net_read_io 
> (this=0x2aab7b237e00, nh=0x2aaab2409cc0, lthread=0x2aaab2406000) at 
> SSLNetVConnection.cc:595
> #16 0x2ae5558c in NetHandler::mainNetEvent (this=0x2aaab2409cc0, 
> event=, e=) at UnixNet.cc:513
> #17 0x2ae8d2e6 in Continuation::handleEvent (data=0x2aaab0bfa700, 
> event=5, this=) at I_Continuation.h:153
> #18 EThread::process_event (calling_code=5, e=0x2aaab0bfa700, 
> this=0x2aaab2406000) at UnixEThread.cc:148
> #19 EThread::execute (this=0x2aaab2406000) at UnixEThread.cc:275
> #20 0x2ae8c0e6 in spawn_thread_internal (a=0x2aaab0b25bb0) at 
> Thread.cc:86
> #21 0x2d6b3aa1 in start_thread (arg=0x2aaab3d04700) at 
> pthread_create.c:301
> #22 0x2e8bc

[GitHub] trafficserver pull request #1100: TS-4916: Fix for an H2-infinite-loop deadl...

[shinrich]

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

https://github.com/apache/trafficserver/pull/1100#discussion_r83291283
  
--- Diff: proxy/http2/Http2Stream.cc ---
@@ -267,10 +267,12 @@ Http2Stream::do_io_close(int /* flags */)
   // Make sure any trailing end of stream frames are sent
   // Ourselve will be removed at send_data_frames or closing 
connection phase
   static_cast(parent)->connection_state.send_data_frames(this);
+
+  // Make sure the stream is deleted at this point since next step is 
self destroy.
+  this->delete_stream();
--- End diff --

It isn't clear to me that this delete_stream is necessary either.


---
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-4916) Http2ConnectionState::restart_streams infinite loop causes deadlock

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/1100#discussion_r83291135
  
--- Diff: proxy/http2/Http2ConnectionState.cc ---
@@ -1097,6 +1141,7 @@ void
 Http2ConnectionState::send_data_frames(Http2Stream *stream)
 {
   if (stream->get_state() == HTTP2_STREAM_STATE_CLOSED) {
+this->delete_stream(stream);
 return;
--- End diff --

Were we leaking a stream without a delete call? 


Issue Time Tracking
---

Worklog Id: (was: 30607)
Time Spent: 3h 50m  (was: 3h 40m)

> Http2ConnectionState::restart_streams infinite loop causes deadlock 
> 
>
> Key: TS-4916
> URL: https://issues.apache.org/jira/browse/TS-4916
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, HTTP/2
>Reporter: Gancho Tenev
>Assignee: Gancho Tenev
>Priority: Blocker
> Fix For: 7.1.0
>
>  Time Spent: 3h 50m
>  Remaining Estimate: 0h
>
> Http2ConnectionState::restart_streams falls into an infinite loop while 
> holding a lock, which leads to cache updates to start failing.
> The infinite loop is caused by traversing a list whose last element “next” 
> points to the element itself and the traversal never finishes.
> {code}
> Thread 51 (Thread 0x2aaab3d04700 (LWP 34270)):
> #0  0x2acf3fee in Http2ConnectionState::restart_streams 
> (this=0x2ae6ba5284c8) at Http2ConnectionState.cc:913
> #1  rcv_window_update_frame (cstate=..., frame=...) at 
> Http2ConnectionState.cc:627
> #2  0x2acf9738 in Http2ConnectionState::main_event_handler 
> (this=0x2ae6ba5284c8, event=, edata=) at 
> Http2ConnectionState.cc:823
> #3  0x2acef1c3 in Continuation::handleEvent (data=0x2aaab3d039a0, 
> event=2253, this=0x2ae6ba5284c8) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #4  send_connection_event (cont=cont@entry=0x2ae6ba5284c8, 
> event=event@entry=2253, edata=edata@entry=0x2aaab3d039a0) at 
> Http2ClientSession.cc:58
> #5  0x2acef462 in Http2ClientSession::state_complete_frame_read 
> (this=0x2ae6ba528290, event=, edata=0x2aab7b237f18) at 
> Http2ClientSession.cc:426
> #6  0x2acf0982 in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=0x2ae6ba528290) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #7  Http2ClientSession::state_start_frame_read (this=0x2ae6ba528290, 
> event=, edata=0x2aab7b237f18) at Http2ClientSession.cc:399
> #8  0x2acef5a3 in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=0x2ae6ba528290) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #9  Http2ClientSession::state_complete_frame_read (this=0x2ae6ba528290, 
> event=, edata=0x2aab7b237f18) at Http2ClientSession.cc:431
> #10 0x2acf0982 in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=0x2ae6ba528290) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #11 Http2ClientSession::state_start_frame_read (this=0x2ae6ba528290, 
> event=, edata=0x2aab7b237f18) at Http2ClientSession.cc:399
> #12 0x2ae67e2b in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #13 read_signal_and_update (vc=0x2aab7b237e00, vc@entry=0x1, 
> event=event@entry=100) at UnixNetVConnection.cc:153
> #14 UnixNetVConnection::readSignalAndUpdate (this=this@entry=0x2aab7b237e00, 
> event=event@entry=100) at UnixNetVConnection.cc:1036
> #15 0x2ae47653 in SSLNetVConnection::net_read_io 
> (this=0x2aab7b237e00, nh=0x2aaab2409cc0, lthread=0x2aaab2406000) at 
> SSLNetVConnection.cc:595
> #16 0x2ae5558c in NetHandler::mainNetEvent (this=0x2aaab2409cc0, 
> event=, e=) at UnixNet.cc:513
> #17 0x2ae8d2e6 in Continuation::handleEvent (data=0x2aaab0bfa700, 
> event=5, this=) at I_Continuation.h:153
> #18 EThread::process_event (calling_code=5, e=0x2aaab0bfa700, 
> this=0x2aaab2406000) at UnixEThread.cc:148
> #19 EThread::execute (this=0x2aaab2406000) at UnixEThread.cc:275
> #20 0x2ae8c0e6 in spawn_thread_internal (a=0x2aaab0b25bb0) at 
> Thread.cc:86
> #21 0x2d6b3aa1 in start_thread (arg=0x2aaab3d04700) at 
> pthread_create.c:301
> #22 0x2e8bc93d in clone () at 
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:115
> {code}
> Here is the stream_list trace.
> {code}
> (gdb) thread 51
> [Switching to thread 51 (Thread 0x2aaab3d04700 (LWP 34270))]
> #0  0x0

[GitHub] trafficserver pull request #1100: TS-4916: Fix for an H2-infinite-loop deadl...

[shinrich]

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

https://github.com/apache/trafficserver/pull/1100#discussion_r83290881
  
--- Diff: proxy/http2/Http2ConnectionState.cc ---
@@ -936,30 +940,70 @@ Http2ConnectionState::cleanup_streams()
 void
 Http2ConnectionState::delete_stream(Http2Stream *stream)
 {
+  // The following check allows the method to be called safely on already 
deleted streams.
+  if (deleted_from_active_streams(stream)) {
+return;
+  }
+
+  SCOPED_MUTEX_LOCK(lock, this->mutex, this_ethread());
+
--- End diff --

Why do you need to grab a lock here?  Given the mutex sharing between vc 
and session and ConnectionState, we should already be holding this mutex.


---
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 #1105: TS-4968: Log a warning if connect_attempts_rr_ret...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1105
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/895/ 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-4968) Log a warning if connect_attempts_rr_retries is >= connect_attempts_max_retries

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Log a warning if connect_attempts_rr_retries is >= 
> connect_attempts_max_retries
> ---
>
> Key: TS-4968
> URL: https://issues.apache.org/jira/browse/TS-4968
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HTTP
>Reporter: Thomas Jackson
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> If connect_attempts_rr_retries >= connect_attempts_max_retries requests going 
> to an RR DNS record will never be redispatched. To make it a bit more 
> obvious-- I think we should log a warning when we load the configs.



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

[GitHub] trafficserver pull request #1106: Add prr proxy_request_retries log field

[jacksontj]

GitHub user jacksontj opened a pull request:

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

Add prr proxy_request_retries log field



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

$ git pull https://github.com/jacksontj/trafficserver TS-4969

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

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


commit 453e5c77902bf244b39b242939e934323178dc0d
Author: Thomas Jackson 
Date:   2016-10-13T19:11:29Z

Add prr proxy_request_retries log field




---
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-4968) Log a warning if connect_attempts_rr_retries is >= connect_attempts_max_retries

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Log a warning if connect_attempts_rr_retries is >= 
> connect_attempts_max_retries
> ---
>
> Key: TS-4968
> URL: https://issues.apache.org/jira/browse/TS-4968
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HTTP
>Reporter: Thomas Jackson
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> If connect_attempts_rr_retries >= connect_attempts_max_retries requests going 
> to an RR DNS record will never be redispatched. To make it a bit more 
> obvious-- I think we should log a warning when we load the configs.



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

[jira] [Created] (TS-4969) Add log field for number of retries against origin

[Thomas Jackson (JIRA)]

Thomas Jackson created TS-4969:
--

 Summary: Add log field for number of retries against origin
 Key: TS-4969
 URL: https://issues.apache.org/jira/browse/TS-4969
 Project: Traffic Server
  Issue Type: Improvement
  Components: HTTP
Reporter: Thomas Jackson


We have configuration options for retries, but I don't see a mechanism to log 
the number of retries that have happened. This would be immensely helpful in 
debugging origin issues.



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

[GitHub] trafficserver issue #1105: TS-4968: Log a warning if connect_attempts_rr_ret...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1105
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/1003/ 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 #1088: TS-4915: Crash from hostdb in PriorityQueu...

[shinrich]

Github user shinrich closed the pull request at:

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


---
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-4915) Crash from hostdb in PriorityQueueLess

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 13/Oct/16 19:03
Start Date: 13/Oct/16 19:03
Worklog Time Spent: 10m 
  Work Description: Github user shinrich closed the pull request at:

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


Issue Time Tracking
---

Worklog Id: (was: 30603)
Time Spent: 6h 10m  (was: 6h)

> Crash from hostdb in PriorityQueueLess
> --
>
> Key: TS-4915
> URL: https://issues.apache.org/jira/browse/TS-4915
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HostDB
>Reporter: Susan Hinrichs
>Priority: Blocker
> Fix For: 7.1.0
>
> Attachments: ts-4915.diff, ts-4915.diff
>
>  Time Spent: 6h 10m
>  Remaining Estimate: 0h
>
> Saw this while testing fix for TS-4813 with debug enabled.
> {code}
> (gdb) bt full
> #0  0x00547bfe in RefCountCacheHashEntry::operator< (this=0x1cc0880, 
> v2=...) at ../iocore/hostdb/P_RefCountCache.h:94
> No locals.
> #1  0x0054988d in 
> PriorityQueueLess::operator() (this=0x2b78a9a2587b, 
> a=@0x2b78f402af68, b=@0x2b78f402aa28)
> at ../lib/ts/PriorityQueue.h:41
> No locals.
> #2  0x00549785 in PriorityQueue PriorityQueueLess >::_bubble_up (this=0x1cb2990, 
> index=2) at ../lib/ts/PriorityQueue.h:191
> comp = {}
> parent = 0
> #3  0x006ecfcc in PriorityQueue PriorityQueueLess >::push (this=0x1cb2990, 
> entry=0x2b78f402af60) at ../../lib/ts/PriorityQueue.h:91
> len = 2
> #4  0x006ec206 in RefCountCachePartition::put 
> (this=0x1cb2900, key=6912554662447498853, item=0x2b78aee04f00, size=96, 
> expire_time=1475202356) at ./P_RefCountCache.h:210
> expiry_entry = 0x2b78f402af60
> __func__ = "put"
> val = 0x1cc0880
> #5  0x006eb3de in RefCountCache::put (this=0x18051e0, 
> key=6912554662447498853, item=0x2b78aee04f00, size=16, 
> expiry_time=1475202356) at ./P_RefCountCache.h:462
> No locals.
> #6  0x006e2d8e in HostDBContinuation::dnsEvent (this=0x2b7938020f00, 
> event=600, e=0x2b78ac009440) at HostDB.cc:1422
> is_rr = false
> old_rr_data = 0x0
> first_record = 0x2b78ac0094f8
> m = 0x1
> failed = false
> old_r = {m_ptr = 0x0}
> af = 2 '\002'
> s_size = 16
> rrsize = 0
> allocSize = 16
> r = 0x2b78aee04f00
> old_info = { = { = {_vptr.ForceVFPTToTop 
> = 0x7f3630}, m_refcount = 0}, iobuffer_index = 0, 
>   key = 47797242059264, app = {allotment = {application1 = 5326300, 
> application2 = 0}, http_data = {http_version = 4, 
>   pipeline_max = 59, keepalive_timeout = 17, fail_count = 81, 
> unused1 = 0, last_failure = 0}, rr = {offset = 5326300}}, data = {
> ip = {sa = {sa_family = 54488, sa_data = 
> "^\000\000\000\000\000\020\034$\274x+\000"}, sin = {sin_family = 54488, 
> sin_port = 94, 
> sin_addr = {s_addr = 0}, sin_zero = "\020\034$\274x+\000"}, 
> sin6 = {sin6_family = 54488, sin6_port = 94, sin6_flowinfo = 0, 
> sin6_addr = {__in6_u = {__u6_addr8 = 
> "\020\034$\274x+\000\000\030\036$\274\375\b\000", __u6_addr16 = {7184, 48164, 
> 11128, 
>   0, 7704, 48164, 2301, 0}, __u6_addr32 = {3156483088, 
> 11128, 3156483608, 2301}}}, sin6_scope_id = 3156478176}}, 
> hostname_offset = 6214872, srv = {srv_offset = 54488, srv_weight 
> = 94, srv_priority = 0, srv_port = 0, key = 3156483088}}, 
>   hostname_offset = 11128, ip_timestamp = 2845989456, 
> ip_timeout_interval = 11128, is_srv = 0, reverse_dns = 0, round_robin = 1, 
>   round_robin_elt = 0}
> valid_records = 0
> tip = {_family = 2, _addr = {_ip4 = 540420056, _ip6 = {__in6_u = 
> {__u6_addr8 = "\330'6 x+\000\000\360L\020\250x+\000", 
> __u6_addr16 = {10200, 8246, 11128, 0, 19696, 43024, 11128, 
> 0}, __u6_addr32 = {540420056, 11128, 2819640560, 11128}}}, 
> _byte = "\330'6 x+\000\000\360L\020\250x+\000", _u32 = 
> {540420056, 11128, 2819640560, 11128}, _u64 = {47794936489944, 
>   47797215710448}}}
> ttl_seconds = 132
> aname = 0x2b7938021000 "fbmm1.zenfs.com"
> offset = 96
> thread = 0x2b78a8101010
> __func__ = "dnsEvent"
> #7  0x005145dc in Continuation::handleEvent (this=0x2b7938020f00, 
> event=600, data=0x2b78ac009440)
> at ../iocore/eventsystem/I_Continuation.h:153
> No locals.
> #8  0x006f681e in DNSEntry::postEvent (this=0x2b78f4028600) at 
> DNS.cc:1269
> __func__ = "postEvent"
> #9  0x0

[jira] [Work logged] (TS-4968) Log a warning if connect_attempts_rr_retries is >= connect_attempts_max_retries

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 13/Oct/16 18:53
Start Date: 13/Oct/16 18:53
Worklog Time Spent: 10m 
  Work Description: GitHub user jacksontj opened a pull request:

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

TS-4968: Log a warning if connect_attempts_rr_retries is >= 
connect_attempts_max_retries



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

$ git pull https://github.com/jacksontj/trafficserver TS-4968

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

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


commit 4ca4ca26e22864f415595f5be3a364e9f881ec99
Author: Thomas Jackson 
Date:   2016-10-13T18:53:20Z

TS-4968: Log a warning if connect_attempts_rr_retries is >= 
connect_attempts_max_retries




Issue Time Tracking
---

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

> Log a warning if connect_attempts_rr_retries is >= 
> connect_attempts_max_retries
> ---
>
> Key: TS-4968
> URL: https://issues.apache.org/jira/browse/TS-4968
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HTTP
>Reporter: Thomas Jackson
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> If connect_attempts_rr_retries >= connect_attempts_max_retries requests going 
> to an RR DNS record will never be redispatched. To make it a bit more 
> obvious-- I think we should log a warning when we load the configs.



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

[GitHub] trafficserver pull request #1105: TS-4968: Log a warning if connect_attempts...

[jacksontj]

GitHub user jacksontj opened a pull request:

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

TS-4968: Log a warning if connect_attempts_rr_retries is >= 
connect_attempts_max_retries



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

$ git pull https://github.com/jacksontj/trafficserver TS-4968

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

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


commit 4ca4ca26e22864f415595f5be3a364e9f881ec99
Author: Thomas Jackson 
Date:   2016-10-13T18:53:20Z

TS-4968: Log a warning if connect_attempts_rr_retries is >= 
connect_attempts_max_retries




---
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] [Created] (TS-4968) Log a warning if connect_attempts_rr_retries is >= connect_attempts_max_retries

[Thomas Jackson (JIRA)]

Thomas Jackson created TS-4968:
--

 Summary: Log a warning if connect_attempts_rr_retries is >= 
connect_attempts_max_retries
 Key: TS-4968
 URL: https://issues.apache.org/jira/browse/TS-4968
 Project: Traffic Server
  Issue Type: Improvement
  Components: HTTP
Reporter: Thomas Jackson


If connect_attempts_rr_retries >= connect_attempts_max_retries requests going 
to an RR DNS record will never be redispatched. To make it a bit more obvious-- 
I think we should log a warning when we load the configs.



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

[jira] [Work logged] (TS-4916) Http2ConnectionState::restart_streams infinite loop causes deadlock

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/1100#discussion_r83279595
  
--- Diff: iocore/aio/.diags.log.meta ---
@@ -0,0 +1 @@
+creation_time = 1476307057
--- End diff --

removed, committed by mistake


Issue Time Tracking
---

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

> Http2ConnectionState::restart_streams infinite loop causes deadlock 
> 
>
> Key: TS-4916
> URL: https://issues.apache.org/jira/browse/TS-4916
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, HTTP/2
>Reporter: Gancho Tenev
>Assignee: Gancho Tenev
>Priority: Blocker
> Fix For: 7.1.0
>
>  Time Spent: 3.5h
>  Remaining Estimate: 0h
>
> Http2ConnectionState::restart_streams falls into an infinite loop while 
> holding a lock, which leads to cache updates to start failing.
> The infinite loop is caused by traversing a list whose last element “next” 
> points to the element itself and the traversal never finishes.
> {code}
> Thread 51 (Thread 0x2aaab3d04700 (LWP 34270)):
> #0  0x2acf3fee in Http2ConnectionState::restart_streams 
> (this=0x2ae6ba5284c8) at Http2ConnectionState.cc:913
> #1  rcv_window_update_frame (cstate=..., frame=...) at 
> Http2ConnectionState.cc:627
> #2  0x2acf9738 in Http2ConnectionState::main_event_handler 
> (this=0x2ae6ba5284c8, event=, edata=) at 
> Http2ConnectionState.cc:823
> #3  0x2acef1c3 in Continuation::handleEvent (data=0x2aaab3d039a0, 
> event=2253, this=0x2ae6ba5284c8) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #4  send_connection_event (cont=cont@entry=0x2ae6ba5284c8, 
> event=event@entry=2253, edata=edata@entry=0x2aaab3d039a0) at 
> Http2ClientSession.cc:58
> #5  0x2acef462 in Http2ClientSession::state_complete_frame_read 
> (this=0x2ae6ba528290, event=, edata=0x2aab7b237f18) at 
> Http2ClientSession.cc:426
> #6  0x2acf0982 in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=0x2ae6ba528290) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #7  Http2ClientSession::state_start_frame_read (this=0x2ae6ba528290, 
> event=, edata=0x2aab7b237f18) at Http2ClientSession.cc:399
> #8  0x2acef5a3 in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=0x2ae6ba528290) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #9  Http2ClientSession::state_complete_frame_read (this=0x2ae6ba528290, 
> event=, edata=0x2aab7b237f18) at Http2ClientSession.cc:431
> #10 0x2acf0982 in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=0x2ae6ba528290) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #11 Http2ClientSession::state_start_frame_read (this=0x2ae6ba528290, 
> event=, edata=0x2aab7b237f18) at Http2ClientSession.cc:399
> #12 0x2ae67e2b in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #13 read_signal_and_update (vc=0x2aab7b237e00, vc@entry=0x1, 
> event=event@entry=100) at UnixNetVConnection.cc:153
> #14 UnixNetVConnection::readSignalAndUpdate (this=this@entry=0x2aab7b237e00, 
> event=event@entry=100) at UnixNetVConnection.cc:1036
> #15 0x2ae47653 in SSLNetVConnection::net_read_io 
> (this=0x2aab7b237e00, nh=0x2aaab2409cc0, lthread=0x2aaab2406000) at 
> SSLNetVConnection.cc:595
> #16 0x2ae5558c in NetHandler::mainNetEvent (this=0x2aaab2409cc0, 
> event=, e=) at UnixNet.cc:513
> #17 0x2ae8d2e6 in Continuation::handleEvent (data=0x2aaab0bfa700, 
> event=5, this=) at I_Continuation.h:153
> #18 EThread::process_event (calling_code=5, e=0x2aaab0bfa700, 
> this=0x2aaab2406000) at UnixEThread.cc:148
> #19 EThread::execute (this=0x2aaab2406000) at UnixEThread.cc:275
> #20 0x2ae8c0e6 in spawn_thread_internal (a=0x2aaab0b25bb0) at 
> Thread.cc:86
> #21 0x2d6b3aa1 in start_thread (arg=0x2aaab3d04700) at 
> pthread_create.c:301
> #22 0x2e8bc93d in clone () at 
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:115
> {code}
> Here is the stream_list trace.
> {code}
> (gdb) thread 51
> [Switching to thread 51 (Thread 0x2aaab3d04700 (LWP 34270))]
> #0  0x2acf3fee in Http2ConnectionState::restart_streams 
> (this=0x2ae6ba5284c8) at Http2ConnectionState.cc:913
> (gdb) trace_list stream_list
> --- count=0 ---
> id=29
> this=0x2ae673f0c840
> nex

[GitHub] trafficserver pull request #1100: TS-4916: Fix for an H2-infinite-loop deadl...

[gtenev]

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

https://github.com/apache/trafficserver/pull/1100#discussion_r83279595
  
--- Diff: iocore/aio/.diags.log.meta ---
@@ -0,0 +1 @@
+creation_time = 1476307057
--- End diff --

removed, committed by mistake


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

[jenkins]

See 

Changes:

[James Peach] TS-4963: Add option to obey keepalive on internal transactions.

--
[...truncated 5404 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... [ 70%] 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... [ 77%] 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/TSStatPeristence.en
reading sources... [ 79%] developer-guide/api/types/TSStatSync.en
reading sources... [ 79%] developer-guide/api/types/TSThreadPool.en
reading sources... [ 79%] developer-guide/api/types/TSUuid.en
reading sources... [ 80%] 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... [ 81%] 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... [ 82%] 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... [ 83%] 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... [ 84%] developer-guide/debugging/using-tsasse

[jira] [Work logged] (TS-4966) Debug asserts fail when trying to schedule a continuation from a lifecycle plugin message hook

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Debug asserts fail when trying to schedule a continuation from a lifecycle 
> plugin message hook
> --
>
> Key: TS-4966
> URL: https://issues.apache.org/jira/browse/TS-4966
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: Alan M. Carroll
>Assignee: Alan M. Carroll
> Fix For: 7.1.0
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> The plugin message callback for the lifecycle hook is called from a special 
> core thread which is not an {{EThread}}. Because of this debug assertions 
> fail in {{TSContSchedule}} (and other API calls) because mutex operations 
> fail due to the lack of {{EThread}}.



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

[GitHub] trafficserver issue #1103: TS-4966: Fix process manager thread to support TS...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1103
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/894/ 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-4966) Debug asserts fail when trying to schedule a continuation from a lifecycle plugin message hook

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Debug asserts fail when trying to schedule a continuation from a lifecycle 
> plugin message hook
> --
>
> Key: TS-4966
> URL: https://issues.apache.org/jira/browse/TS-4966
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: Alan M. Carroll
>Assignee: Alan M. Carroll
> Fix For: 7.1.0
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> The plugin message callback for the lifecycle hook is called from a special 
> core thread which is not an {{EThread}}. Because of this debug assertions 
> fail in {{TSContSchedule}} (and other API calls) because mutex operations 
> fail due to the lack of {{EThread}}.



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

[GitHub] trafficserver issue #1103: TS-4966: Fix process manager thread to support TS...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1103
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/1002/ 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] [Commented] (TS-4967) header_frequency plugin should allow logging data to a specific file

[Alan M. Carroll (JIRA)]

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

Alan M. Carroll commented on TS-4967:
-

I'll also add a {{README}} that explains how to use the plugin.

Currently to generate a report in {{traffic.out}} this command is used.
{code}
traffic_ctl plugin msg header_freq log
{code}
The change is to permit logging to a specific file with this syntax.
{code}
traffic_ctl plugin msg header_freq log:/path/to/file
{code}

> header_frequency plugin should allow logging data to a specific file
> 
>
> Key: TS-4967
> URL: https://issues.apache.org/jira/browse/TS-4967
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: Alan M. Carroll
>
> Extend the command option to the plugin to specify an output file.



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

[jira] [Created] (TS-4967) header_frequency plugin should allow logging data to a specific file

[Alan M. Carroll (JIRA)]

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

 Summary: header_frequency plugin should allow logging data to a 
specific file
 Key: TS-4967
 URL: https://issues.apache.org/jira/browse/TS-4967
 Project: Traffic Server
  Issue Type: Improvement
  Components: Plugins
Reporter: Alan M. Carroll


Extend the command option to the plugin to specify an output file.



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

[jira] [Work logged] (TS-4963) Option to allow keepalive for PluginVC.

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Option to allow keepalive for PluginVC.
> ---
>
> Key: TS-4963
> URL: https://issues.apache.org/jira/browse/TS-4963
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Configuration, Core, Plugins
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.1.0
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> Since it will take some time to explore and test a fix for TS-4960, add a 
> configuration knob to allow keepalive on internal connections.



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

[GitHub] trafficserver issue #1102: TS-4963: Add option to obey keepalive on internal...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1102
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/893/ 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-4963) Option to allow keepalive for PluginVC.

[ASF GitHub Bot (JIRA)]

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

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

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

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


Issue Time Tracking
---

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

> Option to allow keepalive for PluginVC.
> ---
>
> Key: TS-4963
> URL: https://issues.apache.org/jira/browse/TS-4963
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Configuration, Core, Plugins
>Reporter: James Peach
> Fix For: 7.1.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> Since it will take some time to explore and test a fix for TS-4960, add a 
> configuration knob to allow keepalive on internal connections.



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

[jira] [Resolved] (TS-4963) Option to allow keepalive for PluginVC.

[James Peach (JIRA)]

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

James Peach resolved TS-4963.
-
   Resolution: Fixed
 Assignee: James Peach
Fix Version/s: 7.1.0

> Option to allow keepalive for PluginVC.
> ---
>
> Key: TS-4963
> URL: https://issues.apache.org/jira/browse/TS-4963
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Configuration, Core, Plugins
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.1.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> Since it will take some time to explore and test a fix for TS-4960, add a 
> configuration knob to allow keepalive on internal connections.



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

[GitHub] trafficserver pull request #1102: TS-4963: Add option to obey keepalive on i...

[jpeach]

Github user jpeach closed the pull request at:

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


---
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-4963) Option to allow keepalive for PluginVC.

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Option to allow keepalive for PluginVC.
> ---
>
> Key: TS-4963
> URL: https://issues.apache.org/jira/browse/TS-4963
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Configuration, Core, Plugins
>Reporter: James Peach
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> Since it will take some time to explore and test a fix for TS-4960, add a 
> configuration knob to allow keepalive on internal connections.



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

[jira] [Work logged] (TS-4966) Debug asserts fail when trying to schedule a continuation from a lifecycle plugin message hook

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/1103
  
Had to fiddle with the call to `ProcessManager::start` due to casting 
issues with the function type. Rather than deal with that, I reverted to using 
the lambda which works on all C++ 11 compilers.


Issue Time Tracking
---

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

> Debug asserts fail when trying to schedule a continuation from a lifecycle 
> plugin message hook
> --
>
> Key: TS-4966
> URL: https://issues.apache.org/jira/browse/TS-4966
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: Alan M. Carroll
>Assignee: Alan M. Carroll
> Fix For: 7.1.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> The plugin message callback for the lifecycle hook is called from a special 
> core thread which is not an {{EThread}}. Because of this debug assertions 
> fail in {{TSContSchedule}} (and other API calls) because mutex operations 
> fail due to the lack of {{EThread}}.



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

[GitHub] trafficserver issue #1102: TS-4963: Add option to obey keepalive on internal...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1102
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/1001/ 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 #1103: TS-4966: Fix process manager thread to support TS...

[SolidWallOfCode]

Github user SolidWallOfCode commented on the issue:

https://github.com/apache/trafficserver/pull/1103
  
Had to fiddle with the call to `ProcessManager::start` due to casting 
issues with the function type. Rather than deal with that, I reverted to using 
the lambda which works on all C++ 11 compilers.


---
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-4963) Option to allow keepalive for PluginVC.

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/1102
  
Seems fine as an interim measure. We might want to mark it "deprecated" 
from the start so it can be removed in 8.0.


Issue Time Tracking
---

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

> Option to allow keepalive for PluginVC.
> ---
>
> Key: TS-4963
> URL: https://issues.apache.org/jira/browse/TS-4963
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Configuration, Core, Plugins
>Reporter: James Peach
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Since it will take some time to explore and test a fix for TS-4960, add a 
> configuration knob to allow keepalive on internal connections.



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

[GitHub] trafficserver issue #1102: TS-4963: Add option to obey keepalive on internal...

[SolidWallOfCode]

Github user SolidWallOfCode commented on the issue:

https://github.com/apache/trafficserver/pull/1102
  
Seems fine as an interim measure. We might want to mark it "deprecated" 
from the start so it can be removed in 8.0.


---
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-4916) Http2ConnectionState::restart_streams infinite loop causes deadlock

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Http2ConnectionState::restart_streams infinite loop causes deadlock 
> 
>
> Key: TS-4916
> URL: https://issues.apache.org/jira/browse/TS-4916
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, HTTP/2
>Reporter: Gancho Tenev
>Assignee: Gancho Tenev
>Priority: Blocker
> Fix For: 7.1.0
>
>  Time Spent: 3h 20m
>  Remaining Estimate: 0h
>
> Http2ConnectionState::restart_streams falls into an infinite loop while 
> holding a lock, which leads to cache updates to start failing.
> The infinite loop is caused by traversing a list whose last element “next” 
> points to the element itself and the traversal never finishes.
> {code}
> Thread 51 (Thread 0x2aaab3d04700 (LWP 34270)):
> #0  0x2acf3fee in Http2ConnectionState::restart_streams 
> (this=0x2ae6ba5284c8) at Http2ConnectionState.cc:913
> #1  rcv_window_update_frame (cstate=..., frame=...) at 
> Http2ConnectionState.cc:627
> #2  0x2acf9738 in Http2ConnectionState::main_event_handler 
> (this=0x2ae6ba5284c8, event=, edata=) at 
> Http2ConnectionState.cc:823
> #3  0x2acef1c3 in Continuation::handleEvent (data=0x2aaab3d039a0, 
> event=2253, this=0x2ae6ba5284c8) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #4  send_connection_event (cont=cont@entry=0x2ae6ba5284c8, 
> event=event@entry=2253, edata=edata@entry=0x2aaab3d039a0) at 
> Http2ClientSession.cc:58
> #5  0x2acef462 in Http2ClientSession::state_complete_frame_read 
> (this=0x2ae6ba528290, event=, edata=0x2aab7b237f18) at 
> Http2ClientSession.cc:426
> #6  0x2acf0982 in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=0x2ae6ba528290) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #7  Http2ClientSession::state_start_frame_read (this=0x2ae6ba528290, 
> event=, edata=0x2aab7b237f18) at Http2ClientSession.cc:399
> #8  0x2acef5a3 in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=0x2ae6ba528290) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #9  Http2ClientSession::state_complete_frame_read (this=0x2ae6ba528290, 
> event=, edata=0x2aab7b237f18) at Http2ClientSession.cc:431
> #10 0x2acf0982 in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=0x2ae6ba528290) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #11 Http2ClientSession::state_start_frame_read (this=0x2ae6ba528290, 
> event=, edata=0x2aab7b237f18) at Http2ClientSession.cc:399
> #12 0x2ae67e2b in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #13 read_signal_and_update (vc=0x2aab7b237e00, vc@entry=0x1, 
> event=event@entry=100) at UnixNetVConnection.cc:153
> #14 UnixNetVConnection::readSignalAndUpdate (this=this@entry=0x2aab7b237e00, 
> event=event@entry=100) at UnixNetVConnection.cc:1036
> #15 0x2ae47653 in SSLNetVConnection::net_read_io 
> (this=0x2aab7b237e00, nh=0x2aaab2409cc0, lthread=0x2aaab2406000) at 
> SSLNetVConnection.cc:595
> #16 0x2ae5558c in NetHandler::mainNetEvent (this=0x2aaab2409cc0, 
> event=, e=) at UnixNet.cc:513
> #17 0x2ae8d2e6 in Continuation::handleEvent (data=0x2aaab0bfa700, 
> event=5, this=) at I_Continuation.h:153
> #18 EThread::process_event (calling_code=5, e=0x2aaab0bfa700, 
> this=0x2aaab2406000) at UnixEThread.cc:148
> #19 EThread::execute (this=0x2aaab2406000) at UnixEThread.cc:275
> #20 0x2ae8c0e6 in spawn_thread_internal (a=0x2aaab0b25bb0) at 
> Thread.cc:86
> #21 0x2d6b3aa1 in start_thread (arg=0x2aaab3d04700) at 
> pthread_create.c:301
> #22 0x2e8bc93d in clone () at 
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:115
> {code}
> Here is the stream_list trace.
> {code}
> (gdb) thread 51
> [Switching to thread 51 (Thread 0x2aaab3d04700 (LWP 34270))]
> #0  0x2acf3fee in Http2ConnectionState::restart_streams 
> (this=0x2ae6ba5284c8) at Http2ConnectionState.cc:913
> (gdb) trace_list stream_list
> --- count=0 ---
> id=29
> this=0x2ae673f0c840
> next=0x2aaac05d8900
> prev=(nil)
> --- count=1 ---
> id=27
> this=0x2aaa

[GitHub] trafficserver issue #1100: TS-4916: Fix for an H2-infinite-loop deadlock

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1100
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/1000/ 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 #1100: TS-4916: Fix for an H2-infinite-loop deadlock

[atsci]

Github user atsci commented on the issue:

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