[jira] [Assigned] (TS-1663) gitpubsub comments test
[ https://issues.apache.org/jira/browse/TS-1663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach reassigned TS-1663: --- Assignee: Daniel Gruno gitpubsub comments test --- Key: TS-1663 URL: https://issues.apache.org/jira/browse/TS-1663 Project: Traffic Server Issue Type: Test Reporter: Daniel Gruno Assignee: Daniel Gruno This is merely an issue set up to test the git - jira hook we are planning to use. nothing to see here. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1672) Emergency throttling can continue forever
Brian Geffon created TS-1672: Summary: Emergency throttling can continue forever Key: TS-1672 URL: https://issues.apache.org/jira/browse/TS-1672 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Brian Geffon I'm not sure how this hasn't been caught yet, but in production we've observed emergency throttling spinning forever. It turns out that the timestamp is never updated. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-1672) Emergency throttling can continue forever
[ https://issues.apache.org/jira/browse/TS-1672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Geffon reassigned TS-1672: Assignee: Brian Geffon Emergency throttling can continue forever - Key: TS-1672 URL: https://issues.apache.org/jira/browse/TS-1672 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Brian Geffon Assignee: Brian Geffon I'm not sure how this hasn't been caught yet, but in production we've observed emergency throttling spinning forever. It turns out that the timestamp is never updated. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1672) Emergency throttling can continue forever
[ https://issues.apache.org/jira/browse/TS-1672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13566797#comment-13566797 ] TrafficServer Bot commented on TS-1672: --- Commit 4d6c7eebefcf1a027d083324c0c61c05ddb32a7f from [~briang] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=4d6c7ee ] TS-1672: Emergency throttling can continue forever Emergency throttling can continue forever - Key: TS-1672 URL: https://issues.apache.org/jira/browse/TS-1672 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Brian Geffon Assignee: Brian Geffon I'm not sure how this hasn't been caught yet, but in production we've observed emergency throttling spinning forever. It turns out that the timestamp is never updated. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1672) Emergency throttling can continue forever
[ https://issues.apache.org/jira/browse/TS-1672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13566799#comment-13566799 ] Brian Geffon commented on TS-1672: -- Committed to master 4d6c7eebefcf1a027d083324c0c61c05ddb32a7f Emergency throttling can continue forever - Key: TS-1672 URL: https://issues.apache.org/jira/browse/TS-1672 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Brian Geffon Assignee: Brian Geffon I'm not sure how this hasn't been caught yet, but in production we've observed emergency throttling spinning forever. It turns out that the timestamp is never updated. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1673) Remap with recv port is using the wrong port for remapping
Brian Geffon created TS-1673: Summary: Remap with recv port is using the wrong port for remapping Key: TS-1673 URL: https://issues.apache.org/jira/browse/TS-1673 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Brian Geffon Remap with recv port is using the wrong port for remapping -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1673) Remap with recv port is using the wrong port for remapping
[ https://issues.apache.org/jira/browse/TS-1673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13566816#comment-13566816 ] TrafficServer Bot commented on TS-1673: --- Commit 49e352f975545a3254a23fd3964d5b5729cf0d04 from [~briang] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=49e352f ] TS-1673: Remap with recv port is using the wrong port Remap with recv port is using the wrong port for remapping -- Key: TS-1673 URL: https://issues.apache.org/jira/browse/TS-1673 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Brian Geffon Remap with recv port is using the wrong port for remapping -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1673) Remap with recv port is using the wrong port for remapping
[ https://issues.apache.org/jira/browse/TS-1673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Geffon updated TS-1673: - Fix Version/s: 3.3.1 Remap with recv port is using the wrong port for remapping -- Key: TS-1673 URL: https://issues.apache.org/jira/browse/TS-1673 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Brian Geffon Fix For: 3.3.1 Remap with recv port is using the wrong port for remapping -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-1673) Remap with recv port is using the wrong port for remapping
[ https://issues.apache.org/jira/browse/TS-1673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Geffon reassigned TS-1673: Assignee: Brian Geffon Remap with recv port is using the wrong port for remapping -- Key: TS-1673 URL: https://issues.apache.org/jira/browse/TS-1673 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Brian Geffon Assignee: Brian Geffon Fix For: 3.3.1 Remap with recv port is using the wrong port for remapping -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1674) TSStatIntDecrement is broken
[ https://issues.apache.org/jira/browse/TS-1674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Geffon updated TS-1674: - Summary: TSStatIntDecrement is broken (was: TSStatInDecrement is broken) TSStatIntDecrement is broken Key: TS-1674 URL: https://issues.apache.org/jira/browse/TS-1674 Project: Traffic Server Issue Type: Bug Components: TS API Reporter: Brian Geffon ATS keeps a thread-local copy of the stat value and aggregates it periodically and on demand when stats are being collected. However the decrement function doesn't let a value go negative. So in a thread that has not incremented this stat previously, the decrement call fails. This negative value check is logically flawed as it doesn't account for the per-thread distribution of the stats. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-1674) TSStatIntDecrement is broken
[ https://issues.apache.org/jira/browse/TS-1674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Geffon reassigned TS-1674: Assignee: Brian Geffon TSStatIntDecrement is broken Key: TS-1674 URL: https://issues.apache.org/jira/browse/TS-1674 Project: Traffic Server Issue Type: Bug Components: TS API Reporter: Brian Geffon Assignee: Brian Geffon ATS keeps a thread-local copy of the stat value and aggregates it periodically and on demand when stats are being collected. However the decrement function doesn't let a value go negative. So in a thread that has not incremented this stat previously, the decrement call fails. This negative value check is logically flawed as it doesn't account for the per-thread distribution of the stats. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1674) TSStatIntDecrement is broken
[ https://issues.apache.org/jira/browse/TS-1674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13566824#comment-13566824 ] TrafficServer Bot commented on TS-1674: --- Commit 6d573ce581846663508067766a6960b77d2cc6aa from [~briang] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=6d573ce ] TS-1674: TSStatIntDecrement is broken: logic is flawed TSStatIntDecrement is broken Key: TS-1674 URL: https://issues.apache.org/jira/browse/TS-1674 Project: Traffic Server Issue Type: Bug Components: TS API Reporter: Brian Geffon Assignee: Brian Geffon ATS keeps a thread-local copy of the stat value and aggregates it periodically and on demand when stats are being collected. However the decrement function doesn't let a value go negative. So in a thread that has not incremented this stat previously, the decrement call fails. This negative value check is logically flawed as it doesn't account for the per-thread distribution of the stats. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1675) Adding api TSHttpTxnClientIncomingPortSet
Brian Geffon created TS-1675: Summary: Adding api TSHttpTxnClientIncomingPortSet Key: TS-1675 URL: https://issues.apache.org/jira/browse/TS-1675 Project: Traffic Server Issue Type: New Feature Components: TS API Reporter: Brian Geffon TSHttpTxnClientIncomingPortSet is not currently available in the API, adding it.. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1675) Adding api TSHttpTxnClientIncomingPortSet
[ https://issues.apache.org/jira/browse/TS-1675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13566837#comment-13566837 ] TrafficServer Bot commented on TS-1675: --- Commit 561269868855deb25f0925dffc61da50209420a8 from [~briang] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=5612698 ] TS-1675: Adding api TSHttpTxnClientIncomingPortSet Adding api TSHttpTxnClientIncomingPortSet - Key: TS-1675 URL: https://issues.apache.org/jira/browse/TS-1675 Project: Traffic Server Issue Type: New Feature Components: TS API Reporter: Brian Geffon TSHttpTxnClientIncomingPortSet is not currently available in the API, adding it.. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1459) Backport regex_remap to 3.0.x
[ https://issues.apache.org/jira/browse/TS-1459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13566875#comment-13566875 ] Brian Geffon commented on TS-1459: -- My understanding is that we will not do another 3.0 release, so I'll close this as WONT FIX. Backport regex_remap to 3.0.x - Key: TS-1459 URL: https://issues.apache.org/jira/browse/TS-1459 Project: Traffic Server Issue Type: Bug Components: Plugins Affects Versions: 3.0.6 Reporter: Brian Geffon Assignee: Brian Geffon Priority: Minor Fix For: 3.0.6 Attachments: TS-1459.patch Back port regex_remap to 3.0.x -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-1676) FetchSM (TSFetchUrl) cannot handle POST bodies 32kb.
[ https://issues.apache.org/jira/browse/TS-1676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Geffon reassigned TS-1676: Assignee: Brian Geffon FetchSM (TSFetchUrl) cannot handle POST bodies 32kb. -- Key: TS-1676 URL: https://issues.apache.org/jira/browse/TS-1676 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Brian Geffon Assignee: Brian Geffon FetchSM processes data in chunks of 32kb, we'll need to reenable the vio if there is more data to process. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Work started] (TS-1676) FetchSM (TSFetchUrl) cannot handle POST bodies 32kb.
[ https://issues.apache.org/jira/browse/TS-1676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on TS-1676 started by Brian Geffon. FetchSM (TSFetchUrl) cannot handle POST bodies 32kb. -- Key: TS-1676 URL: https://issues.apache.org/jira/browse/TS-1676 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Brian Geffon Assignee: Brian Geffon FetchSM processes data in chunks of 32kb, we'll need to reenable the vio if there is more data to process. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Work stopped] (TS-1676) FetchSM (TSFetchUrl) cannot handle POST bodies 32kb.
[ https://issues.apache.org/jira/browse/TS-1676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on TS-1676 stopped by Brian Geffon. FetchSM (TSFetchUrl) cannot handle POST bodies 32kb. -- Key: TS-1676 URL: https://issues.apache.org/jira/browse/TS-1676 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Brian Geffon Assignee: Brian Geffon FetchSM processes data in chunks of 32kb, we'll need to reenable the vio if there is more data to process. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1677) header_filter should first look in sysconfdir for its config file
[
https://issues.apache.org/jira/browse/TS-1677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13567060#comment-13567060
]
James Peach commented on TS-1677:
-
Yeh, it would be helpful if there was a TS API that automatically looked there
for relative paths.
header_filter should first look in sysconfdir for its config file
-
Key: TS-1677
URL: https://issues.apache.org/jira/browse/TS-1677
Project: Traffic Server
Issue Type: Improvement
Components: Plugins
Reporter: Igor Galić
When {{header_filter}} plugin gets a relative config-file, it should look for
it in our {{sysconfdir}}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1006) memory management, cut down memory waste ?
[
https://issues.apache.org/jira/browse/TS-1006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13567397#comment-13567397
]
James Peach commented on TS-1006:
-
Some thoughts:
- we should start work on merging this, because I don't think it will get
sufficient review outside of trunk
- unless there is a performance cost, it should always be compiled in but
default to disabled at runtime
- when merging, break it down into smaller, uncontroversial pieces; for
example add the configuration options first, then some infrastructure, then
more functional pieces; try to avoid the unnecessary whitespace and general fix
changes
- do we really need another linked list?
- it would be great to have some unit tests
:)
memory management, cut down memory waste ?
--
Key: TS-1006
URL: https://issues.apache.org/jira/browse/TS-1006
Project: Traffic Server
Issue Type: Improvement
Components: Core
Affects Versions: 3.1.1
Reporter: Zhao Yongming
Assignee: Bin Chen
Fix For: 3.3.2
Attachments: -INTRODUCTION-.patch,
0001-TS-1006-Allocator-Introduce-a-reclaimable-InkFreeLis.patch,
0002-TS-1006-Allocator-make-InkFreeList-memory-pool-confi.patch,
Memory-Usage-After-Introduced-New-Allocator.png, memusage.ods, memusage.ods
when we review the memory usage in the production, there is something
abnormal, ie, looks like TS take much memory than index data + common system
waste, and here is some memory dump result by set
proxy.config.dump_mem_info_frequency
1, the one on a not so busy forwarding system:
physics memory: 32G
RAM cache: 22G
DISK: 6140 GB
average_object_size 64000
{code}
allocated |in-use | type size | free list name
|||--
671088640 | 37748736 |2097152 |
memory/ioBufAllocator[14]
2248146944 | 2135949312 |1048576 |
memory/ioBufAllocator[13]
1711276032 | 1705508864 | 524288 |
memory/ioBufAllocator[12]
1669332992 | 1667760128 | 262144 |
memory/ioBufAllocator[11]
2214592512 | 221184 | 131072 |
memory/ioBufAllocator[10]
2325741568 | 2323775488 | 65536 |
memory/ioBufAllocator[9]
2091909120 | 2089123840 | 32768 |
memory/ioBufAllocator[8]
1956642816 | 1956478976 | 16384 |
memory/ioBufAllocator[7]
2094530560 | 2094071808 | 8192 |
memory/ioBufAllocator[6]
356515840 | 355540992 | 4096 |
memory/ioBufAllocator[5]
1048576 | 14336 | 2048 |
memory/ioBufAllocator[4]
131072 | 0 | 1024 |
memory/ioBufAllocator[3]
65536 | 0 |512 |
memory/ioBufAllocator[2]
32768 | 0 |256 |
memory/ioBufAllocator[1]
16384 | 0 |128 |
memory/ioBufAllocator[0]
0 | 0 |576 |
memory/ICPRequestCont_allocator
0 | 0 |112 |
memory/ICPPeerReadContAllocator
0 | 0 |432 |
memory/PeerReadDataAllocator
0 | 0 | 32 |
memory/MIMEFieldSDKHandle
0 | 0 |240 |
memory/INKVConnAllocator
0 | 0 | 96 |
memory/INKContAllocator
4096 | 0 | 32 |
memory/apiHookAllocator
0 | 0 |288 |
memory/FetchSMAllocator
0 | 0 | 80 |
memory/prefetchLockHandlerAllocator
0 | 0 |176 |
memory/PrefetchBlasterAllocator
0 | 0 | 80 |
memory/prefetchUrlBlaster
0 | 0 | 96 | memory/blasterUrlList
0 | 0 | 96 |
memory/prefetchUrlEntryAllocator
0 | 0 |128 |
memory/socksProxyAllocator
0 | 0 |144 |
memory/ObjectReloadCont
3258368 | 576016 |592 |
memory/httpClientSessionAllocator
825344 | 139568 |208 |
memory/httpServerSessionAllocator
22597632 |1284848 | 9808 | memory/httpSMAllocator
0 | 0 | 32 |
memory/CacheLookupHttpConfigAllocator
0 |
[jira] [Commented] (TS-1674) TSStatIntDecrement is broken
[ https://issues.apache.org/jira/browse/TS-1674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13567418#comment-13567418 ] Uri Shachar commented on TS-1674: - This may cause problems with our patch for TS-1631 (supporting the ability to reset individual stats). I've been thinking that the 'correct' way to go here would be to unify all stats instead of maintaining a per thread copy -- thoughts? TSStatIntDecrement is broken Key: TS-1674 URL: https://issues.apache.org/jira/browse/TS-1674 Project: Traffic Server Issue Type: Bug Components: TS API Reporter: Brian Geffon Assignee: Brian Geffon Fix For: 3.3.1 ATS keeps a thread-local copy of the stat value and aggregates it periodically and on demand when stats are being collected. However the decrement function doesn't let a value go negative. So in a thread that has not incremented this stat previously, the decrement call fails. This negative value check is logically flawed as it doesn't account for the per-thread distribution of the stats. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] [Commented] (TS-1006) memory management, cut down memory waste ?
On Thu, Jan 31, 2013 at 2:17 PM, James Peach (JIRA) j...@apache.org wrote: [ https://issues.apache.org/jira/browse/TS-1006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13567397#comment-13567397] James Peach commented on TS-1006: - Some thoughts: - we should start work on merging this, because I don't think it will get sufficient review outside of trunk - unless there is a performance cost, it should always be compiled in but default to disabled at runtime Agree. - when merging, break it down into smaller, uncontroversial pieces; for example add the configuration options first, then some infrastructure, then more functional pieces; try to avoid the unnecessary whitespace and general fix changes Ok, I can split them into more pieces. - do we really need another linked list? When I developed this patchset, I was not so familiar with TS library. Now, I have found that there is a List.h file containing templated single-link/double-link list library. I'll try to use templated-list in this patchset, although I prefer C-Style link list:D. - it would be great to have some unit tests Agree, but I'm busy with other things now. Unit tests is not so urgent for us, maybe I'll write some tests in the future. I'll give a new version later with your advise. Thank you! :) -- Yunkai Zhang Work at Taobao
