[jira] [Commented] (TS-1453) remove InactivityCop and enable define INACTIVITY_TIMEOUT
[ https://issues.apache.org/jira/browse/TS-1453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13635969#comment-13635969 ] Bin Chen commented on TS-1453: -- this patch can be not depending on TS-1405. In our env, ts should handle 200 thounds connections(InActiveCop should check every 1 second every conntions, It's so terrible). Now, we should improve cpu usage. The same box and same qps, our custom proxy use cpu about 60% of ts. > remove InactivityCop and enable define INACTIVITY_TIMEOUT > - > > Key: TS-1453 > URL: https://issues.apache.org/jira/browse/TS-1453 > Project: Traffic Server > Issue Type: Sub-task > Components: Core >Affects Versions: 3.2.0 >Reporter: Bin Chen >Assignee: Bin Chen > Fix For: 3.3.5 > > Attachments: TS-1453.patch > > > when we have O(1), then we can be enable define INACTIVITY_TIMEOUT -- 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-1728) Need a way to assign storage entries to volumes
[
https://issues.apache.org/jira/browse/TS-1728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13635926#comment-13635926
]
Leif Hedstrom commented on TS-1728:
---
Alan brought up a good point, there are a few cache related configs, that with
this patch would be useful to have as additional "tags" for storage.config as
well. E.g.
{code}
/dev/sda object_size=8k volume=1
/dev/sdb object_size=1M volume=2
{code}
This would then allow hosting.config (or a plugin) to assign content most
suitable for a particular disk / cache config.
> Need a way to assign storage entries to volumes
> ---
>
> Key: TS-1728
> URL: https://issues.apache.org/jira/browse/TS-1728
> Project: Traffic Server
> Issue Type: Wish
> Components: Cache
>Reporter: Jan van Doorn
>Assignee: Phil Sorber
>Priority: Minor
> Fix For: 3.3.3
>
> Attachments: vol.patch
>
>
> See http://www.knutsel.com/vol/compare/ for a write up and some test results
> on this. We are proposing a simple way to hard link storage.config entries to
> volume.config and thus hosting.config entries.
--
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-1833) Deprecate TSMimeHdrFieldValueStringInsert() (and family)
[ https://issues.apache.org/jira/browse/TS-1833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13635860#comment-13635860 ] Leif Hedstrom commented on TS-1833: --- We should also change our plugins to use Set() consistently, as a good example. > Deprecate TSMimeHdrFieldValueStringInsert() (and family) > > > Key: TS-1833 > URL: https://issues.apache.org/jira/browse/TS-1833 > Project: Traffic Server > Issue Type: Improvement > Components: TS API >Reporter: Leif Hedstrom > > It seems to be that TSMimeHdrFieldValueStringInsert() is really just a subset > of TSMimeHdrFieldValueStringSet(). This just makes for confusing APIs, i.e. > which one do I use when? The alternative would be to remove the "idx" > argument to the TSMimeHdrFieldValueStringSet() method, but that would then > break API and ABI compatibility. > Also, as James found out, the docs are less than clear. Set() needs to be > called with an idx of -1 for it to actually be a Set() operation. With idx > >=0, TSMimeHdrFieldValueStringSet() is actually identical to > TSMimeHdrFieldValueStringInsert() -- 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-1833) Deprecate TSMimeHdrFieldValueStringInsert() (and family)
[ https://issues.apache.org/jira/browse/TS-1833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-1833: - Assignee: Leif Hedstrom > Deprecate TSMimeHdrFieldValueStringInsert() (and family) > > > Key: TS-1833 > URL: https://issues.apache.org/jira/browse/TS-1833 > Project: Traffic Server > Issue Type: Improvement > Components: TS API >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom > > It seems to be that TSMimeHdrFieldValueStringInsert() is really just a subset > of TSMimeHdrFieldValueStringSet(). This just makes for confusing APIs, i.e. > which one do I use when? The alternative would be to remove the "idx" > argument to the TSMimeHdrFieldValueStringSet() method, but that would then > break API and ABI compatibility. > Also, as James found out, the docs are less than clear. Set() needs to be > called with an idx of -1 for it to actually be a Set() operation. With idx > >=0, TSMimeHdrFieldValueStringSet() is actually identical to > TSMimeHdrFieldValueStringInsert() -- 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-1833) Deprecate TSMimeHdrFieldValueStringInsert() (and family)
[ https://issues.apache.org/jira/browse/TS-1833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1833: -- Fix Version/s: 3.3.3 > Deprecate TSMimeHdrFieldValueStringInsert() (and family) > > > Key: TS-1833 > URL: https://issues.apache.org/jira/browse/TS-1833 > Project: Traffic Server > Issue Type: Improvement > Components: TS API >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom > Fix For: 3.3.3 > > > It seems to be that TSMimeHdrFieldValueStringInsert() is really just a subset > of TSMimeHdrFieldValueStringSet(). This just makes for confusing APIs, i.e. > which one do I use when? The alternative would be to remove the "idx" > argument to the TSMimeHdrFieldValueStringSet() method, but that would then > break API and ABI compatibility. > Also, as James found out, the docs are less than clear. Set() needs to be > called with an idx of -1 for it to actually be a Set() operation. With idx > >=0, TSMimeHdrFieldValueStringSet() is actually identical to > TSMimeHdrFieldValueStringInsert() -- 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-1833) Deprecate TSMimeHdrFieldValueStringInsert() (and family)
Leif Hedstrom created TS-1833: - Summary: Deprecate TSMimeHdrFieldValueStringInsert() (and family) Key: TS-1833 URL: https://issues.apache.org/jira/browse/TS-1833 Project: Traffic Server Issue Type: Improvement Components: TS API Reporter: Leif Hedstrom It seems to be that TSMimeHdrFieldValueStringInsert() is really just a subset of TSMimeHdrFieldValueStringSet(). This just makes for confusing APIs, i.e. which one do I use when? The alternative would be to remove the "idx" argument to the TSMimeHdrFieldValueStringSet() method, but that would then break API and ABI compatibility. Also, as James found out, the docs are less than clear. Set() needs to be called with an idx of -1 for it to actually be a Set() operation. With idx >=0, TSMimeHdrFieldValueStringSet() is actually identical to TSMimeHdrFieldValueStringInsert() -- 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-952) when turn off config.proxy.hostdb, ts just reponse a 502 page.
[ https://issues.apache.org/jira/browse/TS-952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13635665#comment-13635665 ] Leif Hedstrom commented on TS-952: -- Also, looking at the code, the intent was probably to do a DNS lookup on every request (perhaps a local, caching resolver). So this does indeed seem like a valid bug, although not sure how usable it would be. > when turn off config.proxy.hostdb, ts just reponse a 502 page. > -- > > Key: TS-952 > URL: https://issues.apache.org/jira/browse/TS-952 > Project: Traffic Server > Issue Type: Bug > Components: DNS, HTTP >Affects Versions: 3.1.0 > Environment: all. >Reporter: weijin > Fix For: 3.3.4 > > > If turn config.proxy.hostdb off, ts does not do the dns query but just return > a 502 page. -- 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-952) when turn off config.proxy.hostdb, ts just reponse a 502 page.
[ https://issues.apache.org/jira/browse/TS-952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13635658#comment-13635658 ] Leif Hedstrom commented on TS-952: -- Maybe there's a use case where in transparent proxy, with certain configs, the UA (browser) actually does the DNS lookup? I can't see this being useful to disable though with forward or reverse proxy. > when turn off config.proxy.hostdb, ts just reponse a 502 page. > -- > > Key: TS-952 > URL: https://issues.apache.org/jira/browse/TS-952 > Project: Traffic Server > Issue Type: Bug > Components: DNS, HTTP >Affects Versions: 3.1.0 > Environment: all. >Reporter: weijin > Fix For: 3.3.4 > > > If turn config.proxy.hostdb off, ts does not do the dns query but just return > a 502 page. -- 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-952) when turn off config.proxy.hostdb, ts just reponse a 502 page.
[ https://issues.apache.org/jira/browse/TS-952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13635617#comment-13635617 ] James Peach commented on TS-952: What ought to happen here? Remove the proxy.config.hostdb option? > when turn off config.proxy.hostdb, ts just reponse a 502 page. > -- > > Key: TS-952 > URL: https://issues.apache.org/jira/browse/TS-952 > Project: Traffic Server > Issue Type: Bug > Components: DNS, HTTP >Affects Versions: 3.1.0 > Environment: all. >Reporter: weijin > Fix For: 3.3.4 > > > If turn config.proxy.hostdb off, ts does not do the dns query but just return > a 502 page. -- 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-1832) automatically upgrade HostDB for 3.4
[ https://issues.apache.org/jira/browse/TS-1832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13635458#comment-13635458 ] Leif Hedstrom commented on TS-1832: --- To explain the issue. The old config asks for a size 32MB DB, that can hold 120,000 objects. When you try that with the new version (at least until TS-1811 is fixed), it gets unhappy because it can not satisfy 120,000 objects with a 32MB DB. I agree, this config system is wonky, but it's different issue than the HostDB itself. I can not see an RFE filed on fixing the configuration confusion, but that seems like a good bug to add (maybe even re-subject this). Also, what Bryan runs into is that when HostDB is dysfunctional, you get the behavior from TS-952. > automatically upgrade HostDB for 3.4 > > > Key: TS-1832 > URL: https://issues.apache.org/jira/browse/TS-1832 > Project: Traffic Server > Issue Type: Bug > Components: Core, DNS >Reporter: James Peach > > http://mail-archives.apache.org/mod_mbox/trafficserver-dev/201304.mbox/%3c02b034ee-ae6b-4cde-959a-2bf80c730...@yahoo-inc.com%3e > As described by Bryan in the message above, upgrading to the newer HostDB > format breaks DNS resolution. We should make sure that users upgrading from > stable 3.2 releases never hit this problem. -- 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-1832) automatically upgrade HostDB for 3.4
[ https://issues.apache.org/jira/browse/TS-1832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13635416#comment-13635416 ] Leif Hedstrom commented on TS-1832: --- It does that. The problem is running ATS with an old config. Yes, it's wonky, but's not a HostDB "vesrion" issue, it's a config issue. > automatically upgrade HostDB for 3.4 > > > Key: TS-1832 > URL: https://issues.apache.org/jira/browse/TS-1832 > Project: Traffic Server > Issue Type: Bug > Components: Core, DNS >Reporter: James Peach > > http://mail-archives.apache.org/mod_mbox/trafficserver-dev/201304.mbox/%3c02b034ee-ae6b-4cde-959a-2bf80c730...@yahoo-inc.com%3e > As described by Bryan in the message above, upgrading to the newer HostDB > format breaks DNS resolution. We should make sure that users upgrading from > stable 3.2 releases never hit this problem. -- 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-1832) automatically upgrade HostDB for 3.4
James Peach created TS-1832: --- Summary: automatically upgrade HostDB for 3.4 Key: TS-1832 URL: https://issues.apache.org/jira/browse/TS-1832 Project: Traffic Server Issue Type: Bug Components: Core, DNS Reporter: James Peach http://mail-archives.apache.org/mod_mbox/trafficserver-dev/201304.mbox/%3c02b034ee-ae6b-4cde-959a-2bf80c730...@yahoo-inc.com%3e As described by Bryan in the message above, upgrading to the newer HostDB format breaks DNS resolution. We should make sure that users upgrading from stable 3.2 releases never hit this problem. -- 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-1830) add getpagesize library function
[ https://issues.apache.org/jira/browse/TS-1830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13635365#comment-13635365 ] ASF subversion and git services commented on TS-1830: - Commit fce0cf4f6e3d86043cf37599a32fc73c31f8bb01 in branch refs/heads/master from [~jpe...@apache.org] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=fce0cf4 ] TS-1830: use ats_pagesize wrapper everywhere > add getpagesize library function > > > Key: TS-1830 > URL: https://issues.apache.org/jira/browse/TS-1830 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Reporter: James Peach >Assignee: James Peach >Priority: Minor > Fix For: 3.3.3 > > > We use sysconf(_SC_PAGESIZE) and getpagesize() interchangeably. It would be > clearer if we had an ats_pagesize() API that was used everywhere. -- 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-1831) traffic_logstats should not always require log dir access
James Peach created TS-1831:
---
Summary: traffic_logstats should not always require log dir access
Key: TS-1831
URL: https://issues.apache.org/jira/browse/TS-1831
Project: Traffic Server
Issue Type: Bug
Components: Logging
Reporter: James Peach
When running "make check", the traffic_logstats test fails if the host system
does not have a current Traffic Server installation:
{code}
FAIL: tests/test_logstats_json
==
unable to change to log directory
"/home/vagrant/build/proxy/var/log/trafficserver" [2 'No such file or
directory']
please set correct path in env variable TS_ROOT
{code}
It's unreasonable for traffic_logstats to absolutely require the logdir to be
present. We should investigate whether the chdir failure can be weakened to a
warning instead of a hard error.
--
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-1830) add getpagesize library function
James Peach created TS-1830: --- Summary: add getpagesize library function Key: TS-1830 URL: https://issues.apache.org/jira/browse/TS-1830 Project: Traffic Server Issue Type: Improvement Components: Core Reporter: James Peach We use sysconf(_SC_PAGESIZE) and getpagesize() interchangeably. It would be clearer if we had an ats_pagesize() API that was used everywhere. -- 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-1830) add getpagesize library function
[ https://issues.apache.org/jira/browse/TS-1830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-1830: Priority: Minor (was: Major) Fix Version/s: 3.3.3 Assignee: James Peach I have a patch for this. > add getpagesize library function > > > Key: TS-1830 > URL: https://issues.apache.org/jira/browse/TS-1830 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Reporter: James Peach >Assignee: James Peach >Priority: Minor > Fix For: 3.3.3 > > > We use sysconf(_SC_PAGESIZE) and getpagesize() interchangeably. It would be > clearer if we had an ats_pagesize() API that was used everywhere. -- 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-1805) Stats: show:proxy-stats in traffic_shell only have Client Throughput, all others '0'
[
https://issues.apache.org/jira/browse/TS-1805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13635324#comment-13635324
]
James Peach commented on TS-1805:
-
Is there anything more to do on this ticket? Can we mark is as resolved and
file a separate bug for bettydramit's traffic_shell issue?
> Stats: show:proxy-stats in traffic_shell only have Client Throughput, all
> others '0'
>
>
> Key: TS-1805
> URL: https://issues.apache.org/jira/browse/TS-1805
> Project: Traffic Server
> Issue Type: Bug
> Components: Stats
>Reporter: Zhao Yongming
> Attachments:
> 0001-TS-1805-fix-conversion-when-pass-value-to-statVarSet.patch,
> 0001-TS-1805-fix-uninitialized-result_type-in-NodeStatEva.patch
>
>
> there maybe more problems, let us start with this one.
> {code}
> % show:proxy-stats
> Document Hit Rate 0.00 % *
> Ram cache Hit Rate --- 0.00 % *
> Bandwidth Saving - 0.00 % *
> Cache Percent Free --- 0.00 %
> Open Server Connections -- 0
> Open Client Connections -- 0
> Open Cache Connections --- 0
> Client Throughput 10030.373047 MBit/Sec
> Transaction Per Second --- 0.00
> {code}
--
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-1453) remove InactivityCop and enable define INACTIVITY_TIMEOUT
[ https://issues.apache.org/jira/browse/TS-1453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13635318#comment-13635318 ] Leif Hedstrom commented on TS-1453: --- I haven't reviewed this yet, but just two comments on this code base in general: 1) The reason why it is the way it is right now (two paths, one is disabled), is because it was thought that the event system could not handle the load. 2) Does this patch require the TS-1405 changes as well ? Meaning, without TS-1405, would we have a performance problem with the number of pending (future) events? > remove InactivityCop and enable define INACTIVITY_TIMEOUT > - > > Key: TS-1453 > URL: https://issues.apache.org/jira/browse/TS-1453 > Project: Traffic Server > Issue Type: Sub-task > Components: Core >Affects Versions: 3.2.0 >Reporter: Bin Chen >Assignee: Bin Chen > Fix For: 3.3.5 > > Attachments: TS-1453.patch > > > when we have O(1), then we can be enable define INACTIVITY_TIMEOUT -- 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-1805) Stats: show:proxy-stats in traffic_shell only have Client Throughput, all others '0'
[
https://issues.apache.org/jira/browse/TS-1805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13635320#comment-13635320
]
ASF subversion and git services commented on TS-1805:
-
Commit 5ceaf91afca76d94b8406c52efa60d5910e334c6 in branch refs/heads/master
from [~jpe...@apache.org]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=5ceaf91 ]
TS-1805: Make sure that we always have a RecData_t type when we evaluate
NodeStatEval.
> Stats: show:proxy-stats in traffic_shell only have Client Throughput, all
> others '0'
>
>
> Key: TS-1805
> URL: https://issues.apache.org/jira/browse/TS-1805
> Project: Traffic Server
> Issue Type: Bug
> Components: Stats
>Reporter: Zhao Yongming
> Attachments:
> 0001-TS-1805-fix-conversion-when-pass-value-to-statVarSet.patch,
> 0001-TS-1805-fix-uninitialized-result_type-in-NodeStatEva.patch
>
>
> there maybe more problems, let us start with this one.
> {code}
> % show:proxy-stats
> Document Hit Rate 0.00 % *
> Ram cache Hit Rate --- 0.00 % *
> Bandwidth Saving - 0.00 % *
> Cache Percent Free --- 0.00 %
> Open Server Connections -- 0
> Open Client Connections -- 0
> Open Cache Connections --- 0
> Client Throughput 10030.373047 MBit/Sec
> Transaction Per Second --- 0.00
> {code}
--
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-1453) remove InactivityCop and enable define INACTIVITY_TIMEOUT
[ https://issues.apache.org/jira/browse/TS-1453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13635306#comment-13635306 ] James Peach commented on TS-1453: - "volatile unsigned int disable" should be bool, since it's only used with "true" and "false" values. Why is it required to be volatile? Is there any reason to keep the INACTIVITY_TIMEOUT definition? How does this behave with large numbers of client connections? > remove InactivityCop and enable define INACTIVITY_TIMEOUT > - > > Key: TS-1453 > URL: https://issues.apache.org/jira/browse/TS-1453 > Project: Traffic Server > Issue Type: Sub-task > Components: Core >Affects Versions: 3.2.0 >Reporter: Bin Chen >Assignee: Bin Chen > Fix For: 3.3.5 > > Attachments: TS-1453.patch > > > when we have O(1), then we can be enable define INACTIVITY_TIMEOUT -- 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-1755) add basic logstats tests
[ https://issues.apache.org/jira/browse/TS-1755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13635299#comment-13635299 ] ASF subversion and git services commented on TS-1755: - Commit 311abc01c2d0567a7ab2ea01b86190b85c08c3cc in branch refs/heads/master from [~jpe...@apache.org] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=311abc0 ] TS-1755: Fix shell script standards review comments > add basic logstats tests > > > Key: TS-1755 > URL: https://issues.apache.org/jira/browse/TS-1755 > Project: Traffic Server > Issue Type: Test > Components: Logging >Reporter: James Peach >Assignee: James Peach > Fix For: 3.3.3 > > > traffic_logstats was broken for a while, but no-one noticed. We should add > some basic tests so that we can make sure that it's basically working. -- 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-295) Allowing HTTP CONNECT to be used on non-SSL ports
[ https://issues.apache.org/jira/browse/TS-295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13635107#comment-13635107 ] ASF subversion and git services commented on TS-295: Commit e125ec95838fb270bae3d46fcaff4705df4af5a1 in branch refs/heads/sphinx-docs from Uri Shachar [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=e125ec9 ] TS-295: Change ssl_ports to connect_ports in docs + typo fix > Allowing HTTP CONNECT to be used on non-SSL ports > - > > Key: TS-295 > URL: https://issues.apache.org/jira/browse/TS-295 > Project: Traffic Server > Issue Type: Improvement > Components: Documentation >Affects Versions: 2.0.0 > Environment: All? >Reporter: Marcus Clyne >Assignee: Uri Shachar >Priority: Minor > Fix For: Doc 3.4 > > Attachments: TS-295.diff > > > Currently HTTP CONNECT can only be used on ports designated as SSL ports in > the config file, even if SSL is not used. > It seems more sensible to add a config option to specify which ports can be > tunneled through using CONNECT's, perhaps defaulting to the SSL ports, but > not being limited to them. -- 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-1366) cquc does not work as documented: Logging the remapped URL
[
https://issues.apache.org/jira/browse/TS-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13635049#comment-13635049
]
ASF subversion and git services commented on TS-1366:
-
Commit 85ef72268a612c5230285cfb4b6dd48a64fadc8a in branch
refs/heads/sphinx-docs from [~amc]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=85ef722 ]
TS-1366: Update logging formats for remapped vs. pristine.
> cquc does not work as documented: Logging the remapped URL
> --
>
> Key: TS-1366
> URL: https://issues.apache.org/jira/browse/TS-1366
> Project: Traffic Server
> Issue Type: Bug
> Components: Documentation
>Reporter: Igor Galić
>Assignee: Alan M. Carroll
> Fix For: Doc 3.4
>
> Attachments: ts-1366.diff
>
>
> From the documentation
> (http://trafficserver.apache.org/docs/trunk/admin/working-log-files/log-formats#SquidFormat)
> :
> cquc
> The client request canonical URL; blanks and other characters that might
> not be parsed by log analysis tools are replaced by escape sequences. The
> escape sequence is a percentage sign followed by the ASCII code number of the
> replaced character in hex.
> But in fact it logs the remapped URL.
> This may or may not be related to the {{records.config}} setting:
> {noformat}
> CONFIG proxy.config.url_remap.pristine_host_hdr INT 1
> {noformat}
--
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] [Resolved] (TS-295) Allowing HTTP CONNECT to be used on non-SSL ports
[ https://issues.apache.org/jira/browse/TS-295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uri Shachar resolved TS-295. Resolution: Fixed Changed ssl_ports to connect_ports in the docs (ssl_ports haven't been around for ~3 years) > Allowing HTTP CONNECT to be used on non-SSL ports > - > > Key: TS-295 > URL: https://issues.apache.org/jira/browse/TS-295 > Project: Traffic Server > Issue Type: Improvement > Components: Documentation >Affects Versions: 2.0.0 > Environment: All? >Reporter: Marcus Clyne >Assignee: Uri Shachar >Priority: Minor > Fix For: Doc 3.4 > > Attachments: TS-295.diff > > > Currently HTTP CONNECT can only be used on ports designated as SSL ports in > the config file, even if SSL is not used. > It seems more sensible to add a config option to specify which ports can be > tunneled through using CONNECT's, perhaps defaulting to the SSL ports, but > not being limited to them. -- 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-295) Allowing HTTP CONNECT to be used on non-SSL ports
[ https://issues.apache.org/jira/browse/TS-295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13635028#comment-13635028 ] ASF subversion and git services commented on TS-295: Commit 1469246 from ushachar [ https://svn.apache.org/r1469246 ] TS-295: Change ssl_ports to connect_ports in docs + typo fix > Allowing HTTP CONNECT to be used on non-SSL ports > - > > Key: TS-295 > URL: https://issues.apache.org/jira/browse/TS-295 > Project: Traffic Server > Issue Type: Improvement > Components: Documentation >Affects Versions: 2.0.0 > Environment: All? >Reporter: Marcus Clyne >Assignee: Uri Shachar >Priority: Minor > Fix For: Doc 3.4 > > Attachments: TS-295.diff > > > Currently HTTP CONNECT can only be used on ports designated as SSL ports in > the config file, even if SSL is not used. > It seems more sensible to add a config option to specify which ports can be > tunneled through using CONNECT's, perhaps defaulting to the SSL ports, but > not being limited to them. -- 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-1453) remove InactivityCop and enable define INACTIVITY_TIMEOUT
[ https://issues.apache.org/jira/browse/TS-1453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen updated TS-1453: - Attachment: (was: TS-1453.patch) > remove InactivityCop and enable define INACTIVITY_TIMEOUT > - > > Key: TS-1453 > URL: https://issues.apache.org/jira/browse/TS-1453 > Project: Traffic Server > Issue Type: Sub-task > Components: Core >Affects Versions: 3.2.0 >Reporter: Bin Chen >Assignee: Bin Chen > Fix For: 3.3.5 > > Attachments: TS-1453.patch > > > when we have O(1), then we can be enable define INACTIVITY_TIMEOUT -- 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-1453) remove InactivityCop and enable define INACTIVITY_TIMEOUT
[ https://issues.apache.org/jira/browse/TS-1453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen updated TS-1453: - Attachment: TS-1453.patch base git master + TS-1405(linux_time_wheel_v11jp.patch) > remove InactivityCop and enable define INACTIVITY_TIMEOUT > - > > Key: TS-1453 > URL: https://issues.apache.org/jira/browse/TS-1453 > Project: Traffic Server > Issue Type: Sub-task > Components: Core >Affects Versions: 3.2.0 >Reporter: Bin Chen >Assignee: Bin Chen > Fix For: 3.3.5 > > Attachments: TS-1453.patch > > > when we have O(1), then we can be enable define INACTIVITY_TIMEOUT -- 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-1453) remove InactivityCop and enable define INACTIVITY_TIMEOUT
[ https://issues.apache.org/jira/browse/TS-1453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13634992#comment-13634992 ] Bin Chen commented on TS-1453: -- John & Leif, please help to review this patch(replace InActivCop), Thanks. > remove InactivityCop and enable define INACTIVITY_TIMEOUT > - > > Key: TS-1453 > URL: https://issues.apache.org/jira/browse/TS-1453 > Project: Traffic Server > Issue Type: Sub-task > Components: Core >Affects Versions: 3.2.0 >Reporter: Bin Chen >Assignee: Bin Chen > Fix For: 3.3.5 > > Attachments: TS-1453.patch > > > when we have O(1), then we can be enable define INACTIVITY_TIMEOUT -- 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-1453) remove InactivityCop and enable define INACTIVITY_TIMEOUT
[ https://issues.apache.org/jira/browse/TS-1453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen updated TS-1453: - Attachment: TS-1453.patch > remove InactivityCop and enable define INACTIVITY_TIMEOUT > - > > Key: TS-1453 > URL: https://issues.apache.org/jira/browse/TS-1453 > Project: Traffic Server > Issue Type: Sub-task > Components: Core >Affects Versions: 3.2.0 >Reporter: Bin Chen >Assignee: Bin Chen > Fix For: 3.3.5 > > Attachments: TS-1453.patch > > > when we have O(1), then we can be enable define INACTIVITY_TIMEOUT -- 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
