Github user masaori335 commented on a diff in the pull request:
https://github.com/apache/trafficserver/pull/686#discussion_r65658324
--- Diff: mgmt/api/INKMgmtAPI.cc ---
@@ -1865,8 +1865,7 @@ TSGetErrorMessage(TSMgmtError err_id)
tsapi TSMgmtError
TSEncryptPassword(char *
Github user jpeach commented on a diff in the pull request:
https://github.com/apache/trafficserver/pull/686#discussion_r65657843
--- Diff: mgmt/api/INKMgmtAPI.cc ---
@@ -1865,8 +1865,7 @@ TSGetErrorMessage(TSMgmtError err_id)
tsapi TSMgmtError
TSEncryptPassword(char *pass
Github user SolidWallOfCode commented on the issue:
https://github.com/apache/trafficserver/pull/653
The IPv4 and IPv6 addresses are stored in the same hash table because that
was easiest at the time. There's certainly no fundamental reason to do that,
although maybe it helps with kee
Github user SolidWallOfCode commented on a diff in the pull request:
https://github.com/apache/trafficserver/pull/653#discussion_r65651918
--- Diff: iocore/hostdb/HostDB.cc ---
@@ -583,7 +468,7 @@ reply_to_cont(Continuation *cont, HostDBInfo *r, bool
is_srv = false)
ink_
Github user SolidWallOfCode commented on a diff in the pull request:
https://github.com/apache/trafficserver/pull/653#discussion_r65651692
--- Diff: iocore/hostdb/HostDB.cc ---
@@ -439,37 +327,24 @@ HostDBCache::start(int flags)
Warning("Please set 'proxy.config.hostdb.stor
Github user sudheerv commented on the issue:
https://github.com/apache/trafficserver/pull/685
ð
---
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 t
Github user shukitchan commented on the issue:
https://github.com/apache/trafficserver/pull/685
@sudheerv I made the change already. Please take a look.
will definitely squash into a single commit before merge. Thanks.
---
If your project is set up for it, you can reply to this em
Github user masaori335 commented on the issue:
https://github.com/apache/trafficserver/pull/693
OK, I'll close this and think this issue again.
---
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 closed the pull request at:
https://github.com/apache/trafficserver/pull/693
---
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 feat
Github user bgaff commented on the issue:
https://github.com/apache/trafficserver/pull/693
Agree. If we have N bytes available we should send N bytes immediately, we
should never wait for more than N bytes if only N are available.
---
If your project is set up for it, you can reply t
Github user zwoop commented on the issue:
https://github.com/apache/trafficserver/pull/693
I'm not saying buffering, I'm saying, use as much from what's already
buffered before you send a frame. There's zero reason to send a 9 byte frame,
which could theoretically become TCP packet wi
Github user bgaff commented on the issue:
https://github.com/apache/trafficserver/pull/693
I actually don't think we should do buffering at all. I believe the TCP
implementation should be responsible for determining how the data goes over the
wire.
---
If your project is set up for
Github user masaori335 commented on the issue:
https://github.com/apache/trafficserver/pull/693
Yes, this could increase time to first byte. We should send the first chunk
in anyway.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHu
Github user jpeach commented on the issue:
https://github.com/apache/trafficserver/pull/694
If you need to explicitly dump core from somewhere you can use
``ink_abort``.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If
Github user shinrich commented on the issue:
https://github.com/apache/trafficserver/pull/694
Ok, I see you point. I have no love lost for MachineFatal. This is my
first encounter with it. I'll try replacing it's use in
ProtocolProbeSessionAccept with Fatal and add a ink_release_as
Github user jpeach commented on the issue:
https://github.com/apache/trafficserver/pull/694
But ``Fatal`` doesn't drop a core and it shouldn't so this should behave
the same. I'm all for adding asserts near the root cause but I don't think we
should drop core on managed errors, and re
Github user shinrich commented on the issue:
https://github.com/apache/trafficserver/pull/694
In our most recent fire drill, the core was very useful. The particular
problem only happens under very heavy load. By poking around the core, we got
some idea of the underlying cause and w
Github user jpeach commented on the issue:
https://github.com/apache/trafficserver/pull/694
This somewhat defeats the fix in TS-4441. Rather than making fatal errors
inconsistent, I think it is better to have the place that generates the error
call ``ink_release_assert``.
We
Github user shinrich closed the pull request at:
https://github.com/apache/trafficserver/pull/688
---
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 featur
GitHub user shinrich opened a pull request:
https://github.com/apache/trafficserver/pull/694
TS-4503: Cause MachineFatal to terminate process without attempting mâ¦
â¦emory cleanup.
You can merge this pull request into a Git repository by running:
$ git pull https://github.co
Github user bgaff commented on the issue:
https://github.com/apache/trafficserver/pull/693
This is undesirable for content such as HTML where it's a common pattern
for pages to "early flush" so that clients can begin downloading static
resources earlier (such as js/css/images).
---
Github user masaori335 commented on the issue:
https://github.com/apache/trafficserver/pull/693
## before
```
$ nghttp --no-dep -vn
"https://127.0.0.1:4443/stream-bytes/163840?chunk_size=16284";
...
[ 0.130] recv DATA frame
[ 0.130] recv DATA frame
[ 0.169]
GitHub user masaori335 opened a pull request:
https://github.com/apache/trafficserver/pull/693
TS-4324: Buffer responses to not send small size DATA frames
If body_done flag is not marked and read available size is smaller
than 16KB in Http2ConnectionState::send_a_data_frame(), w
Github user SolidWallOfCode commented on the issue:
https://github.com/apache/trafficserver/pull/679
After some discussion with Jason and looking at other parts of the build
tree, I went with "_aux" because that's the convention the doc subtree uses.
Lacking any better reason to pick
Github user asfgit closed the pull request at:
https://github.com/apache/trafficserver/pull/679
---
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 masaori335 commented on a diff in the pull request:
https://github.com/apache/trafficserver/pull/686#discussion_r65574580
--- Diff: mgmt/api/INKMgmtAPI.cc ---
@@ -1865,8 +1865,7 @@ TSGetErrorMessage(TSMgmtError err_id)
tsapi TSMgmtError
TSEncryptPassword(char *
Github user zwoop commented on the issue:
https://github.com/apache/trafficserver/pull/688
Can we squash this into one commit?
---
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
ena
Github user jpeach commented on a diff in the pull request:
https://github.com/apache/trafficserver/pull/686#discussion_r65573005
--- Diff: mgmt/api/INKMgmtAPI.cc ---
@@ -1865,8 +1865,7 @@ TSGetErrorMessage(TSMgmtError err_id)
tsapi TSMgmtError
TSEncryptPassword(char *pass
Github user SolidWallOfCode commented on the issue:
https://github.com/apache/trafficserver/pull/686
Seems reasonable to me. I checked the history and both of these seem to
have been put in at the same time, although I can't imagine why both were
needed.
---
If your project is set u
Github user shinrich commented on the issue:
https://github.com/apache/trafficserver/pull/688
Pushed a new version. I tested it against the example-plugin. @biilmann
can you verify against the cache write case? I'll squash the commits when
doing the final merge.
---
If your proje
Github user jpeach commented on the issue:
https://github.com/apache/trafficserver/pull/690
Thanks @pbchou. I think we can make this a more complete fix. If you look
at the way ``remap_load_plugin`` works, it it supposed to return non-zero on
error and write the error message to ``err
Github user shinrich commented on a diff in the pull request:
https://github.com/apache/trafficserver/pull/688#discussion_r65564121
--- Diff: proxy/http/HttpSM.cc ---
@@ -2439,8 +2439,12 @@ HttpSM::state_cache_open_write(int event, void *data)
if (ua_session) {
NetVC
Github user jpeach closed the pull request at:
https://github.com/apache/trafficserver/pull/691
---
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 commented on the issue:
https://github.com/apache/trafficserver/pull/691
Thanks @dark264sh
---
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
GitHub user zizhong opened a pull request:
https://github.com/apache/trafficserver/pull/692
[TS-4500] add cookie-rewrite functionality into header-rewrite plugin
add cookie-rewrite functionality into header-rewrite plugin.
There're three cookie handling operators added, incl
GitHub user dark264sh opened a pull request:
https://github.com/apache/trafficserver/pull/691
TS-4499: balancer plugin cannot use over port number over 32767
[TS-4499](https://issues.apache.org/jira/browse/TS-4499?jql=text%20~%20%22balancer%20plugins%22)
You can merge this pull req
36 matches
Mail list logo
