Github user shinrich commented on the issue:
https://github.com/apache/trafficserver/pull/761
One benefit of the existing throttle approach is that there is a single
limit for both inbound and outbound connections. This allows you to create a
last ditch limit if the number
Github user shinrich commented on the issue:
https://github.com/apache/trafficserver/pull/825
Looks good to me as well.
---
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
Github user shinrich commented on a diff in the pull request:
https://github.com/apache/trafficserver/pull/825#discussion_r72122764
--- Diff: proxy/ProxyClientTransaction.h ---
@@ -211,7 +211,11 @@ class ProxyClientTransaction : public VConnection
virtual bool
Github user shinrich commented on the issue:
https://github.com/apache/trafficserver/pull/801
We are running with this change locally. I've made some other changes on
this front too. I'll look at adding some asserts/warning messages to see
whether we are still encountering
Github user shinrich commented on a diff in the pull request:
https://github.com/apache/trafficserver/pull/801#discussion_r72125568
--- Diff: configure.ac ---
@@ -49,7 +49,7 @@ AM_INIT_AUTOMAKE([-Wall -Werror -Wno-portability
tar-ustar foreign no-installinf
AM_MAINTAINER_MODE
Github user shinrich closed the pull request at:
https://github.com/apache/trafficserver/pull/800
---
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 shinrich commented on a diff in the pull request:
https://github.com/apache/trafficserver/pull/766#discussion_r72139223
--- Diff: iocore/net/UnixNetVConnection.cc ---
@@ -1139,8 +1139,8 @@ UnixNetVConnection::mainEvent(int event, Event *e)
(write.vio.mutex
Github user shinrich commented on the issue:
https://github.com/apache/trafficserver/pull/766
Yes, I'll go ahead and merge this up. Might consider backporting.
Stopping the period on the inactivty cop seems like a bad thing.
---
If your project is set up for it, you can reply
Github user shinrich commented on the issue:
https://github.com/apache/trafficserver/pull/846
Yes, we should land it.
---
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
GitHub user shinrich opened a pull request:
https://github.com/apache/trafficserver/pull/853
TS-4619: intermediate chain loading can miss certificates.
Made the changes @jpeach suggested in the bug. Tested with three deep
chains for rsa and ec (cert and two signers). Tested
Github user shinrich commented on a diff in the pull request:
https://github.com/apache/trafficserver/pull/847#discussion_r74317308
--- Diff: proxy/http2/Http2Stream.cc ---
@@ -509,7 +509,7 @@ Http2Stream::update_write_request(IOBufferReader
*buf_reader, int64_t write_len
GitHub user shinrich opened a pull request:
https://github.com/apache/trafficserver/pull/849
TS-4729: Fix dead assignment.
Alternative to PR 847
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/shinrich/trafficserver ts-4729
GitHub user shinrich opened a pull request:
https://github.com/apache/trafficserver/pull/865
TS-2987: Add new TS API TSHttpTxnPluginTagGet
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/shinrich/trafficserver ts-2987
GitHub user shinrich opened a pull request:
https://github.com/apache/trafficserver/pull/866
TS-2237: Fix double encoding of URLs in squid logs.
Resurrecting @sudheerv's fix. We've been running with this fix for over a
year. The logic to lookup the character in the bitfield array
Github user shinrich closed the pull request at:
https://github.com/apache/trafficserver/pull/853
---
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 shinrich commented on the issue:
https://github.com/apache/trafficserver/pull/853
The add1 version increments the reference count of the certificate, The
add0 version doesn't, so it effectively takes ownership of the reference you
pass in. From the man page
&quo
Github user shinrich commented on the issue:
https://github.com/apache/trafficserver/pull/753
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 this feature
enabled
GitHub user shinrich opened a pull request:
https://github.com/apache/trafficserver/pull/856
TS-4749: generate warning message when origin_max_connections limits
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/shinrich
Github user shinrich commented on the issue:
https://github.com/apache/trafficserver/pull/857
Looks good. Having an explicit disable_io_read/write might be nice. But
using NULL's to clear out the current io's does't seem too surprising.
---
If your project is set up for it, you
GitHub user shinrich opened a pull request:
https://github.com/apache/trafficserver/pull/863
TS-4750: Fix Connection Leak warnings.
Removing secondary server address cache in HttpServerSession. Instead pull
that information from netvc. Use the same address to add server sessions
Github user shinrich commented on a diff in the pull request:
https://github.com/apache/trafficserver/pull/801#discussion_r71157128
--- Diff: proxy/ProxyClientSession.cc ---
@@ -142,7 +141,9 @@ ProxyClientSession::do_api_callout(TSHttpHookID id)
this->api_current = N
Github user shinrich commented on the issue:
https://github.com/apache/trafficserver/pull/801
I'm not sure how to interpret your comment. I was seeing IO events
trailing during the SSN close handling. For example, it looks like I could
call the clearing do_io_write
GitHub user shinrich opened a pull request:
https://github.com/apache/trafficserver/pull/810
TS-4671: Allow multicert line with action but no ssl_cert_name
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/shinrich/trafficserver
Github user shinrich commented on the issue:
https://github.com/apache/trafficserver/pull/787
It would be possible to break out the schedule_event clean up and the
state_api_callout into smaller patches. The rest of it really needs to be
together.I need to move onto another
Github user shinrich commented on the issue:
https://github.com/apache/trafficserver/pull/787
Pushed new version of the branch that does not include the schedule_event
and state_api_callout fixes. Filed TS-4663 and TS-4664 to track those issues.
Will try to reproduce those fixes
GitHub user shinrich opened a pull request:
https://github.com/apache/trafficserver/pull/800
TS-4663: ASAN crash. Scheduled event triggers after ClientSession deleted
Track scheduled event and cancel it when client session is deleted if it is
still hanging around.
You can merge
Github user shinrich commented on a diff in the pull request:
https://github.com/apache/trafficserver/pull/766#discussion_r71044678
--- Diff: iocore/net/UnixNetVConnection.cc ---
@@ -1139,8 +1139,8 @@ UnixNetVConnection::mainEvent(int event, Event *e)
(write.vio.mutex
GitHub user shinrich opened a pull request:
https://github.com/apache/trafficserver/pull/801
TS-4664: Fix crash by unifying event handlers for ClientSession.
Combining the handlers for ClientSession so both IO events and plugin
events can be handled.
You can merge this pull
Github user shinrich closed the pull request at:
https://github.com/apache/trafficserver/pull/810
---
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 shinrich closed the pull request at:
https://github.com/apache/trafficserver/pull/787
---
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 shinrich opened a pull request:
https://github.com/apache/trafficserver/pull/842
TS-4717: Http2 stack explosion.
Added a common state_process_frame_read method to loop over reading frames
while there is data available. The original state_start_frame_read
Github user shinrich commented on a diff in the pull request:
https://github.com/apache/trafficserver/pull/831#discussion_r73763348
--- Diff: proxy/logging/LogCollationClientSM.cc ---
@@ -266,6 +266,9 @@ LogCollationClientSM::client_auth(int event, VIO * /*
vio ATS_UNUSED
Github user shinrich commented on the issue:
https://github.com/apache/trafficserver/pull/842
Thanks @maskit. Looking at your debug messages and comparing it to my own,
I realized that I was not running completely up to date with master. Once got
the right version of the code, I
Github user shinrich commented on the issue:
https://github.com/apache/trafficserver/pull/842
Thanks @maskit. I fixed the sense of inside_frame. Had made a name change
and flipped the sense of the bool. Thought I had fixed up the patch, after
testing on my build, but missed
Github user shinrich commented on a diff in the pull request:
https://github.com/apache/trafficserver/pull/842#discussion_r74137828
--- Diff: proxy/http2/Http2ClientSession.h ---
@@ -243,6 +243,12 @@ class Http2ClientSession : public ProxyClientSession
return "h
Github user shinrich commented on the issue:
https://github.com/apache/trafficserver/pull/846
Agreed that the assert doesn't mean much at this point.
current_reader (the HttpSM) may be NULL here or not. If the StateMachine
calls ua_session->release then it will not be n
Github user shinrich closed the pull request at:
https://github.com/apache/trafficserver/pull/842
---
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 shinrich commented on a diff in the pull request:
https://github.com/apache/trafficserver/pull/866#discussion_r74760880
--- Diff: proxy/logging/LogUtils.cc ---
@@ -359,6 +359,23 @@ LogUtils::escapify_url(Arena *arena, char *url, size_t
len_in, int *len_out, cha
Github user shinrich commented on the issue:
https://github.com/apache/trafficserver/pull/866
@maskit, you list some lovely tricky cases. Abort encode on detect seems
like a reasonable approach too. Ideally, we just could declare that nothing
comes in already encoded
Github user shinrich commented on a diff in the pull request:
https://github.com/apache/trafficserver/pull/866#discussion_r74760536
--- Diff: configure.ac ---
@@ -49,7 +49,7 @@ AM_INIT_AUTOMAKE([-Wall -Werror -Wno-portability
tar-ustar foreign no-installinf
AM_MAINTAINER_MODE
Github user shinrich commented on the issue:
https://github.com/apache/trafficserver/pull/866
Reviewing the bug comments Sudheer says "Yes, the external URLs should be
already encoded - however, internally, I see code that decodes the URL strings
(e.g. UrlMatcher::Match
GitHub user shinrich opened an issue:
https://github.com/apache/trafficserver/issues/1360
REGRESSION_TEST(SDK_API_OVERRIDABLE_CONFIGS) sometimes crashes
Due to timing changes in cleaning up sessions and state machines sometimes
REGRESSION_TEST(SDK_API_OVERRIDABLE_CONFIGS) crashes
GitHub user shinrich opened an issue:
https://github.com/apache/trafficserver/issues/1358
Should add server_connect_end to the milestones
We added this milestone entry a while back to help debug a performance
problem. Would like to contribute this back.
---
If your
GitHub user shinrich opened a pull request:
https://github.com/apache/trafficserver/pull/1361
Issue #1358: Add server_connect_end in slow log
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/shinrich/trafficserver issue-1358
GitHub user shinrich opened a pull request:
https://github.com/apache/trafficserver/pull/1365
TS-4896: TSHttp***ClientAddrGet/TSHttp***IncomingAddrGet may return NULL
Several of our plugins would experience crashes once we tightened up clean
up on session shutdown. They assumed
Github user shinrich closed the issue at:
https://github.com/apache/trafficserver/issues/1358
---
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 shinrich opened a pull request:
https://github.com/apache/trafficserver/pull/1364
Issue #1359: Flaw in TS-2157 port in server address may be unset
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/shinrich
Github user shinrich commented on the issue:
https://github.com/apache/trafficserver/issues/1358
Fix commited
---
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 shinrich opened a pull request:
https://github.com/apache/trafficserver/pull/1366
Issue #1360: REGRESSION_TEST(SDK_API_OVERRIDABLE_CONFIGS) crash sometimes
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/shinrich
Github user shinrich commented on the issue:
https://github.com/apache/trafficserver/pull/1364
Would be reasonable to backport. We will be pulling it back into our
version of 7.1
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub
GitHub user shinrich opened an issue:
https://github.com/apache/trafficserver/issues/1359
Flaw in TS-2157 means that port in server address is unset
This is only an issue if the request to origin is a non-standard port.
---
If your project is set up for it, you can
GitHub user shinrich opened a pull request:
https://github.com/apache/trafficserver/pull/1368
Issue #1367: HdrHeap potential corruption
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/shinrich/trafficserver issue-1367
GitHub user shinrich opened an issue:
https://github.com/apache/trafficserver/issues/1369
proxy.config.http.server_max_connections over limit should fail immediately
The way it is currently encoded, requests over the connection limit delay
100ms and try again. This doesn't help ATS
GitHub user shinrich opened an issue:
https://github.com/apache/trafficserver/issues/1367
HdrHeap potential corruption
Would see this sometimes during the host header manipulation. The original
code assumes that the string pointer from the field will stay static over other
header
GitHub user shinrich opened a pull request:
https://github.com/apache/trafficserver/pull/1370
Issue #1369: proxy.config.http.server_max_connections over limit fail
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/shinrich
Github user shinrich commented on the issue:
https://github.com/apache/trafficserver/pull/1375
The client session gets cleaned up as normal after the response is sent.
The problem is the original code was cleaning up the client session via the
kill tunnel before sending the error
Github user shinrich closed the pull request at:
https://github.com/apache/trafficserver/pull/1370
---
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 shinrich closed the pull request at:
https://github.com/apache/trafficserver/pull/1379
---
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 shinrich closed the pull request at:
https://github.com/apache/trafficserver/pull/1375
---
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 shinrich commented on the issue:
https://github.com/apache/trafficserver/pull/1365
Replaced NULL references with nullptr
---
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 shinrich closed the pull request at:
https://github.com/apache/trafficserver/pull/1365
---
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 shinrich closed the pull request at:
https://github.com/apache/trafficserver/pull/1248
---
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 shinrich opened a pull request:
https://github.com/apache/trafficserver/pull/1387
Add diags log message when cache wraps.
Requested by our operations guys to better track wraps.
You can merge this pull request into a Git repository by running:
$ git pull https
Github user shinrich closed the pull request at:
https://github.com/apache/trafficserver/pull/1368
---
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 shinrich commented on the issue:
https://github.com/apache/trafficserver/pull/1370
Ok. Still figuring out the new world order :-)
---
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
Github user shinrich commented on the issue:
https://github.com/apache/trafficserver/pull/1366
Probably. We will be pulling this back into our 7.1
---
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
Github user shinrich closed the pull request at:
https://github.com/apache/trafficserver/pull/1366
---
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 shinrich commented on the issue:
https://github.com/apache/trafficserver/issues/1367
Hopefully this fixes what you saw @maskit. Looking at the discussion on
TS-2792 had it been solved before?
---
If your project is set up for it, you can reply to this email and have
GitHub user shinrich opened a pull request:
https://github.com/apache/trafficserver/pull/1379
Make sure to schedule connect event on correct thread type.
Cannot blindly schedule on current thread. It may not be the right type.
You can merge this pull request into a Git repository
Github user shinrich closed the pull request at:
https://github.com/apache/trafficserver/pull/1376
---
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 shinrich opened a pull request:
https://github.com/apache/trafficserver/pull/1376
TSStringPercentDecode null-termination clipping on overflow.
Actually fixed by @petar last summer, but forgot to get it pushed to up.
Long URL's would cause buffer overflow write
GitHub user shinrich opened a pull request:
https://github.com/apache/trafficserver/pull/1375
Incorrectly freeing Http1ClientSession setting up to return a error
Saw a very deep stack. The following is the stop of the stack.
{code}
#0 0x in ?? ()
#1
Github user shinrich commented on a diff in the pull request:
https://github.com/apache/trafficserver/pull/1370#discussion_r97871781
--- Diff: proxy/http/HttpSM.cc ---
@@ -4933,8 +4933,10 @@ HttpSM::do_http_server_open(bool raw)
// between the statement above and the check
Github user shinrich commented on the issue:
https://github.com/apache/trafficserver/pull/1370
Addressed Alan's comment.
---
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
Github user shinrich commented on the issue:
https://github.com/apache/trafficserver/issues/1421
Related discussion on issue #1401. I have a hacky PR related to that
issue, which has enabled us to continue on. It is definitely triggered by the
error bubbling changes. I didn't pin
GitHub user shinrich opened an issue:
https://github.com/apache/trafficserver/issues/1480
Crash in Http1ClientSession::set_inactivity_timeout
While testing 7.1, we see the following crash and stack track
```
#0 0x in ?? ()
#1 0x005d6794
Github user shinrich commented on the issue:
https://github.com/apache/trafficserver/issues/1459
Found this was an issue in the changes made in our version of 7.1 shown in
PR #1446. I will update the PR with the fix. As it stands, if there is no
servername hook, the cert hook
Github user shinrich commented on a diff in the pull request:
https://github.com/apache/trafficserver/pull/1488#discussion_r103023456
--- Diff: iocore/net/SSLUtils.cc ---
@@ -2007,7 +2007,10 @@ SSLParseCertificateConfiguration(const
SSLConfigParams *params, SSLCertLookup *l
GitHub user shinrich opened an issue:
https://github.com/apache/trafficserver/issues/1476
Crash in get_client_addr()
After working through issues #1401 and #1443, we now see the following
crash in our copy of 7.1. The crash occurs once every couple hours.
```
#0
Github user shinrich commented on the issue:
https://github.com/apache/trafficserver/issues/1369
Change committed.
---
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
Github user shinrich closed the issue at:
https://github.com/apache/trafficserver/issues/1369
---
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 shinrich commented on the issue:
https://github.com/apache/trafficserver/pull/1446
Updated PR to address issue #1459
---
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 shinrich commented on the issue:
https://github.com/apache/trafficserver/issues/1401
I've finally got my environment running and I see the same stack very
quickly as well. In the cases I've seen it looks like there was a write error,
but for some reason the write vio has
Github user shinrich commented on the issue:
https://github.com/apache/trafficserver/issues/1401
@PSUdaemon would be cool to see symbols with the stack to verify that is
the same thing. My hacky fix made it go away only to be immediately replaced
by a new crash. (New issue
Github user shinrich commented on the issue:
https://github.com/apache/trafficserver/issues/1401
BTW I'm currently testing without HTTP/2.
---
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 shinrich opened an issue:
https://github.com/apache/trafficserver/issues/1443
Assert on null t_state.transact_return_point
Seeing this crash now after putting in work around for issue #1401.
```
#0 0x2b20159b7625 in raise () from /lib64/libc.so.6
#1
Github user shinrich commented on the issue:
https://github.com/apache/trafficserver/issues/1443
Tracked it down some more. In this case, new remap rule is not found, and
build_error_response is called to set the status of 404 with the reason of "Not
Found". B
GitHub user shinrich opened a pull request:
https://github.com/apache/trafficserver/pull/1444
issue #1401: Potential fix to the write_to_io_net crash.
Not a super satisfying solution. Without this change, ats 7.1 would crash
immediately in our production environment
GitHub user shinrich opened a pull request:
https://github.com/apache/trafficserver/pull/1445
Issue #1443 - Fix early or duplicate 404 error handling
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/shinrich/trafficserver
GitHub user shinrich opened a pull request:
https://github.com/apache/trafficserver/pull/1446
Need dedicated TS_SSL_SERVERNAME_HOOK
If you have a plugin that needs to trigger on every TLS client hello, this
won't
work the TS_SSL_SNI_HOOK with openssl-1.0.2. In that version
Github user shinrich commented on the issue:
https://github.com/apache/trafficserver/pull/1445
An assert triggers. A stack trace in the issue description.
https://github.com/apache/trafficserver/issues/1443
---
If your project is set up for it, you can reply to this email
Github user shinrich commented on the issue:
https://github.com/apache/trafficserver/pull/1444
Yes, as I said not an entirely satisfying solution. I do thing the issue
is triggered by the changes from TS-4796 where @jacksontj added logic to bubble
up these errors. I'm guessing
GitHub user shinrich opened an issue:
https://github.com/apache/trafficserver/issues/1459
Mysterious uptick in user_agent SSL errors moving to 7.1
Comparing a machine running 7.1.x against its peer running our version of
5.3.x. A number of the proxy.process.ssl.user_agent_
GitHub user shinrich opened an issue:
https://github.com/apache/trafficserver/issues/1452
ssl_callback_ocsp_stapling spew of messages in diags.log on start
On system start with 7.1, I see lots of the following messages in diags.log
for a few minutes. It eventually stops
Github user shinrich closed the pull request at:
https://github.com/apache/trafficserver/pull/1347
---
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 shinrich commented on the issue:
https://github.com/apache/trafficserver/pull/1347
Looks good to me. Explicitly checking that both the path and file name are
NULL should avoid bogus load attempts. Still odd that relative layout logic
uses getcwd if the path is NULL
GitHub user shinrich opened a pull request:
https://github.com/apache/trafficserver/pull/881
TS-4766: HTTP/2 frame corruption fix.
Moved handler reset into the do_complete_frame_read worker.
You can merge this pull request into a Git repository by running:
$ git pull https
Github user shinrich closed the pull request at:
https://github.com/apache/trafficserver/pull/881
---
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 shinrich commented on the issue:
https://github.com/apache/trafficserver/pull/863
@oknet True there are many variants of the get_remote_* get_remote_ip
should be going away since it is IPv4 (looks like only two references remain).
For get_remote_endpoint
Github user shinrich commented on the issue:
https://github.com/apache/trafficserver/pull/849
Addressed @bryancall 's concerns with a new commit (squashed).
---
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
1 - 100 of 343 matches
Mail list logo
