[jira] [Commented] (TS-3424) SSL error: SSL3_GET_RECORD:decryption failed or bad record mac
[
https://issues.apache.org/jira/browse/TS-3424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14356400#comment-14356400
]
Brian Geffon commented on TS-3424:
--
The errors we are seeing now are coming from
SSLNetVConnection::sslServerHandShakeEvent, it appears the SSL_accept is
returning something <= 0, unfortunately the wrapper function is hiding the
exact return value at the moment.
Additionally, when I try to get the detailed error code via ERR_get_error()
it's returning 0, so I'm not entirely sure what's up there. It's unlikely that
this is something specific to our environment as this issue didn't happen with
5.0.x and it's happening during the SSL_accept phase before we have a chance to
really do anything.
> SSL error: SSL3_GET_RECORD:decryption failed or bad record mac
> --
>
> Key: TS-3424
> URL: https://issues.apache.org/jira/browse/TS-3424
> Project: Traffic Server
> Issue Type: Bug
> Components: Core, SSL
>Reporter: Brian Geffon
>Assignee: Brian Geffon
> Fix For: 6.0.0
>
> Attachments: ts-3424-2.diff, ts-3424-3.diff, ts-3424-for-52-2.diff,
> ts-3424-for-52.diff, ts-3424.diff, undo-handshake-buffer.diff
>
>
> Starting with 5.2.x we're seeing SSL_ERROR_SSL type errors in
> {{ssl_read_from_net}}, when calling OpenSSL's {{ERR_error_string_n}} we see
> the error is {{1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad
> record mac}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (TS-3433) Use extra memory than expected
[ https://issues.apache.org/jira/browse/TS-3433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14356372#comment-14356372 ] pjack edited comment on TS-3433 at 3/11/15 6:13 AM: It did not start up with 1.5G but growing over time to 1.5G. I found this issue at ATS 4.2.1 but even I upgrade to 4.2.3, I still can reproduce this issue. Do you need further information? was (Author: pjack): It did not start up with 1.5G but growing over time to 1.5G. I found this issue at ATS 4.2.1 but even I upgrade to 4.2.3, I still can reproduce this issue. > Use extra memory than expected > -- > > Key: TS-3433 > URL: https://issues.apache.org/jira/browse/TS-3433 > Project: Traffic Server > Issue Type: Bug > Components: Cache >Reporter: pjack > Fix For: sometime > > > the storage size is 16G, and ram_cache.size use the default value : (-1) > I expect the memory of the process should be less than 200MB, but it used > 1.5G and more until my server out of memory. > I checked the ram_cache size and I found bytes_used > total_bytes. > OS: Ubuntu 12.04 with 3.13.0-32 kernal > traffic server version: 4.2.3 > $curl http://localhost:8080/_status | grep ram > "proxy.process.cache.ram_cache.total_bytes": "13410304", > "proxy.process.cache.ram_cache.bytes_used": "133754880", > "proxy.process.cache.ram_cache.hits": "12322", > "proxy.process.cache.ram_cache.misses": "55584", > But if I setup the ram_cache.size to a fixed value, then the bytes_used will > be always smaller than total_bytes. Please let me know if it is a correct > scenario or some kind of bug? > Thanks! > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3433) Use extra memory than expected
[ https://issues.apache.org/jira/browse/TS-3433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14356372#comment-14356372 ] pjack commented on TS-3433: --- It did not start up with 1.5G but growing over time to 1.5G. I found this issue at ATS 4.2.1 but even I upgrade to 4.2.3, I still can reproduce this issue. > Use extra memory than expected > -- > > Key: TS-3433 > URL: https://issues.apache.org/jira/browse/TS-3433 > Project: Traffic Server > Issue Type: Bug > Components: Cache >Reporter: pjack > Fix For: sometime > > > the storage size is 16G, and ram_cache.size use the default value : (-1) > I expect the memory of the process should be less than 200MB, but it used > 1.5G and more until my server out of memory. > I checked the ram_cache size and I found bytes_used > total_bytes. > OS: Ubuntu 12.04 with 3.13.0-32 kernal > traffic server version: 4.2.3 > $curl http://localhost:8080/_status | grep ram > "proxy.process.cache.ram_cache.total_bytes": "13410304", > "proxy.process.cache.ram_cache.bytes_used": "133754880", > "proxy.process.cache.ram_cache.hits": "12322", > "proxy.process.cache.ram_cache.misses": "55584", > But if I setup the ram_cache.size to a fixed value, then the bytes_used will > be always smaller than total_bytes. Please let me know if it is a correct > scenario or some kind of bug? > Thanks! > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3433) Use extra memory than expected
[ https://issues.apache.org/jira/browse/TS-3433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14356339#comment-14356339 ] Leif Hedstrom commented on TS-3433: --- It starts up with 1.5G of RAM used? Or are you saying it's growing over time to 1.5G ? What version of ATS? 16G of disk cache would use a small amount of RAM (about 20MB or so) for directory entries, so the numbers definitely don't add up to 1.5G of RAM. > Use extra memory than expected > -- > > Key: TS-3433 > URL: https://issues.apache.org/jira/browse/TS-3433 > Project: Traffic Server > Issue Type: Bug > Components: Cache >Reporter: pjack > Fix For: sometime > > > the storage size is 16G, and ram_cache.size use the default value : (-1) > I expect the memory of the process should be less than 200MB, but it used > 1.5G and more until my server out of memory. > I checked the ram_cache size and I found bytes_used > total_bytes. > OS: Ubuntu 12.04 with 3.13.0-32 kernal > traffic server version: 4.2.3 > $curl http://localhost:8080/_status | grep ram > "proxy.process.cache.ram_cache.total_bytes": "13410304", > "proxy.process.cache.ram_cache.bytes_used": "133754880", > "proxy.process.cache.ram_cache.hits": "12322", > "proxy.process.cache.ram_cache.misses": "55584", > But if I setup the ram_cache.size to a fixed value, then the bytes_used will > be always smaller than total_bytes. Please let me know if it is a correct > scenario or some kind of bug? > Thanks! > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3433) Use extra memory than expected
[ https://issues.apache.org/jira/browse/TS-3433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-3433: -- Fix Version/s: sometime > Use extra memory than expected > -- > > Key: TS-3433 > URL: https://issues.apache.org/jira/browse/TS-3433 > Project: Traffic Server > Issue Type: Bug > Components: Cache >Reporter: pjack > Fix For: sometime > > > the storage size is 16G, and ram_cache.size use the default value : (-1) > I expect the memory of the process should be less than 200MB, but it used > 1.5G and more until my server out of memory. > I checked the ram_cache size and I found bytes_used > total_bytes. > OS: Ubuntu 12.04 with 3.13.0-32 kernal > traffic server version: 4.2.3 > $curl http://localhost:8080/_status | grep ram > "proxy.process.cache.ram_cache.total_bytes": "13410304", > "proxy.process.cache.ram_cache.bytes_used": "133754880", > "proxy.process.cache.ram_cache.hits": "12322", > "proxy.process.cache.ram_cache.misses": "55584", > But if I setup the ram_cache.size to a fixed value, then the bytes_used will > be always smaller than total_bytes. Please let me know if it is a correct > scenario or some kind of bug? > Thanks! > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3435) proxy.config.log.max_secs_per_buffer does not work below 5 secs
[ https://issues.apache.org/jira/browse/TS-3435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14356327#comment-14356327 ] Leif Hedstrom commented on TS-3435: --- I don't know that anyone will work on this, I'm not opposed to the changes necessary to get this to work. And fwiw, you are absolutely correct, it will not really work if you go less that the "collection" intervals. > proxy.config.log.max_secs_per_buffer does not work below 5 secs > --- > > Key: TS-3435 > URL: https://issues.apache.org/jira/browse/TS-3435 > Project: Traffic Server > Issue Type: Bug >Reporter: Frank Chan >Priority: Minor > Fix For: sometime > > > It seems proxy.config.log.max_secs_per_buffer doesn't work below 5 secs. > Apparently, it is because Log.cc:PERIODIC_TASKS_INTERVAL is set to 5 secs. > There are comments from the code that this may be configurable in future and > guess it may fix the issue. > Thanks! -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3435) proxy.config.log.max_secs_per_buffer does not work below 5 secs
[ https://issues.apache.org/jira/browse/TS-3435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-3435: -- Fix Version/s: sometime > proxy.config.log.max_secs_per_buffer does not work below 5 secs > --- > > Key: TS-3435 > URL: https://issues.apache.org/jira/browse/TS-3435 > Project: Traffic Server > Issue Type: Bug >Reporter: Frank Chan >Priority: Minor > Fix For: sometime > > > It seems proxy.config.log.max_secs_per_buffer doesn't work below 5 secs. > Apparently, it is because Log.cc:PERIODIC_TASKS_INTERVAL is set to 5 secs. > There are comments from the code that this may be configurable in future and > guess it may fix the issue. > Thanks! -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3424) SSL error: SSL3_GET_RECORD:decryption failed or bad record mac
[
https://issues.apache.org/jira/browse/TS-3424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Susan Hinrichs updated TS-3424:
---
Attachment: ts-3424-for-52-2.diff
Brian is still reporting an increase in SSL_ERROR_SSL errors from 5.0 to 5.2.
Lower than original, but still an increase.
ts-3424-for-52-2.diff plugs one more place where we might have lost buffer
data. I tested this in our production but did not exercise the case. It may
be an issue in your environment.
In our production environment, I did not notice a difference in SSL_ERROR_SSL
counts from 5.0 to 5.2 plus previous patch.
> SSL error: SSL3_GET_RECORD:decryption failed or bad record mac
> --
>
> Key: TS-3424
> URL: https://issues.apache.org/jira/browse/TS-3424
> Project: Traffic Server
> Issue Type: Bug
> Components: Core, SSL
>Reporter: Brian Geffon
>Assignee: Brian Geffon
> Fix For: 6.0.0
>
> Attachments: ts-3424-2.diff, ts-3424-3.diff, ts-3424-for-52-2.diff,
> ts-3424-for-52.diff, ts-3424.diff, undo-handshake-buffer.diff
>
>
> Starting with 5.2.x we're seeing SSL_ERROR_SSL type errors in
> {{ssl_read_from_net}}, when calling OpenSSL's {{ERR_error_string_n}} we see
> the error is {{1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad
> record mac}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3342) Non-standard method in bad request can cause crash
[
https://issues.apache.org/jira/browse/TS-3342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14356166#comment-14356166
]
William Bardwell commented on TS-3342:
--
Commit 66bdd406f92e61bd0fdc86afe308a7563093896f in trafficserver's branch
refs/heads/master
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=66bdd40 ]
> Non-standard method in bad request can cause crash
> --
>
> Key: TS-3342
> URL: https://issues.apache.org/jira/browse/TS-3342
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Reporter: William Bardwell
>Assignee: William Bardwell
> Labels: review
> Fix For: 5.3.0
>
> Attachments: TS-3342.diff
>
>
> Fix is to check for a normal sort of method (that would actually need a cache
> lookup) in HttpTransact::HandleCacheOpenReadMiss() to do
> {code}
> s->cache_info.action = CACHE_DO_NO_ACTION;
> {code}
> instead of
> {code}
> s->cache_info.action = CACHE_PREPARE_TO_WRITE;
> {code}
> for anything weird. But I am concerned that this might cause problems if
> someone wants to add support for a weird method...but maybe that never works
> right with the cache anyway...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3331) negative responses cached even when headers indicate otherwise
[ https://issues.apache.org/jira/browse/TS-3331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14356129#comment-14356129 ] William Bardwell commented on TS-3331: -- Commit bd62e7006547e9fc174a764b2c219f774643a31a in trafficserver's branch refs/heads/master [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=bd62e70 ] > negative responses cached even when headers indicate otherwise > -- > > Key: TS-3331 > URL: https://issues.apache.org/jira/browse/TS-3331 > Project: Traffic Server > Issue Type: Bug > Components: Core >Reporter: William Bardwell >Assignee: William Bardwell > Labels: review > Fix For: 5.3.0 > > > Negative type status codes get cached even when there are Cache-Control: > no-store or the like headers and positive caching would be paying attention > to that. So the fix is to apply response headers (and general caching > config) to negative caching choices too. > My patch might fix [TS-2633] 406 negative responses being cached for too long -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3435) proxy.config.log.max_secs_per_buffer does not work below 5 secs
[ https://issues.apache.org/jira/browse/TS-3435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Frank Chan updated TS-3435: --- Priority: Minor (was: Major) > proxy.config.log.max_secs_per_buffer does not work below 5 secs > --- > > Key: TS-3435 > URL: https://issues.apache.org/jira/browse/TS-3435 > Project: Traffic Server > Issue Type: Bug >Reporter: Frank Chan >Priority: Minor > > It seems proxy.config.log.max_secs_per_buffer doesn't work below 5 secs. > Apparently, it is because Log.cc:PERIODIC_TASKS_INTERVAL is set to 5 secs. > There are comments from the code that this may be configurable in future and > guess it may fix the issue. > Thanks! -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-3435) proxy.config.log.max_secs_per_buffer does not work below 5 secs
Frank Chan created TS-3435: -- Summary: proxy.config.log.max_secs_per_buffer does not work below 5 secs Key: TS-3435 URL: https://issues.apache.org/jira/browse/TS-3435 Project: Traffic Server Issue Type: Bug Reporter: Frank Chan It seems proxy.config.log.max_secs_per_buffer doesn't work below 5 secs. Apparently, it is because Log.cc:PERIODIC_TASKS_INTERVAL is set to 5 secs. There are comments from the code that this may be configurable in future and guess it may fix the issue. Thanks! -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3417) Use madvise() with MADV_DONTDUMP option to limit core sizes
[ https://issues.apache.org/jira/browse/TS-3417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14355191#comment-14355191 ] ASF subversion and git services commented on TS-3417: - Commit 613f8dadd1ad4f699b72d88cfba7e2f874242d3d in trafficserver's branch refs/heads/master from [~psudaemon] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=613f8da ] TS-3417: Add cast to make GCC happy > Use madvise() with MADV_DONTDUMP option to limit core sizes > --- > > Key: TS-3417 > URL: https://issues.apache.org/jira/browse/TS-3417 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Reporter: Phil Sorber >Assignee: Phil Sorber > Fix For: 5.3.0 > > > When ATS crashes it often leaves behind very large core files, in the > hundreds of gigabytes. A large percentage of these core files are useless > data in the IO buffers. We can limit the pages that the kernel dumps with > madvise(). > Note: This will only work on Linux 3.4+. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (TS-3427) compilation error of atscppapi when configured for a out-of-tree build
[ https://issues.apache.org/jira/browse/TS-3427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14354479#comment-14354479 ] Bin edited comment on TS-3427 at 3/10/15 7:48 AM: -- The unused_variables.diff patch removes unused variables. If a variable is unused, it should be deleted. Should I file a separate ticket for this? was (Author: bzeng): This patch removes unused variables. If a variable is unused, it should be deleted. > compilation error of atscppapi when configured for a out-of-tree build > -- > > Key: TS-3427 > URL: https://issues.apache.org/jira/browse/TS-3427 > Project: Traffic Server > Issue Type: Bug > Components: Build, CPP API >Reporter: Bin >Assignee: Brian Geffon > Fix For: 6.0.0 > > Attachments: atscppapi_1.diff, atscppapi_3.diff, unused_variables.diff > > > Header file not found error when --enable-cppapi is enabled for an > out-of-tree build on RHEL 6.4. It has no complaints if it is a in-tree build. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (TS-3427) compilation error of atscppapi when configured for a out-of-tree build
[ https://issues.apache.org/jira/browse/TS-3427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14354477#comment-14354477 ] Bin edited comment on TS-3427 at 3/10/15 7:47 AM: -- My bad. Thanks for the reviews. Did not do the regression tests. Replace top_srcdir with top_builddir for out-of-tree builds. Tested with './ci/regresssion --enable-cppapi' It should work now. was (Author: bzeng): Replace top_srcdir with top_builddir for out-of-tree builds. Tested with './ci/regresssion --enable-cppapi' > compilation error of atscppapi when configured for a out-of-tree build > -- > > Key: TS-3427 > URL: https://issues.apache.org/jira/browse/TS-3427 > Project: Traffic Server > Issue Type: Bug > Components: Build, CPP API >Reporter: Bin >Assignee: Brian Geffon > Fix For: 6.0.0 > > Attachments: atscppapi_1.diff, atscppapi_3.diff, unused_variables.diff > > > Header file not found error when --enable-cppapi is enabled for an > out-of-tree build on RHEL 6.4. It has no complaints if it is a in-tree build. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3427) compilation error of atscppapi when configured for a out-of-tree build
[ https://issues.apache.org/jira/browse/TS-3427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin updated TS-3427: Attachment: unused_variables.diff This patch removes unused variables. If a variable is unused, it should be deleted. > compilation error of atscppapi when configured for a out-of-tree build > -- > > Key: TS-3427 > URL: https://issues.apache.org/jira/browse/TS-3427 > Project: Traffic Server > Issue Type: Bug > Components: Build, CPP API >Reporter: Bin >Assignee: Brian Geffon > Fix For: 6.0.0 > > Attachments: atscppapi_1.diff, atscppapi_3.diff, unused_variables.diff > > > Header file not found error when --enable-cppapi is enabled for an > out-of-tree build on RHEL 6.4. It has no complaints if it is a in-tree build. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3427) compilation error of atscppapi when configured for a out-of-tree build
[ https://issues.apache.org/jira/browse/TS-3427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin updated TS-3427: Attachment: atscppapi_3.diff Replace top_srcdir with top_builddir for out-of-tree builds. Tested with './ci/regresssion --enable-cppapi' > compilation error of atscppapi when configured for a out-of-tree build > -- > > Key: TS-3427 > URL: https://issues.apache.org/jira/browse/TS-3427 > Project: Traffic Server > Issue Type: Bug > Components: Build, CPP API >Reporter: Bin >Assignee: Brian Geffon > Fix For: 6.0.0 > > Attachments: atscppapi_1.diff, atscppapi_3.diff > > > Header file not found error when --enable-cppapi is enabled for an > out-of-tree build on RHEL 6.4. It has no complaints if it is a in-tree build. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
