GitHub user vmamidi opened a pull request:
https://github.com/apache/trafficserver/pull/1619
Perform the config reload on ET_TASK threads
Config reload on a main thread could potentially block the requests on the
thread if the reload takes longer time.
You can merge this pull
Github user vmamidi closed the pull request at:
https://github.com/apache/trafficserver/pull/1404
---
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
Github user vmamidi commented on the issue:
https://github.com/apache/trafficserver/pull/1404
incorporated the review comments.
---
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
Github user vmamidi commented on the issue:
https://github.com/apache/trafficserver/pull/1404
According to RFC ( https://tools.ietf.org/html/rfc7231#section-4.2.1 ) all
the idempotent methods should be retryable but we can at least try to retry the
safe requests. The methods GET
GitHub user vmamidi opened a pull request:
https://github.com/apache/trafficserver/pull/1404
TS-1403 retry safe methods in case of server failures irrespective of
connection state
You can merge this pull request into a Git repository by running:
$ git pull https://github.com
GitHub user vmamidi opened an issue:
https://github.com/apache/trafficserver/issues/1403
idempotent requests should be retryable irrespective of the state of the
connection
According to RFC ( https://tools.ietf.org/html/rfc7231#section-4.2.1 ) all
the idempotent methods should
GitHub user vmamidi opened an issue:
https://github.com/apache/trafficserver/issues/1372
handle the traffic manager functionality in traffic server process
currently syncing of stats and other activities are handled in traffic
manager process. We can handle all those activities
GitHub user vmamidi opened an issue:
https://github.com/apache/trafficserver/issues/1336
cache promote plugin takes too much calculating size of LRUList
pstack shows that cache promote plugin spends lot of time calculating too
much time in determining the size of LRUList
Github user vmamidi closed the pull request at:
https://github.com/apache/trafficserver/pull/1270
---
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
GitHub user vmamidi opened a pull request:
https://github.com/apache/trafficserver/pull/1270
TS-5102 parent metrics
Add new metrics for parents
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/vmamidi/trafficserver
10 matches
Mail list logo
