[GitHub] trafficserver issue #1515: Logging cache code map size fix
Github user gtenev commented on the issue: https://github.com/apache/trafficserver/pull/1515 @jpeach: sounds like right thing to do, needed a quick fix, will find some time to make the API less error-prone. @zwoop: sir, yes, sir! --- 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 is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] trafficserver pull request #1515: Logging cache code map size fix
GitHub user gtenev opened a pull request: https://github.com/apache/trafficserver/pull/1515 Logging cache code map size fix The size of the cache code map does not correspond to the number of cache result code values. Discrepancy introduced with commit eadc9cfa4020799859c4c65be6608990b6f0fe80 You can merge this pull request into a Git repository by running: $ git pull https://github.com/gtenev/trafficserver logging_crc_size_fix Alternatively you can review and apply these changes as the patch at: https://github.com/apache/trafficserver/pull/1515.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #1515 --- 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 is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] trafficserver issue #1441: Mark the new span metrics as gauges in Epic plugi...
Github user gtenev commented on the issue: https://github.com/apache/trafficserver/pull/1441 ð looks good --- 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 is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] trafficserver issue #1246: TS-5069: Fixes CID 1366771 and 1366771
Github user gtenev commented on the issue: https://github.com/apache/trafficserver/pull/1246 ð looks good --- 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 is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] trafficserver issue #1239: TS-5069 enhance logstats to report stats per user
Github user gtenev commented on the issue: https://github.com/apache/trafficserver/pull/1239 @zwoop no problems, should be good now --- 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 is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] trafficserver pull request #1239: TS-5069 enhance logstats to report stats p...
GitHub user gtenev opened a pull request: https://github.com/apache/trafficserver/pull/1239 TS-5069 enhance logstats to report stats per user Enhanced `traffic_logstats` to aggregate and report stats per user instead of per host. You can merge this pull request into a Git repository by running: $ git pull https://github.com/gtenev/trafficserver TS-5069 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/trafficserver/pull/1239.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #1239 commit b6b660ef1589e9c78e5f3121986205b3c75850a4 Author: Gancho Tenev <gtte...@gmail.com> Date: 2016-11-30T05:55:21Z TS-5069 enhance logstats to report stats per user --- 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 is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] trafficserver issue #1238: TS-4429: Adds a --concise (-C) option for logstat...
Github user gtenev commented on the issue: https://github.com/apache/trafficserver/pull/1238 ð looks reasonable to me, it would reduce the amount of data to transfer/store without post-processing of the `traffic_logstats` output --- 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 is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] trafficserver pull request #1173: TS-4706 Truncated SNI name during escalati...
GitHub user gtenev opened a pull request: https://github.com/apache/trafficserver/pull/1173 TS-4706 Truncated SNI name during escalation SSL hostname verification failing due to truncated SNI name. (cherry picked from commit 4d02d0e877e24b1dc94948c236462417bdd9bbf0) You can merge this pull request into a Git repository by running: $ git pull https://github.com/gtenev/trafficserver TS-4706_backport Alternatively you can review and apply these changes as the patch at: https://github.com/apache/trafficserver/pull/1173.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #1173 --- 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 is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] trafficserver pull request #1172: TS-4650: cachekey: not thread safe
GitHub user gtenev opened a pull request: https://github.com/apache/trafficserver/pull/1172 TS-4650: cachekey: not thread safe (cherry picked from commit f4a97a9d573867441c5dd711b54ff66117fcd057) (cherry picked from commit 15b2ab08a30a0df8c2223e05c7bfc4cb530ea243) You can merge this pull request into a Git repository by running: $ git pull https://github.com/gtenev/trafficserver TS-4650_backport Alternatively you can review and apply these changes as the patch at: https://github.com/apache/trafficserver/pull/1172.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #1172 commit ec577b957b75a2a0e1e481d47f2e3f5988c21f1e Author: Felicity Tarnell <f...@le-fay.org> Date: 2016-07-12T15:28:44Z TS-4650: cachekey: not thread safe (cherry picked from commit f4a97a9d573867441c5dd711b54ff66117fcd057) (cherry picked from commit 15b2ab08a30a0df8c2223e05c7bfc4cb530ea243) --- 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 is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] trafficserver issue #996: TS-4834 Expose bad disk and disk access failures
Github user gtenev commented on the issue: https://github.com/apache/trafficserver/pull/996 @zwoop, it is ready to land now. --- 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 is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] trafficserver issue #996: TS-4834 Expose bad disk and disk access failures
Github user gtenev commented on the issue: https://github.com/apache/trafficserver/pull/996 @jpeach added docs, @SolidWallOfCode made the requested change. --- 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 is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] trafficserver issue #996: TS-4834 Expose bad disk and disk access failures
Github user gtenev commented on the issue: https://github.com/apache/trafficserver/pull/996 @zwoop, I have not heard any objections for a while so unless @jpeach and @SolidWallOfCode have any concerns with the latest patch I think we can 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 and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] trafficserver pull request #1157: TS-4916 Add safety net to avoid H2-infinit...
GitHub user gtenev opened a pull request: https://github.com/apache/trafficserver/pull/1157 TS-4916 Add safety net to avoid H2-infinite-loop deadlock. Current Http2ConnectionState implementation uses a memory pool for instantiating streams and DLL<> stream_list for storing active streams. Destroying a stream before deleting it from stream_list and then creating a new one + reusing the same chunk from the memory pool right away always leads to destroying the DLL structure (deadlocks, inconsistencies). Added a safety net since the consequences are disastrous. Until the design/implementation changes it seems less error prone to (double) delete before destroying (noop if already deleted). (cherry picked from commit a6f9337f61c980739e08bbefeb5f6409b7dcdac1) Conflicts: proxy/http2/Http2ConnectionState.cc You can merge this pull request into a Git repository by running: $ git pull https://github.com/gtenev/trafficserver h2_loop Alternatively you can review and apply these changes as the patch at: https://github.com/apache/trafficserver/pull/1157.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #1157 commit 8b3d67d8f3bdb7e837c766e57ae75286f1eb01a3 Author: Gancho Tenev <gtte...@gmail.com> Date: 2016-10-17T22:10:12Z TS-4916 Add safety net to avoid H2-infinite-loop deadlock. Current Http2ConnectionState implementation uses a memory pool for instantiating streams and DLL<> stream_list for storing active streams. Destroying a stream before deleting it from stream_list and then creating a new one + reusing the same chunk from the memory pool right away always leads to destroying the DLL structure (deadlocks, inconsistencies). Added a safety net since the consequences are disastrous. Until the design/implementation changes it seems less error prone to (double) delete before destroying (noop if already deleted). (cherry picked from commit a6f9337f61c980739e08bbefeb5f6409b7dcdac1) Conflicts: proxy/http2/Http2ConnectionState.cc --- 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 is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] trafficserver issue #1100: TS-4916: Fix for an H2-infinite-loop deadlock
Github user gtenev commented on the issue: https://github.com/apache/trafficserver/pull/1100 Chatted with @shinrich offline and she is going to mark related fixes TS-4813 and TS-4507 for backport from 7.0.0 to 6.2.1, which should take care of the "missing to delete the stream cases". Submitted a new PR against master #1117 to add the "safety net" delete stream call in `destroy()` before `THREAD_FREE()` and backport to 6.2.1 (changes are not 6.2.1 specific anymore). --- 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 is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] trafficserver pull request #1100: TS-4916: Fix for an H2-infinite-loop deadl...
Github user gtenev closed the pull request at: https://github.com/apache/trafficserver/pull/1100 --- 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 is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] trafficserver pull request #1117: TS-4916 Add safety net to avoid H2-infinit...
GitHub user gtenev opened a pull request: https://github.com/apache/trafficserver/pull/1117 TS-4916 Add safety net to avoid H2-infinite-loop deadlock. Current Http2ConnectionState implementation uses a memory pool for instantiating streams and DLL<> stream_list for storing active streams. Destroying a stream before deleting it from stream_list and then creating a new one + reusing the same chunk from the memory pool right away always leads to destroying the DLL structure (deadlocks, inconsistencies). Added a safety net since the consequences are disastrous. Until the design/implementation changes it seems less error prone to (double) delete before destroying (noop if already deleted). You can merge this pull request into a Git repository by running: $ git pull https://github.com/gtenev/trafficserver TS-4916-master Alternatively you can review and apply these changes as the patch at: https://github.com/apache/trafficserver/pull/1117.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #1117 commit ed72728800fb3a5387172644b1cc586b74c4f0a0 Author: Gancho Tenev <gtte...@gmail.com> Date: 2016-10-17T22:10:12Z TS-4916 Add safety net to avoid H2-infinite-loop deadlock. Current Http2ConnectionState implementation uses a memory pool for instantiating streams and DLL<> stream_list for storing active streams. Destroying a stream before deleting it from stream_list and then creating a new one + reusing the same chunk from the memory pool right away always leads to destroying the DLL structure (deadlocks, inconsistencies). Added a safety net since the consequences are disastrous. Until the design/implementation changes it seems less error prone to (double) delete before destroying (noop if already deleted). --- 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 is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] trafficserver issue #1100: TS-4916: Fix for an H2-infinite-loop deadlock
Github user gtenev commented on the issue: https://github.com/apache/trafficserver/pull/1100 I was actually thinking to propose just adding a âcatch-all-delete-streamâ call in `destroy()` before `THREAD_FREE()` in 7.0. It seems to me that the point of this Jira TS-4813 / this PR got somehow lost so I would like to reiterate. Missing a stream deletion from `DLL<>` before calling `THREAD_FREE()` COULD lead to breaking the `DLL<>` and then if that happens `DLL<>` traversals ALWAYS ends up in infinite loop. Host became dysfunctional pretty often because of this (time to live 1-3 days per host) and it took long time to debug/prove. This is my (practical?) attempt to make sure we donât get stuck in this debugging again regardless of past/current/future âdelete streamâ bugs (as long us we use `THREAD_ALLOC_INIT/THREAD_FREE` + `DLL<>` of course). I wanted to propose a "catch-all-delete-stream" safety net in both 6.2.1 and 7.0.0 because I think it would be hard to guarantee that the next commit would not introduce this weakness again. This is my first read of the H2 code so I can see how the proposed fix can be sub-optimal and will gladly change it, I also hope I provided enough reasoning for best results :). I am pretty confident in my debugging data/conclusions but just by reading the code or by sorting through Jiras that âmay helpâ I can only guess if the new 7.0 version or back-ports to 6.2.1 definitely fix the issue until I test/verify. We could close this PR: - If we are confident all âfixes in this areaâ from 7.0 can be back-ported to 6.2.1 and that the issue will be fixed - AND If adding the proposed safety net does not make any/enough sense Cheers! --- 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 is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] trafficserver pull request #1100: TS-4916: Fix for an H2-infinite-loop deadl...
Github user gtenev commented on a diff in the pull request: https://github.com/apache/trafficserver/pull/1100#discussion_r83512075 --- Diff: proxy/http2/Http2Stream.cc --- @@ -267,10 +267,12 @@ Http2Stream::do_io_close(int /* flags */) // Make sure any trailing end of stream frames are sent // Ourselve will be removed at send_data_frames or closing connection phase static_cast(parent)->connection_state.send_data_frames(this); + + // Make sure the stream is deleted at this point since next step is self destroy. + this->delete_stream(); --- End diff -- This is what actually made sure we delete the stream from the `DLL<>` before triggering `destroy()` (before leaving `do_io_close()`). In the version 6.2.1 we have `send_data_frames()` delete the stream from `DLL<>` on `HTTP2_STREAM_STATE_CLOSED`. Then in a later version we added `HTTP2_STREAM_STATE_HALF_CLOSED_LOCAL`. What caused the destroying of `DLL<>` in our case was `HTTP2_STREAM_STATE_HALF_CLOSED_REMOTE` (which does not cause deletion in any version). It seemed to me we have been always vulnerable to this problem despite the fixes. That is why I thought I would add this âcatch-all-delete-streamâ line here for all the current and future missing states. After this point we are going to `destroy()` the stream regardless of its state anyway. --- 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 is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] trafficserver pull request #1100: TS-4916: Fix for an H2-infinite-loop deadl...
Github user gtenev commented on a diff in the pull request:
https://github.com/apache/trafficserver/pull/1100#discussion_r83511226
--- Diff: proxy/http2/Http2ConnectionState.cc ---
@@ -1097,6 +1141,7 @@ void
Http2ConnectionState::send_data_frames(Http2Stream *stream)
{
if (stream->get_state() == HTTP2_STREAM_STATE_CLOSED) {
+this->delete_stream(stream);
return;
--- End diff --
No, I may have overdone it here.
I thought I would add this deletion because few lines below there is
deleting if state == `HTTP2_STREAM_STATE_CLOSED`. `send_data_frames()` is
called not only from `do_io_close()`, and calling `delete_stream()` on already
deleted stream is OK (with this change).
---
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 is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] trafficserver pull request #1100: TS-4916: Fix for an H2-infinite-loop deadl...
Github user gtenev commented on a diff in the pull request:
https://github.com/apache/trafficserver/pull/1100#discussion_r83510837
--- Diff: proxy/http2/Http2ConnectionState.cc ---
@@ -936,30 +940,70 @@ Http2ConnectionState::cleanup_streams()
void
Http2ConnectionState::delete_stream(Http2Stream *stream)
{
+ // The following check allows the method to be called safely on already
deleted streams.
+ if (deleted_from_active_streams(stream)) {
+return;
+ }
+
+ SCOPED_MUTEX_LOCK(lock, this->mutex, this_ethread());
+
--- End diff --
If we are sure `DLL<>` is always protected by a lock then I must have
really misunderstood this previous [comment on
TS-4916](https://issues.apache.org/jira/browse/TS-4916?focusedCommentId=15552505=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15552505])
where we suspected `DLL<>` to be âmanipulated by simultaneous threadsâ.
That would mean that at least in one thread was not holding the right lock.
In that case would not that mean that ârearranging some of the stream_count
book keepingâ would rather hide the problem than to fix it?
Trying to help based on the comment decided to trace few paths in the
source code that may not be holding ConnectionState lock (theoretically) and
grabbed the lock on the common path closest to the structures that needed
protection (which based on my understanding should not be a problem if the
thread is already holding the lock).
Actually never noticed the race condition in my debugging so I am going to
remove this line from the PR and I will consider limiting my future changes to
the issue I am trying to fix.
---
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 is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] trafficserver pull request #1100: TS-4916: Fix for an H2-infinite-loop deadl...
Github user gtenev commented on a diff in the pull request:
https://github.com/apache/trafficserver/pull/1100#discussion_r83508421
--- Diff: proxy/http2/Http2ConnectionState.cc ---
@@ -936,30 +940,70 @@ Http2ConnectionState::cleanup_streams()
void
Http2ConnectionState::delete_stream(Http2Stream *stream)
{
+ // The following check allows the method to be called safely on already
deleted streams.
+ if (deleted_from_active_streams(stream)) {
+return;
+ }
+
--- End diff --
OK, needed that for calling `delete_stream()` on already deleted streams
for my âcatch-all-delete-streamâ calls (6.2.1).
Also grouped some of the `DLL<>` + `client_streams_count` updates in
separate functions.
Looking at how the master changed since I started working on this I may
need to revert that to be consistent with master.
---
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 is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] trafficserver pull request #1100: TS-4916: Fix for an H2-infinite-loop deadl...
Github user gtenev commented on a diff in the pull request: https://github.com/apache/trafficserver/pull/1100#discussion_r83279595 --- Diff: iocore/aio/.diags.log.meta --- @@ -0,0 +1 @@ +creation_time = 1476307057 --- End diff -- removed, committed by mistake --- 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 is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] trafficserver pull request #1100: TS-4916: Fix for an H2-infinite-loop deadl...
GitHub user gtenev opened a pull request: https://github.com/apache/trafficserver/pull/1100 TS-4916: Fix for an H2-infinite-loop deadlock This is a fix to prevent destroying of the DLL<> structure and the following iteration over Http2ConnectionState::stream_list to fall into an infinite loop while holding a lock, which leads to cache updates to start failing. You can merge this pull request into a Git repository by running: $ git pull https://github.com/gtenev/trafficserver TS-4916 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/trafficserver/pull/1100.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #1100 commit e84978a18f0d856adfea744a5ab11668e1fc Author: Gancho Tenev <gtte...@gmail.com> Date: 2016-10-11T23:05:14Z TS-4916 Fix for a H2-infinite-loop deadlock. --- 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 is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] trafficserver pull request #1099: TS-4916: Fix for an H2-infinite-loop deadl...
Github user gtenev closed the pull request at: https://github.com/apache/trafficserver/pull/1099 --- 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 is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] trafficserver issue #1099: TS-4916: Fix for an H2-infinite-loop deadlock
Github user gtenev commented on the issue: https://github.com/apache/trafficserver/pull/1099 @zwoop I did, my fork looks OK. it seems to me that later in the github GUI I may have submitted the PR against base:master (which was the default), should have been against 6.2.x. Closing. --- 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 is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] trafficserver pull request #1099: TS-4916: Fix for an H2-infinite-loop deadl...
GitHub user gtenev opened a pull request:
https://github.com/apache/trafficserver/pull/1099
TS-4916: Fix for an H2-infinite-loop deadlock
This is a fix to prevent destroying of the ``DLL<>`` structure and the
following iteration over ``Http2ConnectionState::stream_list`` to fall into an
infinite loop while holding a lock, which leads to cache updates to start
failing.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gtenev/trafficserver TS-4916
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/trafficserver/pull/1099.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #1099
commit d9b5237255ab86d9013a29562db6b839122cec23
Author: Phil Sorber <sor...@apache.org>
Date: 2016-04-18T04:58:51Z
Mark proxy.config.ssl.SSLv2 and proxy.config.ssl.SSLv3 as deprecated in the
docs.
commit bad058eb152772f1df0fe4c133f4ac62fa0eaa12
Author: Leif Hedstrom <zw...@apache.org>
Date: 2016-04-04T21:06:47Z
TS-4318 Fix a regression in regex rules
The refactoring done earlier broke the config loading of rules using
the regular expressions. This restore that functionality, but cleaner.
(cherry picked from commit 431a8f838e75338cb685b95c213a6140f5cbdcc7)
commit 8261836994bc74fd3f1a078c976082e91b4bc976
Author: Meera Mosale Nataraja <mech...@gmail.com>
Date: 2016-04-18T19:51:03Z
TS-4147 Allow gzip plugin to be a remap plugin
(cherry picked from commit 3d7cdbfa1dc52e81c2698dfbac526dec1d336246)
commit 12084df688483d939654dd53d3c82e5f3cc9
Author: Masaori Koshiba <masa...@apache.org>
Date: 2016-04-18T06:16:56Z
TS-4361: Remove TS_FETCH_EVENT handlers from Http2ClientSession. This
closes #581.
(cherry picked from commit 3872a385cac3d43de25bdaf38c56bbcc2cb6f65b)
commit 377ffdc65978dd10344dd4a3bcef0677f8263a4e
Author: shinrich <shinr...@yahoo-inc.com>
Date: 2016-04-19T14:40:20Z
TS-4364: Address remnants from HTTP/2 refactoring. This closes #584.
(cherry picked from commit 2a1c3996d1641bd246faf39a171b330ac33da34c)
commit 556a0f9717eb10cdd20d8659bc605bdb10c27ad0
Author: shinrich <shinr...@yahoo-inc.com>
Date: 2016-04-18T15:15:16Z
TS-3429: Fix reference counting for TSContScheduleEvery. This closes #576.
(cherry picked from commit 3286600d90be4b6291b35867720adbd864f580ea)
commit 7bf73303bf325b83492c43b58d9241e20a71c475
Author: Masaori Koshiba <masa...@apache.org>
Date: 2016-04-25T02:12:17Z
TS-4355: Change assert condition for TS-3612
Originally, the condition of assert in HttpTunnel::main_handler(int event,
void *data)
was same to the condition in HttpTunnel::get_consumer(VIO *vio) before
TS-3612.
This commit makes the condition in HttpTunnel::main_handler(int event, void
*data)
same as condition in HttpTunnel::get_consumer(VIO *vio).
(cherry picked from commit 37f7c05de574458d2eff781d9f047673cda97a4e)
commit c754bc35de1ce5d5984990ab07f5ef8588743615
Author: shinrich <shinr...@yahoo-inc.com>
Date: 2016-04-26T20:33:10Z
TS-4378: Remove periodic warning.
(cherry picked from commit 13a20c199803aae734b634da425340c72cf10b26)
commit af91bf80d8a6ca1a85056c1ff960f8848b7dfac3
Author: Thomas Jackson <jacksontj...@gmail.com>
Date: 2016-05-02T15:34:05Z
TS-4403: Fix stale-while-revalidate on DNS lookup failures (#609)
HostDB's "stale-while-revalidate" feature allows hostdb to return stale
records while doing the DNS lookup in the background. This works properly in
the case where the resolver goes away, but in the case that an error was
returned from the resolver the record in cache was thrown away. This means that
a transient error out in the DNS infrastructure would cause ATS to drop its
stale record it would have contently served-- this patch simply makes hostdb
honor its stale-while-revalidate contract (if configured). So, in the event
that the DNS result comes back as `failed` hostdb will keep the old one if it
is okay with being served stale.
This closes #609
(cherry picked from commit 131875cbe7b0975c8c3c4f3d20aa55a5c7caba86)
commit b5317c9ee8812f6be65c0b7f215393e62fb6fe2e
Author: Felix BuÌnemann <buenem...@louis.info>
Date: 2016-04-30T06:09:24Z
TS-4397: Fix build on i386 caused by type mismatch
It seems lua_Integer is 32-Bit on i386 while it's 54-Bit on x86-64
causing the existing code to fail with:
metrics.cc: In function âbool
metrics_binding_initialize(BindingInstance&)â:
metrics.cc:339:58: error: call of overloaded âbind_constant(const char
[20], int64_t)â is ambiguous
binding.bind_constant("metrics.update.pass", int64_t(0));
This closes
[GitHub] trafficserver issue #1028: TS-4870 Avoid marking storage offline multiple ti...
Github user gtenev commented on the issue: https://github.com/apache/trafficserver/pull/1028 @jpeach, renamed "offline" flag to "online", added some reasoning about why the flag was necessary in the last commit description. --- 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 is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] trafficserver pull request #1028: TS-4870 Avoid marking storage offline mult...
Github user gtenev commented on a diff in the pull request:
https://github.com/apache/trafficserver/pull/1028#discussion_r79487888
--- Diff: iocore/cache/Cache.cc ---
@@ -2000,6 +2000,12 @@ CacheProcessor::mark_storage_offline(CacheDisk *d
///< Target disk
uint64_t total_dir_delete = 0;
uint64_t used_dir_delete= 0;
+ /* Don't mark it again, it will invalidate the stats! */
+ if (d->offline) {
+return this->has_online_storage();
+ }
+ d->offline = true;
--- End diff --
@jpeach, great! sure, I can rename the flag to "online" :)
---
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 is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] trafficserver issue #1028: TS-4870 Avoid marking storage offline multiple ti...
Github user gtenev commented on the issue:
https://github.com/apache/trafficserver/pull/1028
@jpeach, appreciate your feedback!
It felt that "disk being offline" (might be an operator's decision) and
"disk being bad" (number of IO errors reached a threshold) are better kept
separate in general.
IMHO using `CacheDisk::num_errors` to mark the disk offline could be error
prone and here is an example.
Let us say ``proxy.config.cache.max_disk_errors=5`` and a disk keeps
failing causing ``handle_disk_failure()`` to be called and at some point
``CacheDisk::num_errors`` becomes ``5`` which causes
``mark_storage_offline()`` to be called.
At this point since ``CacheDisk::num_errors=5`` then ``true==DISK_BAD(d)``.
It seems that if I did ``if(!DISK_BAD(d)) {...}`` (as suggested above) it
would not execute the code in ``mark_storage_offline()`` at all, for instance
``proxy.process.cache.bytes_total_stat`` would not get updated as it should.
This is one of my first adventures in the "cache"component so I hope I am
not missing something, please let me know what you think and will gladly
look/test/change as necessary.
---
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 is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] trafficserver issue #996: TS-4834 Expose bad disk and disk access failures
Github user gtenev commented on the issue: https://github.com/apache/trafficserver/pull/996 @jpeach and @SolidWallOfCode, really appreciate your feedback! Here is the new patch. Removed `_count`. The reason I added was that internally the "bad disk metric" and "disk errors" both had counter semantics and there are already metrics containing `_count`. Renamed `disk` to `span`, this seems more accurate indeed. I like the idea of exposing "online", "offline", etc. The new patch exposes the following metrics as gauges: ``` proxy.process.cache.span.failing proxy.process.cache.span.offline proxy.process.cache.span.online ``` A span "moves" from "online" bucket (`errors==0`) to "failing" (`errors > 0 && errors < proxy.config.cache.max_disk_errors`) to "offline" (`errors >= proxy.config.cache.max_disk_errors`). Please note that "failing" + "offline" + "online" = total number of spans. It was possible to split the read and write metrics so removed `proxy.process.cache.disk.errors` in favor of ``` proxy.process.cache.span.errors.read proxy.process.cache.span.errors.write ``` Removed the "per-volume" stats. @SolidWallOfCode, incrementing the metrics for all volumes on each failure does not make sense either. I would need to add more code to be able to increment the metrics for the right volume and I am not sure it is worth the effort (and maintenance). I think the idea of this change in general is to give the operator a signal that the disks need to be inspected and then the operator would diagnose them with more sophisticated lower level disk utilities. Noticed that the metrics would not get updated properly (would get somehow inconsistent) if there were failures during the cache initialization (before "cache enabled") and tried to fix wherever noticed and able to test / reproduce. --- 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 is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] trafficserver pull request #1028: TS-4870 Avoid marking storage offline mult...
Github user gtenev commented on a diff in the pull request:
https://github.com/apache/trafficserver/pull/1028#discussion_r79075679
--- Diff: iocore/cache/P_CacheDisk.h ---
@@ -97,6 +97,7 @@ struct CacheDisk : public Continuation {
int num_errors;
int cleared;
bool read_only_p;
+ bool offline; /* flag marking cache disk offline (because of too many
failures or by the operator). */
--- End diff --
This is another review tests (per jpeach's request). "Start a review"
---
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 is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] trafficserver pull request #1028: TS-4870 Avoid marking storage offline mult...
Github user gtenev commented on a diff in the pull request:
https://github.com/apache/trafficserver/pull/1028#discussion_r79075616
--- Diff: iocore/cache/P_CacheDisk.h ---
@@ -97,6 +97,7 @@ struct CacheDisk : public Continuation {
int num_errors;
int cleared;
bool read_only_p;
+ bool offline; /* flag marking cache disk offline (because of too many
failures or by the operator). */
--- End diff --
This is another review tests (per jpeach's request). "Add single 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 and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] trafficserver issue #1022: TS-4868: Add configs back and cleanup other clust...
Github user gtenev commented on the issue: https://github.com/apache/trafficserver/pull/1022 I have not looked enough to say if this change is necessary or not but just wanted to mention that it helped me with a crash I got after syncing my fork. ``` Starting program: /opt/apache/trafficserver/bin/traffic_manager [Thread debugging using libthread_db enabled] [E. Mgmt] log ==> [TrafficManager] using root directory '/opt/apache/trafficserver' [New Thread 0x7709b700 (LWP 24130)] [New Thread 0x7fffee69a700 (LWP 24131)] Program received signal SIGSEGV, Segmentation fault. inet_network (cp=0x0) at inet_net.c:55 55 if (*cp == '0') Missing separate debuginfos, use: debuginfo-install libunwind-1.1-3.el6.x86_64 tcl-8.5.7-6.el6.x86_64 (gdb) where #0 inet_network (cp=0x0) at inet_net.c:55 #1 0x00430273 in main (argc=, argv=) at traffic_manager.cc:668 ``` Applying the patch seemed to fix the problem for 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 and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] trafficserver pull request #1028: TS-4870 Avoid marking storage offline mult...
GitHub user gtenev opened a pull request: https://github.com/apache/trafficserver/pull/1028 TS-4870 Avoid marking storage offline multiple times Currently storage can be marked offline multiple times which breaks related metrics. You can merge this pull request into a Git repository by running: $ git pull https://github.com/gtenev/trafficserver TS-4870 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/trafficserver/pull/1028.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #1028 commit b1389f36936bbfcee6ee645e9954eeae92d4e7ed Author: Gancho Tenev <gtte...@gmail.com> Date: 2016-09-15T13:44:44Z TS-4870 Avoid marking storage offline multiple times Currently storage can be marked offline multiple times which breaks related metrics. --- 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 is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] trafficserver issue #956: TS-4806: Fix up event processor thread stacks
Github user gtenev commented on the issue:
https://github.com/apache/trafficserver/pull/956
@PSUdaemon, the patch looks good, +1 on fixing the sleep(1).
Built and run it in production with ``exec_thread.affinity: 1`` and it run
fine.
Here some of the things I checked.
``numastat`` output looked pretty much the same like before the patch was
applied
```
$ sudo numastat -p $(pgrep -f traffic_server)
Per-node process memory usage (in MBs) for PID 31075 ([TS_MAIN])
Node 0 Node 1 Total
--- --- ---
Huge 0.000.000.00
Heap 0.000.000.00
Stack1.520.942.46
Private 118751.97 119729.43 238481.40
--- --- ---
Total 118753.49 119730.37 238483.86
```
"Stop using the main thread as ET_NET 0 ..." (from the Jira)
Here is a new thread showing now: TS_MAIN
```
$ ps -e -T -o 'pid,ucmd'|grep $(pgrep -f traffic_server)|cut -d" " -f2|sort
|uniq -c
5 [ACCEPT
24 [ET_AIO
24 [ET_NET
1 [ET_OCSP
2 [ET_TASK
1 [LOG_FLUSH]
1 [LOG_PREPROC
2 traffic_server
1 [TS_MAIN]
```
``traffic_server`` ``ET_NET`` threads are distributed evenly over the 2
NUMA nodes on the machine where I tested (running on nodesets and bound to the
corresponding cpusets as expected)
```
$ sudo lstopo --top --no-io -.xml|grep traffic_server|awk '{match($12,
/(.*)"/, a); printf("%s %s ", $6, $9); system("ps -e -T -o pid,spid,ucmd|grep "
a[1]);}'
allowed_cpuset="0x3ff003ff" allowed_nodeset="0x0001" 31075 31101
[ET_NET 22]
allowed_cpuset="0x3ff003ff" allowed_nodeset="0x0001" 31075 31099
[ET_NET 20]
allowed_cpuset="0x3ff003ff" allowed_nodeset="0x0001" 31075 31097
[ET_NET 18]
allowed_cpuset="0x3ff003ff" allowed_nodeset="0x0001" 31075 31095
[ET_NET 16]
allowed_cpuset="0x3ff003ff" allowed_nodeset="0x0001" 31075 31093
[ET_NET 14]
allowed_cpuset="0x3ff003ff" allowed_nodeset="0x0001" 31075 31091
[ET_NET 12]
allowed_cpuset="0x3ff003ff" allowed_nodeset="0x0001" 31075 31089
[ET_NET 10]
allowed_cpuset="0x3ff003ff" allowed_nodeset="0x0001" 31075 31087
[ET_NET 8]
allowed_cpuset="0x3ff003ff" allowed_nodeset="0x0001" 31075 31085
[ET_NET 6]
allowed_cpuset="0x3ff003ff" allowed_nodeset="0x0001" 31075 31083
[ET_NET 4]
allowed_cpuset="0x3ff003ff" allowed_nodeset="0x0001" 31075 31081
[ET_NET 2]
allowed_cpuset="0x3ff003ff" allowed_nodeset="0x0001" 31075 31079
[ET_NET 0]
allowed_cpuset="0x00ff,0xc00ffc00" allowed_nodeset="0x0002" 31075
31102 [ET_NET 23]
allowed_cpuset="0x00ff,0xc00ffc00" allowed_nodeset="0x0002" 31075
31100 [ET_NET 21]
allowed_cpuset="0x00ff,0xc00ffc00" allowed_nodeset="0x0002" 31075
31098 [ET_NET 19]
allowed_cpuset="0x00ff,0xc00ffc00" allowed_nodeset="0x0002" 31075
31096 [ET_NET 17]
allowed_cpuset="0x00ff,0xc00ffc00" allowed_nodeset="0x0002" 31075
31094 [ET_NET 15]
allowed_cpuset="0x00ff,0xc00ffc00" allowed_nodeset="0x0002" 31075
31092 [ET_NET 13]
allowed_cpuset="0x00ff,0xc00ffc00" allowed_nodeset="0x0002" 31075
31090 [ET_NET 11]
allowed_cpuset="0x00ff,0xc00ffc00" allowed_nodeset="0x0002" 31075
31088 [ET_NET 9]
allowed_cpuset="0x00ff,0xc00ffc00" allowed_nodeset="0x0002" 31075
31086 [ET_NET 7]
allowed_cpuset="0x00ff,0xc00ffc00" allowed_nodeset="0x0002" 31075
31084 [ET_NET 5]
allowed_cpuset="0x00ff,0xc00ffc00" allowed_nodeset="0x0002" 31075
31082 [ET_NET 3]
allowed_cpuset="0x00ff,0xc00ffc00" allowed_nodeset="0x0002" 31075
31080 [ET_NET 1]
```
The NUMA policy is ``preferred=node0`` and ``preferred=node1`` for the
corresponding stack segments.
```
$ for pid in `ps -e -T -o 'spid,ucmd'|grep ET_NET |cut -d" " -f1 `; do sudo
grep stack /proc/${pid}/numa_maps; done| awk '{match($3, /.*:(.*)/, a);
printf("%s ", $2); system("ps -e -T -o pid,spid,ucmd|grep "
[GitHub] trafficserver pull request #956: TS-4806: Fix up event processor thread stac...
Github user gtenev commented on a diff in the pull request:
https://github.com/apache/trafficserver/pull/956#discussion_r78275728
--- Diff: iocore/eventsystem/UnixEventProcessor.cc ---
@@ -129,34 +197,58 @@ EventProcessor::start(int n_event_threads, size_t
stacksize)
obj_name = (char *)"Machine";
}
+ // How many of the above `obj_type` do we have in our topology?
obj_count = hwloc_get_nbobjs_by_type(ink_get_topology(), obj_type);
Debug("iocore_thread", "Affinity: %d %ss: %d PU: %d", affinity,
obj_name, obj_count, ink_number_of_processors());
#endif
for (i = 0; i < n_ethreads; i++) {
ink_thread tid;
-if (i > 0) {
- snprintf(thr_name, MAX_THREAD_NAME_LENGTH, "[ET_NET %d]", i);
- tid = all_ethreads[i]->start(thr_name, stacksize);
-} else {
- tid = ink_thread_self();
-}
+
#if TS_USE_HWLOC
if (obj_count > 0) {
+ // Get our `obj` instance with index based on the thread number we
are on.
obj = hwloc_get_obj_by_type(ink_get_topology(), obj_type, i %
obj_count);
--- End diff --
We could defensively check/handle ``NULL`` to "protect" ``obj->cpuset``
later.
---
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 is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] trafficserver pull request #996: TS-4834 Expose bad disk and disk access fai...
GitHub user gtenev opened a pull request: https://github.com/apache/trafficserver/pull/996 TS-4834 Expose bad disk and disk access failures For monitoring purposes expose stats about: - disk access failure count - marked bad disk count You can merge this pull request into a Git repository by running: $ git pull https://github.com/gtenev/trafficserver TS-4834 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/trafficserver/pull/996.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #996 commit 04ad3af7fea97b761a4289b44a35a1d934e1a6fc Author: Gancho Tenev <gtte...@gmail.com> Date: 2016-09-08T20:23:09Z TS-4834 Expose bad disk and disk access failures For monitoring purposes expose stats about: - disk access failure count - marked bad disk count --- 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 is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] trafficserver issue #987: TS-4824: gcc enumeral and non-enumeral type in con...
Github user gtenev commented on the issue: https://github.com/apache/trafficserver/pull/987 ð +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 not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] trafficserver pull request #914: TS-4686 Moved hook-trace plugin to plugins/...
GitHub user gtenev opened a pull request: https://github.com/apache/trafficserver/pull/914 TS-4686 Moved hook-trace plugin to plugins/experimental Moved hook-trace plugin from examples to plugin/experimental and its documentation (including the Japanese version). You can merge this pull request into a Git repository by running: $ git pull https://github.com/gtenev/trafficserver TS-4686 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/trafficserver/pull/914.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #914 --- 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 is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] trafficserver issue #911: TS-2220: Rename proxy.config.http.anonymize_insert...
Github user gtenev commented on the issue: https://github.com/apache/trafficserver/pull/911 ð --- 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 is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] trafficserver issue #882: TS-4362 Removed cacheurl plugin
Github user gtenev commented on the issue: https://github.com/apache/trafficserver/pull/882 @zwoop, announcement sent to users@ --- 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 is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] trafficserver pull request #882: TS-4362 Removed cacheurl plugin
GitHub user gtenev opened a pull request: https://github.com/apache/trafficserver/pull/882 TS-4362 Removed cacheurl plugin Removed the cacheurl plugin and its documentation (including the Japanese version) You can merge this pull request into a Git repository by running: $ git pull https://github.com/gtenev/trafficserver TS-4362 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/trafficserver/pull/882.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #882 commit bce1ab5da7f9d73b529fb16d8786dd12b9205336 Author: Gancho Tenev <gtte...@gmail.com> Date: 2016-08-17T23:33:15Z TS-4362 Removed cacheurl plugin --- 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 is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] trafficserver issue #868: TS-4719: Make AIO threads interleave memory across...
Github user gtenev commented on the issue: https://github.com/apache/trafficserver/pull/868 @PSUdaemon, tested the change and it seems it worked. WITHOUT the fix: ``` Per-node process memory usage (in MBs) for PID 33486 ([ET_NET 0]) Node 0 Node 1 Total --- --- --- Huge 0.000.000.00 Heap 0.000.000.00 Stack1.101.933.04 Private 188774.4058365.61 247140.01 --- --- --- Total 188775.5058367.55 247143.05 ``` WITH the fix: ``` Per-node process memory usage (in MBs) for PID 19187 ([ET_NET 0]) Node 0 Node 1 Total --- --- --- Huge 0.000.000.00 Heap 0.000.000.00 Stack1.050.581.63 Private 117512.30 118122.88 235635.18 --- --- --- Total 117513.35 118123.46 235636.80 ``` --- 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 is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] trafficserver issue #837: TS-4706 Truncated SNI name during escalation
Github user gtenev commented on the issue: https://github.com/apache/trafficserver/pull/837 @zwoop thanks for reviewing! As far as can tell the escalate plugin was implemented later then the HttpHdr caching and the caching implementation does not support its use-case well. The reason we started noticing the truncated/garbage name problems is that SSL handshake changed (got stricter) This fix is meant to solve the immediate problem of having `t_state.hdr_info.server_request` cache not being invalidated after the escalate plugin called `TSHttpTxnRedirectUrlSet()` to retry the request to a secondary origin after the primary origin failed. This code change would invalidate (only invalidate) client request and server request `HttpHdr` at the same time only during `HttpSM::redirect_request()`, the caching state of the 2 objects would not necessarily be kept (or assumed to be) in sync (client request and server request HttpHdr were not meant to be invariant). Filed Jira: [TS-4712](https://issues.apache.org/jira/browse/TS-4712) to look into the `HttpHdr` caching use-cases and verify the HttpHdr caching functionality. --- 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 is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] trafficserver pull request #837: TS-4706 Truncated SNI name during escalatio...
GitHub user gtenev opened a pull request: https://github.com/apache/trafficserver/pull/837 TS-4706 Truncated SNI name during escalation A fix for a problem with SSL hostname verification failing due to truncated SNI name. You can merge this pull request into a Git repository by running: $ git pull https://github.com/gtenev/trafficserver TS-4706 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/trafficserver/pull/837.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #837 commit 4d02d0e877e24b1dc94948c236462417bdd9bbf0 Author: Gancho Tenev <gtte...@gmail.com> Date: 2016-07-29T23:39:44Z TS-4706 Truncated SNI name during escalation SSL hostname verification failing due to truncated SNI name. --- 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 is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] trafficserver pull request #818: TS-4683 Adds better error handling on confi...
Github user gtenev commented on a diff in the pull request:
https://github.com/apache/trafficserver/pull/818#discussion_r71735386
--- Diff: plugins/header_rewrite/ruleset.cc ---
@@ -51,7 +51,7 @@ RuleSet::add_condition(Parser , const char *filename)
if (!c->set_hook(_hook)) {
TSError("[%s] in %s: can't use this condition in hook=%d: %%{%s}
with arg: %s", PLUGIN_NAME, filename, _hook,
--- End diff --
@zwoop, do you think it would make sense to print the hook name instead of
the number?
Having the number is a great help for the developers but the operators
would not know what it means.
---
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 is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] trafficserver issue #792: TS-4650: cachekey: not thread safe
Github user gtenev commented on the issue: https://github.com/apache/trafficserver/pull/792 @ftarnell looks good, thanks for fixing! @zwoop it will be great if we can back port to 6.2.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 not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
