[jira] [Created] (TS-954) when use raw disks, some blocks is lost when caculate disk usable blocks
when use raw disks, some blocks is lost when caculate disk usable blocks Key: TS-954 URL: https://issues.apache.org/jira/browse/TS-954 Project: Traffic Server Issue Type: Bug Components: Cache Affects Versions: 3.1.0 Environment: all when use raw disks Reporter: weijin when use raw disks, some blocks may be lost because the skip variable is in bytes not in blocks. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-954) when use raw disks, some blocks is lost when caculate disk usable blocks
[ https://issues.apache.org/jira/browse/TS-954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] weijin updated TS-954: -- Attachment: calcu_blocks.dff when use raw disks, some blocks is lost when caculate disk usable blocks Key: TS-954 URL: https://issues.apache.org/jira/browse/TS-954 Project: Traffic Server Issue Type: Bug Components: Cache Affects Versions: 3.1.0 Environment: all when use raw disks Reporter: weijin Attachments: calcu_blocks.dff when use raw disks, some blocks may be lost because the skip variable is in bytes not in blocks. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-955) TS-168 breaks regressions for TextLog
TS-168 breaks regressions for TextLog - Key: TS-955 URL: https://issues.apache.org/jira/browse/TS-955 Project: Traffic Server Issue Type: Bug Components: Logging Affects Versions: 3.1.1 Reporter: Leif Hedstrom Fix For: 3.1.1 With the fixes from TS-168, the logging regressions can fail if you run the traffic_server -R 1 more than once. The first run always succeeds, but the 2nd and subsequent run can fail. What seems to happen is that the (small) log is not flushed, and the log is not created until the first flush happens. So, everything looks like it works, up until we (5s after log creation) try to read the log. The log then doesn't exist, and the regression in log_test_handler() fails (since, the file can't be open nor read). I've tracked this down to the commit for TS-168, and also traced through the test in gdb, and as far as I can tell, the flush never happens, which means the log write never happens, and hence, the log file creation never happens either. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-955) TS-168 breaks regressions for TextLog
[ https://issues.apache.org/jira/browse/TS-955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-955: - Priority: Critical (was: Major) Assignee: Zhao Yongming TS-168 breaks regressions for TextLog - Key: TS-955 URL: https://issues.apache.org/jira/browse/TS-955 Project: Traffic Server Issue Type: Bug Components: Logging Affects Versions: 3.1.1 Reporter: Leif Hedstrom Assignee: Zhao Yongming Priority: Critical Fix For: 3.1.1 With the fixes from TS-168, the logging regressions can fail if you run the traffic_server -R 1 more than once. The first run always succeeds, but the 2nd and subsequent run can fail. What seems to happen is that the (small) log is not flushed, and the log is not created until the first flush happens. So, everything looks like it works, up until we (5s after log creation) try to read the log. The log then doesn't exist, and the regression in log_test_handler() fails (since, the file can't be open nor read). I've tracked this down to the commit for TS-168, and also traced through the test in gdb, and as far as I can tell, the flush never happens, which means the log write never happens, and hence, the log file creation never happens either. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-84) code base: PATH_NAME_MAX vs PATH_MAX
[ https://issues.apache.org/jira/browse/TS-84?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-84. - Resolution: Fixed code base: PATH_NAME_MAX vs PATH_MAX Key: TS-84 URL: https://issues.apache.org/jira/browse/TS-84 Project: Traffic Server Issue Type: Improvement Components: Cleanup Affects Versions: 2.0.0a Environment: All Reporter: George Paul Assignee: Leif Hedstrom Priority: Minor Fix For: 3.1.1 Originally PATH_NAME_MAX was to be used for PATH_MAX for portability between OS's AFAIR. PATH_MAX is inconsistent on various OSs (linux-4096, osx/bsd-1024, windows-260(?), etc). TS is more consistent in the use of PATH_NAME_MAX in the code base (cache, hostdb, plugins, etc) while TM is not as consistent. TC never used it. The code base needs to examined for usage of both and made consistent and portable. The current suggestion is to use what TS currently uses which is PATH_NAME_MAX. This should be revisited when this issue is worked on. -George -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-924) Performance improvements with second request on same keep-alive connection
[ https://issues.apache.org/jira/browse/TS-924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-924: Assignee: Leif Hedstrom Performance improvements with second request on same keep-alive connection -- Key: TS-924 URL: https://issues.apache.org/jira/browse/TS-924 Project: Traffic Server Issue Type: Improvement Components: Core Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 3.1.1 Attachments: TS-924-v2.diff, TS-924.diff This is a continuation of TS-880, it has more details. The idea is that we committed the safe, but less optimal fix already with TS-880. Ideally though, we should do something like William's first approach, and migrate origin VConns to the same EThread as the UA VConn. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-956) the ON defined in TS conflict with zlib-1.2.5.1
[
https://issues.apache.org/jira/browse/TS-956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13105820#comment-13105820
]
Zhao Yongming commented on TS-956:
--
in TS:
#define ON ((char*)on)
int on = 1;
in zlib:
#ifndef ON /* function prototypes for stdarg */
# if defined(STDC) || defined(Z_HAVE_STDARG_H)
#define ON(args) args
# else
#define ON(args) ()
# endif
#endif
ON maybe defined on the other places, need to figure out
the ON defined in TS conflict with zlib-1.2.5.1
-
Key: TS-956
URL: https://issues.apache.org/jira/browse/TS-956
Project: Traffic Server
Issue Type: Bug
Components: Cleanup, Portability
Affects Versions: 3.1.1
Environment: gcc 4.6.1, zlib 1.2.5.1, ts trunk
Reporter: Zhao Yongming
Assignee: Zhao Yongming
Priority: Critical
Fix For: 3.1.1
when building trunk with my fresh updated gentoo, TS fail at:
{code}
x86_64-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I../../lib/ts
-I../../iocore/eventsystem -I../../iocore/net -I../../iocore/aio
-I../../iocore/hostdb -I../../iocore/cache -I../../iocore/cluster
-I../../iocore/utils -I../../iocore/dns -I../../lib -I../../lib/records
-I../../proxy -I../../proxy/hdrs -I../../proxy/http -I../../proxy/http/remap
-I../../mgmt -I../../mgmt/preparse -I../../mgmt/utils -D_LARGEFILE64_SOURCE=1
-D_COMPILE64BIT_SOURCE=1 -D_GNU_SOURCE -D_REENTRANT -Dlinux -pipe -g -ggdb3
-fno-strict-aliasing -Wall -Werror -O3 -feliminate-unused-debug-symbols
-Wno-invalid-offsetof -MT Inline.o -MD -MP -MF .deps/Inline.Tpo -c -o
Inline.o Inline.cc
In file included from RamCacheCLFUS.cc:30:0:
/usr/include/zlib.h:1283:32: error: invalid conversion from 'char*' to 'int'
[-fpermissive]
/usr/include/zlib.h:1283:34: error: expected ',' or ';' before '(' token
mv -f .deps/CacheHttp.Tpo .deps/CacheHttp.Po
x86_64-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I../../lib/ts
-I../../iocore/eventsystem -I../../iocore/net -I../../iocore/aio
-I../../iocore/hostdb -I../../iocore/cache -I../../iocore/cluster
-I../../iocore/utils -I../../iocore/dns -I../../lib -I../../lib/records
-I../../proxy -I../../proxy/hdrs -I../../proxy/http -I../../proxy/http/remap
-I../../mgmt -I../../mgmt/preparse -I../../mgmt/utils -D_LARGEFILE64_SOURCE=1
-D_COMPILE64BIT_SOURCE=1 -D_GNU_SOURCE -D_REENTRANT -Dlinux -pipe -g -ggdb3
-fno-strict-aliasing -Wall -Werror -O3 -feliminate-unused-debug-symbols
-Wno-invalid-offsetof -MT CacheTest.o -MD -MP -MF .deps/CacheTest.Tpo -c -o
CacheTest.o CacheTest.cc
make[2]: *** [RamCacheCLFUS.o] Error 1
make[2]: *** Waiting for unfinished jobs
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
