Github user jacksontj commented on the pull request:
https://github.com/apache/trafficserver/pull/554#issuecomment-214621535
Well, I'm not sure that I agree it violates the encapsulation-- since its
effectively a variable that tracks timings (which are only set in specific
states in t
Github user asfgit closed the pull request at:
https://github.com/apache/trafficserver/pull/601
---
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
GitHub user jpeach opened a pull request:
https://github.com/apache/trafficserver/pull/601
Improve cache test debugging.
The "cache" regression tests consists of a collection of interdependent
test state machines, but there's no test-level debugging. Add some
logging to show
Github user calavera commented on the pull request:
https://github.com/apache/trafficserver/pull/591#issuecomment-214593633
I opened an issue https://issues.apache.org/jira/browse/TS-4384
---
If your project is set up for it, you can reply to this email and have your
reply appear on G
Github user zwoop commented on the pull request:
https://github.com/apache/trafficserver/pull/591#issuecomment-214593120
Can you create a Jira for this please?
---
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 proje
Github user masaori335 commented on the pull request:
https://github.com/apache/trafficserver/pull/600#issuecomment-214584746
Summary is added.
---
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
Github user masaori335 commented on the pull request:
https://github.com/apache/trafficserver/pull/600#issuecomment-214583503
When I send HTTP/2 request to ATS (built with debug option), I always see
this assertion is triggered.
It looks like `make check` and Regression Tests could
> On Apr 25, 2016, at 7:21 PM, Karthik Sivaraman
> wrote:
>
> Hi
>
>
> I want to share a hash table among two plug-ins. I know that TSHttpTxnArgSet
> can share transaction specific data among plugins but want to know if thats
> the recommended way.
Yeah, that is exactly what those slots ar
Hi
I want to share a hash table among two plug-ins. I know that TSHttpTxnArgSet
can share transaction specific data among plugins but want to know if thats the
recommended way.
More details: I have a hashtable that is keyed based on destination IP address
and has actions for each plugin - -
Hi all,
I would like to add configs to ignore server Cache-Control: max-age and Expires.
In my use case, I would like to let origin server administrators to
use just Cache-Control: s-maxage
to control whether the contents are cacheable.
I am planning to create a CDN service and I would like to si
Thanks Gancho. This is very helpful
Karthik
From: Gancho Tenev
Sent: Friday, April 22, 2016 4:05 PM
To: dev@trafficserver.apache.org
Subject: Re: Unit testing for plugin
Karthik,
If interested in regression / integration testing (trafficserver+plugin) u
Github user zwoop commented on the pull request:
https://github.com/apache/trafficserver/pull/554#issuecomment-214505724
It's unfortunate because it couple internal state in the SM to the
milestones, which are timing events. This means, changes to the milestones
could have bad effects
Github user jacksontj commented on the pull request:
https://github.com/apache/trafficserver/pull/554#issuecomment-214491833
Can you guys expand on the concern with using milestones for this? I can
easily add another bool to the state machine (or change the
`request_body_start` to `re
Github user JamesPeach commented on the pull request:
https://github.com/apache/trafficserver/pull/554#issuecomment-214490389
As per IRC discussion with @zwoop and @bryancall, I think we should find a
way to not use the milestones to track the state transition.
---
If your project is
Github user zwoop commented on the pull request:
https://github.com/apache/trafficserver/pull/598#issuecomment-214471698
I agree with @jacksontj , having an API here makes sense. Then you defer
any penalty cost to the actual usage of such APIs as well (so no cost when not
used).
---
Github user jacksontj commented on the pull request:
https://github.com/apache/trafficserver/pull/598#issuecomment-214471034
Right, I think the correct way was my option #2-- which would be to have an
API for getting this info (basically another mgmt API endpoint like hostdb,
stats, e
Github user bryancall commented on the pull request:
https://github.com/apache/trafficserver/pull/598#issuecomment-214469357
@jacksontj Having it part of the existing metrics would mean you would have
a metric per origin. We went down that road before and created a stats v2
which was
Github user JamesPeach commented on the pull request:
https://github.com/apache/trafficserver/pull/598#issuecomment-214464758
A log field to mark whether a server session was re-used seems helpful, but
a very different patch from what is being proposed here.
---
If your project is se
Github user shinrich commented on the pull request:
https://github.com/apache/trafficserver/pull/598#issuecomment-214463886
@jacksontj the way we are using it on the log entries is as a boolean (zero
or non-zero) to understand whether that request was able to reuse an existing
origin
Github user JamesPeach commented on the pull request:
https://github.com/apache/trafficserver/pull/598#issuecomment-214463141
@bryancall AFAICT ``server_connection_count`` is always populated, which is
hitting a global lock. If there's no consensus that this is the right approach
then
Github user jacksontj commented on the pull request:
https://github.com/apache/trafficserver/pull/598#issuecomment-214452613
@bryancall My main point here is that putting this in the access logs isn't
the right place to put it as the transactions have little to do with the
connections
Github user zwoop commented on the pull request:
https://github.com/apache/trafficserver/pull/598#issuecomment-214452495
Right, I meant, maybe it should be an option to enable these per origin
metrics in the core. At which point, the generic "metric" log tag would work,
right?
Github user bryancall commented on the pull request:
https://github.com/apache/trafficserver/pull/598#issuecomment-214452145
It is configurable to turn it off and on.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If you
Github user zwoop commented on the pull request:
https://github.com/apache/trafficserver/pull/598#issuecomment-214451815
Gotcha. Maybe that should be a regular metric instead then? Per-origin
metric? Although, that has to be configurable to turn off, because it could
explode in your f
Github user bryancall commented on the pull request:
https://github.com/apache/trafficserver/pull/598#issuecomment-214451166
@zwoop This is a value per origin, not a single number that can be
represented in the metrics/stats.
I agree, having something that can generically log
Github user SolidWallOfCode commented on the pull request:
https://github.com/apache/trafficserver/pull/598#issuecomment-214429372
Yeah. We could look at something similar to the milestone work, a generic
tag that lets you pull out a metric.
---
If your project is set up for it, you
I've renamed the function as part of my pull request. You can see the
change in this commit:
https://github.com/apache/trafficserver/pull/594/commits/4fc12c4b2d9bf7ab11b84006cf1be6657868632a
Cheers,
David
On Sun, Apr 24, 2016 at 3:15 PM, David Calavera
wrote:
> The name change makes sense to m
Github user zwoop commented on the pull request:
https://github.com/apache/trafficserver/pull/598#issuecomment-214427434
I think I agree with Thomas. This sets a bit of a bad precedence, treating
one metric as special over all other metrics by also giving it a log tag. I'd
much prefer
Github user jpeach commented on the pull request:
https://github.com/apache/trafficserver/pull/600#issuecomment-214366537
Which tests triggers this assertion? Could you summarize the explanation
from [TS-4355](https://issues.apache.org/jira/browse/TS-4355) in the commit
message?
---
Github user jacksontj commented on the pull request:
https://github.com/apache/trafficserver/pull/598#issuecomment-214360346
IMO logging the connection count isn't the right way to go-- as the
connections (number of them and lifecycle) are independent of the actual
transactions that g
Github user shinrich commented on the pull request:
https://github.com/apache/trafficserver/pull/600#issuecomment-214311782
Looks good to me.
---
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 t
31 matches
Mail list logo
