[jira] [Updated] (TS-993) Add OpenBSD support.
[ https://issues.apache.org/jira/browse/TS-993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Gruno updated TS-993: Attachment: freebsd.patch Patch that fixes the broken loop in Log.cc that makes ATS fail during debug mode and consume 100% cpu Add OpenBSD support. Key: TS-993 URL: https://issues.apache.org/jira/browse/TS-993 Project: Traffic Server Issue Type: Improvement Environment: OpenBSD Reporter: Piotr Sikora Fix For: 3.3.1 Attachments: 0001-Add-OpenBSD-support.patch, freebsd.patch Add OpenBSD support. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-993) Add OpenBSD support.
[ https://issues.apache.org/jira/browse/TS-993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13456557#comment-13456557 ] Daniel Gruno commented on TS-993: - The same bug applies to FreeBSD, as reported at http://www.freebsd.org/cgi/query-pr.cgi?pr=170829 Issues 1, 2 and 3 are related to a mutex not being locked/acquired (according to FreeBSD at least, I'll have to make sure) in Log.cc and subsequently being told to do an ink_cond_wait (which fails with EPERM and thus causes it to loop forever without waiting). I'm attaching a patch that fixes this issue. Add OpenBSD support. Key: TS-993 URL: https://issues.apache.org/jira/browse/TS-993 Project: Traffic Server Issue Type: Improvement Environment: OpenBSD Reporter: Piotr Sikora Fix For: 3.3.1 Attachments: 0001-Add-OpenBSD-support.patch, freebsd.patch Add OpenBSD support. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-1064) logging format update
[ https://issues.apache.org/jira/browse/TS-1064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Gruno resolved TS-1064. -- Resolution: Fixed As there has been no objections, I'm closing this issue as fixed. If anyone feels otherwise, feel free to reopen. logging format update - Key: TS-1064 URL: https://issues.apache.org/jira/browse/TS-1064 Project: Traffic Server Issue Type: Task Components: Documentation Reporter: Zhao Yongming Assignee: Daniel Gruno Priority: Trivial Fix For: Doc 3.2 %phi is not documented so far, we should make sure all those hiding items documented. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1457) transforms during video requests cause massive memory growth
[ https://issues.apache.org/jira/browse/TS-1457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13456572#comment-13456572 ] Alan M. Carroll commented on TS-1457: - Commit This fix changes the way chunking output is handled to avoid the memory bloat. The root problem was using IOBuffers that were too large, in some cases 2M buffers to hold ~10 bytes. 1) Dechunking now uses 256 byte buffers, which is the cut off for copying bytes vs. using IOBuffer references. 2) Chunking now uses minimum size buffers because the only data actually placed in those buffers are the chunk header and trailer which vary from 5 to 12 bytes. All other data is passed via IOBufferBlock references. In addition the chunk size handling was modified to default to the original 4096 but it can now be configured globally and on a per transaction basis. The global config value is proxy.config.http.chunking.size INT maximum chunk size This value is also accessible per transaction by using the TSHttpTxnConfigInt[SG]et functions with a key of TS_CONFIG_HTTP_CHUNKING_SIZE. transforms during video requests cause massive memory growth Key: TS-1457 URL: https://issues.apache.org/jira/browse/TS-1457 Project: Traffic Server Issue Type: Bug Components: Core Affects Versions: 3.2.0 Environment: Linux RHEL6.2 Reporter: Aidan McGurn Priority: Critical Attachments: 3.0.3-null-massif.txt, 3.0.5-null-massif.txt, alan-chunk-fix-3.2.0-null.txt, alan-nofix-3.2.0-null.txt, no-null-3.2.0-massif.txt, null-3.0.2-massif.txt, null-3.2.0-massif.txt, ts-1457-patch-1.diff Running the null-transform example object over 3.2.0, shows massive memory growth - This could be seen on our system since using 3.2.0 with custom plugin which invokes transforms - under load ~6K and with video content (only Video - small files are ok), a huge growth was seen (GB's) such that it crashes the load test machine. heap profiles are attached for comparison: -null transform example so over 3.2.0 -NO null transform over 3.2.0 -null transform example so over 3.0.2 As can be seen no issue in 3.0.2 - The profiles show clearly the call chain is different for both releases -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (TS-1457) transforms during video requests cause massive memory growth
[ https://issues.apache.org/jira/browse/TS-1457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13456572#comment-13456572 ] Alan M. Carroll edited comment on TS-1457 at 9/17/12 12:35 AM: --- Commit a2d46114a918cf72a38d66ea66dea96dbb9b6920 This fix changes the way chunking output is handled to avoid the memory bloat. The root problem was using IOBuffers that were too large, in some cases 2M buffers to hold ~10 bytes. 1) Dechunking now uses 256 byte buffers, which is the cut off for copying bytes vs. using IOBuffer references. 2) Chunking now uses minimum size buffers because the only data actually placed in those buffers are the chunk header and trailer which vary from 5 to 12 bytes. All other data is passed via IOBufferBlock references. In addition the chunk size handling was modified to default to the original 4096 but it can now be configured globally and on a per transaction basis. The global config value is proxy.config.http.chunking.size INT maximum chunk size This value is also accessible per transaction by using the TSHttpTxnConfigInt[SG]et functions with a key of TS_CONFIG_HTTP_CHUNKING_SIZE. was (Author: amc): Commit This fix changes the way chunking output is handled to avoid the memory bloat. The root problem was using IOBuffers that were too large, in some cases 2M buffers to hold ~10 bytes. 1) Dechunking now uses 256 byte buffers, which is the cut off for copying bytes vs. using IOBuffer references. 2) Chunking now uses minimum size buffers because the only data actually placed in those buffers are the chunk header and trailer which vary from 5 to 12 bytes. All other data is passed via IOBufferBlock references. In addition the chunk size handling was modified to default to the original 4096 but it can now be configured globally and on a per transaction basis. The global config value is proxy.config.http.chunking.size INT maximum chunk size This value is also accessible per transaction by using the TSHttpTxnConfigInt[SG]et functions with a key of TS_CONFIG_HTTP_CHUNKING_SIZE. transforms during video requests cause massive memory growth Key: TS-1457 URL: https://issues.apache.org/jira/browse/TS-1457 Project: Traffic Server Issue Type: Bug Components: Core Affects Versions: 3.2.0 Environment: Linux RHEL6.2 Reporter: Aidan McGurn Priority: Critical Attachments: 3.0.3-null-massif.txt, 3.0.5-null-massif.txt, alan-chunk-fix-3.2.0-null.txt, alan-nofix-3.2.0-null.txt, no-null-3.2.0-massif.txt, null-3.0.2-massif.txt, null-3.2.0-massif.txt, ts-1457-patch-1.diff Running the null-transform example object over 3.2.0, shows massive memory growth - This could be seen on our system since using 3.2.0 with custom plugin which invokes transforms - under load ~6K and with video content (only Video - small files are ok), a huge growth was seen (GB's) such that it crashes the load test machine. heap profiles are attached for comparison: -null transform example so over 3.2.0 -NO null transform over 3.2.0 -null transform example so over 3.0.2 As can be seen no issue in 3.0.2 - The profiles show clearly the call chain is different for both releases -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1473) ATS 3.2 drops support for ARM
[
https://issues.apache.org/jira/browse/TS-1473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13456579#comment-13456579
]
Leif Hedstrom commented on TS-1473:
---
I guess I never committed the tiny fix. Will do so shortly.
ATS 3.2 drops support for ARM
-
Key: TS-1473
URL: https://issues.apache.org/jira/browse/TS-1473
Project: Traffic Server
Issue Type: Bug
Components: Plugins
Affects Versions: 3.2.0
Reporter: Arno Toell
Assignee: Leif Hedstrom
Looks like you dropped ARM from the list of supported ports. Trafficserver
3.2 does not build on purpose on ARM anymore. Bad code is in
./trafficserver/plugins/header_filter/lulu.h:
{code}
#if defined(__i386__)
...
#elif defined(__x86_64__)
...
#else
#error Define barriers
#endif
{code}
Full build log for Debian is here:
https://buildd.debian.org/status/fetch.php?pkg=trafficserverarch=armhfver=3.2.0-1stamp=1347665237
Please tell me, whether you intend to fix that (sorry, no ARM assembly skills
from my side) or whether you intend to drop ARM entirely.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1473) ATS 3.2 drops support for ARM
[
https://issues.apache.org/jira/browse/TS-1473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13456580#comment-13456580
]
Leif Hedstrom commented on TS-1473:
---
I made a number of other fixes on trunk as well, but I guess those are not
necessary on 3.2.x.
ATS 3.2 drops support for ARM
-
Key: TS-1473
URL: https://issues.apache.org/jira/browse/TS-1473
Project: Traffic Server
Issue Type: Bug
Components: Plugins
Affects Versions: 3.2.0
Reporter: Arno Toell
Assignee: Leif Hedstrom
Looks like you dropped ARM from the list of supported ports. Trafficserver
3.2 does not build on purpose on ARM anymore. Bad code is in
./trafficserver/plugins/header_filter/lulu.h:
{code}
#if defined(__i386__)
...
#elif defined(__x86_64__)
...
#else
#error Define barriers
#endif
{code}
Full build log for Debian is here:
https://buildd.debian.org/status/fetch.php?pkg=trafficserverarch=armhfver=3.2.0-1stamp=1347665237
Please tell me, whether you intend to fix that (sorry, no ARM assembly skills
from my side) or whether you intend to drop ARM entirely.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1473) ATS 3.2 drops support for ARM
[
https://issues.apache.org/jira/browse/TS-1473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1473:
--
Fix Version/s: 3.3.1
ATS 3.2 drops support for ARM
-
Key: TS-1473
URL: https://issues.apache.org/jira/browse/TS-1473
Project: Traffic Server
Issue Type: Bug
Components: Plugins
Affects Versions: 3.2.0
Reporter: Arno Toell
Assignee: Leif Hedstrom
Fix For: 3.3.1
Looks like you dropped ARM from the list of supported ports. Trafficserver
3.2 does not build on purpose on ARM anymore. Bad code is in
./trafficserver/plugins/header_filter/lulu.h:
{code}
#if defined(__i386__)
...
#elif defined(__x86_64__)
...
#else
#error Define barriers
#endif
{code}
Full build log for Debian is here:
https://buildd.debian.org/status/fetch.php?pkg=trafficserverarch=armhfver=3.2.0-1stamp=1347665237
Please tell me, whether you intend to fix that (sorry, no ARM assembly skills
from my side) or whether you intend to drop ARM entirely.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1466) turn off SSL compression by default
[ https://issues.apache.org/jira/browse/TS-1466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1466: -- Backport to Version: 3.2.6, 3.0.6 turn off SSL compression by default --- Key: TS-1466 URL: https://issues.apache.org/jira/browse/TS-1466 Project: Traffic Server Issue Type: Bug Affects Versions: 3.3.0, 3.2.0 Reporter: Bryan Call Assignee: Bryan Call Fix For: 3.3.1 Attachments: ssl_no_compression.patch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-1473) ATS 3.2 drops support for ARM
[
https://issues.apache.org/jira/browse/TS-1473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom resolved TS-1473.
---
Resolution: Fixed
Fixed in a7baf7c8f1bb9206e17b9ac925e21e5beab08f56 on trunk.
ATS 3.2 drops support for ARM
-
Key: TS-1473
URL: https://issues.apache.org/jira/browse/TS-1473
Project: Traffic Server
Issue Type: Bug
Components: Plugins
Affects Versions: 3.2.0
Reporter: Arno Toell
Assignee: Leif Hedstrom
Fix For: 3.3.1
Looks like you dropped ARM from the list of supported ports. Trafficserver
3.2 does not build on purpose on ARM anymore. Bad code is in
./trafficserver/plugins/header_filter/lulu.h:
{code}
#if defined(__i386__)
...
#elif defined(__x86_64__)
...
#else
#error Define barriers
#endif
{code}
Full build log for Debian is here:
https://buildd.debian.org/status/fetch.php?pkg=trafficserverarch=armhfver=3.2.0-1stamp=1347665237
Please tell me, whether you intend to fix that (sorry, no ARM assembly skills
from my side) or whether you intend to drop ARM entirely.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-993) Add OpenBSD support.
[
https://issues.apache.org/jira/browse/TS-993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13456673#comment-13456673
]
Igor Galić commented on TS-993:
---
[~humbedooh], are you sure we want {{ink_mutex_acquire()}} here, not
{{ink_mutex_try_acquire()}}
{{ink_mutex_acquire()}} causes an {{abort()}}.
Add OpenBSD support.
Key: TS-993
URL: https://issues.apache.org/jira/browse/TS-993
Project: Traffic Server
Issue Type: Improvement
Environment: OpenBSD
Reporter: Piotr Sikora
Fix For: 3.3.1
Attachments: 0001-Add-OpenBSD-support.patch, freebsd.patch
Add OpenBSD support.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-993) Add OpenBSD support.
[ https://issues.apache.org/jira/browse/TS-993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13456675#comment-13456675 ] Daniel Gruno commented on TS-993: - ink_mutex_try_acquire would be just as peachy for me, and probably a safer bet. I did try using the 'try' version myself, and got the same good results (ie cpu not rising to 100%). Add OpenBSD support. Key: TS-993 URL: https://issues.apache.org/jira/browse/TS-993 Project: Traffic Server Issue Type: Improvement Environment: OpenBSD Reporter: Piotr Sikora Fix For: 3.3.1 Attachments: 0001-Add-OpenBSD-support.patch, freebsd.patch Add OpenBSD support. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-993) Add OpenBSD support.
[ https://issues.apache.org/jira/browse/TS-993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13456685#comment-13456685 ] Igor Galić commented on TS-993: --- +1 from me, but maybe you can get [~jplevyak], or someone else who has a clue about how our threading stuff works to comment on this Add OpenBSD support. Key: TS-993 URL: https://issues.apache.org/jira/browse/TS-993 Project: Traffic Server Issue Type: Improvement Environment: OpenBSD Reporter: Piotr Sikora Fix For: 3.3.1 Attachments: 0001-Add-OpenBSD-support.patch, freebsd.patch Add OpenBSD support. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
