[jira] [Commented] (TS-702) FATAL: MIME.cc:1250: failed assert `j block_count`
[
https://issues.apache.org/jira/browse/TS-702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13024816#comment-13024816
]
Alan M. Carroll commented on TS-702:
I made the patch, added a few comments, did some casual testing, and committed
it. r1096494.
FATAL: MIME.cc:1250: failed assert `j block_count`
-
Key: TS-702
URL: https://issues.apache.org/jira/browse/TS-702
Project: Traffic Server
Issue Type: Bug
Components: MIME
Affects Versions: 2.0.1
Environment: Sun Blade X6240 (64G Ram), Running Linux Debian Lenny,
Kernel 2.6.26-2-amd64
Reporter: Ricky Chan
Assignee: Alan M. Carroll
Priority: Critical
Fix For: 2.1.8
Attachments: trafficserver.2.1.7.too.many.mimefields.patch
I have 20 servers in a CDN farm which I brought live recently, I have noticed
with in a day 5 servers had this error reported in traffic.out. Essentially
aborting due to assertion failure. The server restarts (from traffic_cop).
This platform has not had any load go through it yet, it's running around
5MB/s a second with around 25 connection per second. So doing much.
I was going to migrate more traffic onto it, but holding off due to this
assertion issue.
Looking at the code, we have:
for (j=0; j block_count; j++) {
... with a condition which breaks out ..
}
ink_release_assert(j block_count)
So for this assert to be hit the entire list must be gone through without
triggering the break clause, i.e. j == block_count
I don't know this code well, is this a real bug or should the assert be there
(or j = block_count)?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-745) Support ssd
[ https://issues.apache.org/jira/browse/TS-745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] mohan_zl updated TS-745: Attachment: ssd_cache.patch Support ssd --- Key: TS-745 URL: https://issues.apache.org/jira/browse/TS-745 Project: Traffic Server Issue Type: New Feature Components: Cache Reporter: mohan_zl Assignee: mohan_zl Attachments: ssd_cache.patch A patch for supporting, not work well for a long time with --enable-debug -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-748) Client side transparency doesn't work on trunk.
Client side transparency doesn't work on trunk. --- Key: TS-748 URL: https://issues.apache.org/jira/browse/TS-748 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 2.1.8 Reporter: Alan M. Carroll Assignee: Alan M. Carroll Fix For: 2.1.8 Client side transparency doesn't work because of permissions problems (setting transparency on the socket fails). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-749) Connection hangs if origin server goes down in the middle of a response
Connection hangs if origin server goes down in the middle of a response --- Key: TS-749 URL: https://issues.apache.org/jira/browse/TS-749 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 2.1.4, 2.1.5, 2.1.6, 2.1.7 Environment: Any Reporter: William Bardwell If you start a long HTTP response, and then kill the origin web server, the connection to the client goes idle. It looks like TS would accept further commands, but the client doesn't know that the response is finished. After a few minutes an idle timeout will close the connection. Instead the connection should be closed, allowing the client to notice that it only got a partial response in some cases, and letting it proceed in all cases. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-716) Crash in Continuation::handleEvent
[
https://issues.apache.org/jira/browse/TS-716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13024824#comment-13024824
]
Kissdev commented on TS-716:
Under the same load and configuration, the new testing shows the trunk does not
crash,but throws the following errors after running for serveral minutes
(leading to ERR_CLIENT_ABORT and ERR_CONNECT_FAIL response for all requests):
[Apr 25 23:35:07.867] Manager {46969923497680} NOTE: [LocalManager::startProxy]
Launching ts process
Layout configuration
--prefix = '/ats'
--exec_prefix = '/ats'
--bindir = '/ats/bin'
--sbindir = '/ats/bin'
--sysconfdir = '/ats/etc/trafficserver'
--datadir = '/ats/share/trafficserver'
--includedir = '/ats/include'
--libdir = '/ats/lib'
--libexecdir = '/ats/libexec/trafficserver'
--localstatedir = '/ats/var'
--runtimedir = '/ats/var/trafficserver'
--logdir = '/ats/var/log/trafficserver'
--mandir = '/ats/man'
--infodir = '/ats/info'
--cachedir = '/ats/var/trafficserver'
[TrafficServer] using root directory '/ats'
[Apr 25 23:35:07.873] Manager {46969923497680} NOTE:
[LocalManager::pollMgmtProcessServer] New process connecting fd '8'
[Apr 25 23:35:07.873] Manager {46969923497680} NOTE: [Alarms::signalAlarm]
Server Process born
[Apr 25 23:35:08.884] {47969045663584} STATUS: opened
/ats/var/log/trafficserver/diags.log
[Apr 25 23:35:08.884] {47969045663584} NOTE: updated diags config
[Apr 25 23:35:08.887] Server {47969045663584} NOTE: cache clustering disabled
[Apr 25 23:35:08.912] Server {47969045663584} NOTE: cache clustering disabled
[Apr 25 23:35:09.056] Server {47969045663584} NOTE: logging initialized[7],
logging_mode = 3
[Apr 25 23:35:09.068] Server {47969045663584} NOTE: traffic server running
[Apr 25 23:35:15.375] Server {1132697920} NOTE: cache enabled
FATAL: MultiCache.cc:1343: failed assert `!out of space`
/ats/bin/traffic_server - STACK TRACE:
/ats/lib/libtsutil.so.2(ink_fatal_va+0xb6)[0x2ba0a9359306]
/ats/lib/libtsutil.so.2(ink_fatal+0xe4)[0x2ba0a93594de]
/ats/lib/libtsutil.so.2(_ink_assert+0xaa)[0x2ba0a935783e]
/ats/bin/traffic_server(_ZN14MultiCacheBase5allocEPii+0xa4)[0x638e98]
/ats/bin/traffic_server(_ZN18HostDBContinuation8dnsEventEiP7HostEnt+0x944)[0x631424]
/ats/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6f)[0x4d25ff]
/ats/bin/traffic_server(_ZN8DNSEntry9postEventEiP5Event+0xda)[0x63eea8]
/ats/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6f)[0x4d25ff]
/ats/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x11e)[0x6f4184]
/ats/bin/traffic_server(_ZN7EThread7executeEv+0x94)[0x6f4376]
/ats/bin/traffic_server[0x6f3ad6]
/lib64/libpthread.so.0[0x35808064a7]
/lib64/libc.so.6(clone+0x6d)[0x357fcd3c2d]
Crash in Continuation::handleEvent
---
Key: TS-716
URL: https://issues.apache.org/jira/browse/TS-716
Project: Traffic Server
Issue Type: Bug
Components: Core
Affects Versions: 2.1.7
Environment: CentOS 5.4 x86_64, 6 * 2T SATA Disks, 48G Memory
Reporter: Kissdev
Assignee: John Plevyak
Priority: Critical
Fix For: 2.1.8
Attachments: crasher.patch
ATS crashes with the following configuration:
- reverse proxy , storage: 6 raw devices (6*2T), 1 partition (2T)
- remap config:regex_map http://(.*) http://$1
The load : about 100Mbps, requests for top 4000 internet sites, mainly
html,js,pictures,flashes
Detail of crashes by core dump:
crash #1:
{code}
#0 0x004dd17a in Continuation::handleEvent (this=0x2aaaba364cb0,
event=1, data=0x90f7170) at I_Continuation.h:146
146 I_Continuation.h: No such file or directory.
in I_Continuation.h
(gdb) bt
#0 0x004dd17a in Continuation::handleEvent (this=0x2aaaba364cb0,
event=1, data=0x90f7170) at I_Continuation.h:146
#1 0x00702b80 in EThread::process_event (this=0x2b101010,
e=0x90f7170, calling_code=1) at UnixEThread.cc:140
#2 0x00702fa1 in EThread::execute (this=0x2b101010) at
UnixEThread.cc:232
#3 0x007024d2 in spawn_thread_internal (a=0x8d94a70) at Thread.cc:85
#4 0x0036ebc064a7 in start_thread () from /lib64/libpthread.so.0
#5 0x0036eb0d3c2d in clone () from /lib64/libc.so.6
(gdb) frame 0
#0 0x004dd17a in Continuation::handleEvent (this=0x2aaaba364cb0,
event=1, data=0x90f7170) at I_Continuation.h:146
146 in I_Continuation.h
(gdb) print *this
$1 = {force_VFPT_to_top = {_vptr.force_VFPT_to_top = 0x2aaaba360a11},
handler = virtual table offset -1157442765409226770, this adjustment
-1157442765409226769,
handler_name = 0xefefefefefefefef Address 0xefefefefefefefef out of
bounds, mutex = {m_ptr = 0xefefefefefefefef}, link = {SLinkContinuation
= {
[jira] [Commented] (TS-748) Client side transparency doesn't work on trunk.
[ https://issues.apache.org/jira/browse/TS-748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13024829#comment-13024829 ] Alan M. Carroll commented on TS-748: It is unclear what changed caused this problem. The problem doesn't exist in 2.1.7 even on the same system. The best I have discovered is the threading structure must have changed and connections are now handled in a different thread which doesn't have the required privilege. The direct cause is that client transparency depends on POSIX capabilities. These are thread local, while the user id is per process. What happens is that various threads are started while the server has the root user id. Later this is changed to the specified non-root user and as a result the capabilities in all threads are cleared, leaving the client connection serving thread unable to set transparency. The main thread, because of code put in for transparency, continues to have the appropriate privileges. To make the same logic work in other threads, it would be necessary to make the privilege adjustments when the thread starts, as the actual change happens at an effectively random time and synchronizing that would be unfeasibly painful. However, if we are going to make the privilege adjustments at the start of every thread, it seems better to just make the adjustment before spawning any threads. I don't see a good reason to not do so, and it seems better to not have threads suddenly change user id at a random time in the middle of their operation. Client side transparency doesn't work on trunk. --- Key: TS-748 URL: https://issues.apache.org/jira/browse/TS-748 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 2.1.8 Reporter: Alan M. Carroll Assignee: Alan M. Carroll Fix For: 2.1.8 Client side transparency doesn't work because of permissions problems (setting transparency on the socket fails). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-749) Connection hangs if origin server goes down in the middle of a response
[ https://issues.apache.org/jira/browse/TS-749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Bardwell updated TS-749: Attachment: svn.diff This patch fixes it for me, and seems reasonable. It just turns off keep-alive before the release of the connections. Connection hangs if origin server goes down in the middle of a response --- Key: TS-749 URL: https://issues.apache.org/jira/browse/TS-749 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 2.1.7, 2.1.6, 2.1.5, 2.1.4 Environment: Any Reporter: William Bardwell Attachments: svn.diff If you start a long HTTP response, and then kill the origin web server, the connection to the client goes idle. It looks like TS would accept further commands, but the client doesn't know that the response is finished. After a few minutes an idle timeout will close the connection. Instead the connection should be closed, allowing the client to notice that it only got a partial response in some cases, and letting it proceed in all cases. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-716) Crash in Continuation::handleEvent
[
https://issues.apache.org/jira/browse/TS-716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13024834#comment-13024834
]
John Plevyak commented on TS-716:
-
Just to confirm that this is not a configuration problem, try increasing:
CONFIG proxy.config.hostdb.size INT 20
CONFIG proxy.config.hostdb.storage_size INT 33554432
by say a factor of 10.
john
Crash in Continuation::handleEvent
---
Key: TS-716
URL: https://issues.apache.org/jira/browse/TS-716
Project: Traffic Server
Issue Type: Bug
Components: Core
Affects Versions: 2.1.7
Environment: CentOS 5.4 x86_64, 6 * 2T SATA Disks, 48G Memory
Reporter: Kissdev
Assignee: John Plevyak
Priority: Critical
Fix For: 2.1.8
Attachments: crasher.patch
ATS crashes with the following configuration:
- reverse proxy , storage: 6 raw devices (6*2T), 1 partition (2T)
- remap config:regex_map http://(.*) http://$1
The load : about 100Mbps, requests for top 4000 internet sites, mainly
html,js,pictures,flashes
Detail of crashes by core dump:
crash #1:
{code}
#0 0x004dd17a in Continuation::handleEvent (this=0x2aaaba364cb0,
event=1, data=0x90f7170) at I_Continuation.h:146
146 I_Continuation.h: No such file or directory.
in I_Continuation.h
(gdb) bt
#0 0x004dd17a in Continuation::handleEvent (this=0x2aaaba364cb0,
event=1, data=0x90f7170) at I_Continuation.h:146
#1 0x00702b80 in EThread::process_event (this=0x2b101010,
e=0x90f7170, calling_code=1) at UnixEThread.cc:140
#2 0x00702fa1 in EThread::execute (this=0x2b101010) at
UnixEThread.cc:232
#3 0x007024d2 in spawn_thread_internal (a=0x8d94a70) at Thread.cc:85
#4 0x0036ebc064a7 in start_thread () from /lib64/libpthread.so.0
#5 0x0036eb0d3c2d in clone () from /lib64/libc.so.6
(gdb) frame 0
#0 0x004dd17a in Continuation::handleEvent (this=0x2aaaba364cb0,
event=1, data=0x90f7170) at I_Continuation.h:146
146 in I_Continuation.h
(gdb) print *this
$1 = {force_VFPT_to_top = {_vptr.force_VFPT_to_top = 0x2aaaba360a11},
handler = virtual table offset -1157442765409226770, this adjustment
-1157442765409226769,
handler_name = 0xefefefefefefefef Address 0xefefefefefefefef out of
bounds, mutex = {m_ptr = 0xefefefefefefefef}, link = {SLinkContinuation
= {
next = 0xefefefefefefefef}, prev = 0xefefefefefefefef}}
{code}
crash #2:
{code}
(gdb) bt
#0 0x004dd17a in Continuation::handleEvent (this=0x2aaabc0bce80,
event=1, data=0x154b5a80) at I_Continuation.h:146
#1 0x006db290 in InactivityCop::check_inactivity (this=0x154c8730,
event=2, e=0x154b5a80) at UnixNet.cc:57
#2 0x004dd1bb in Continuation::handleEvent (this=0x154c8730,
event=2, data=0x154b5a80) at I_Continuation.h:146
#3 0x00702b80 in EThread::process_event (this=0x2b606010,
e=0x154b5a80, calling_code=2) at UnixEThread.cc:140
#4 0x00702ec2 in EThread::execute (this=0x2b606010) at
UnixEThread.cc:217
#5 0x007024d2 in spawn_thread_internal (a=0x154852c0) at Thread.cc:85
#6 0x0036ebc064a7 in start_thread () from /lib64/libpthread.so.0
#7 0x0036eb0d3c2d in clone () from /lib64/libc.so.6
(gdb) frame 0
#0 0x004dd17a in Continuation::handleEvent (this=0x2aaabc0bce80,
event=1, data=0x154b5a80) at I_Continuation.h:146
146 in I_Continuation.h
(gdb) print *this
$1 = {force_VFPT_to_top = {_vptr.force_VFPT_to_top = 0x16280061},
handler = virtual table offset -1157442765409226770, this adjustment
-1157442765409226769,
handler_name = 0xefefefefefefefef Address 0xefefefefefefefef out of
bounds, mutex = {m_ptr = 0xefefefefefefefef}, link = {SLinkContinuation
= {
next = 0xefefefefefefefef}, prev = 0xefefefefefefefef}}
(gdb)
{code}
crash #3:
{code}
(gdb) bt
#0 0x004dd17a in Continuation::handleEvent (this=0x2aaab45d3a10,
event=2, data=0x5631120) at I_Continuation.h:146
#1 0x00702b80 in EThread::process_event (this=0x2abfc010,
e=0x5631120, calling_code=2) at UnixEThread.cc:140
#2 0x00702ec2 in EThread::execute (this=0x2abfc010) at
UnixEThread.cc:217
#3 0x0050917c in main (argc=3, argv=0x7fff0af6e3b8) at Main.cc:1962
(gdb) frame 0
#0 0x004dd17a in Continuation::handleEvent (this=0x2aaab45d3a10,
event=2, data=0x5631120) at I_Continuation.h:146
146 in I_Continuation.h
(gdb) print *this
$1 = {force_VFPT_to_top = {_vptr.force_VFPT_to_top = 0x2aaab45df291},
handler = virtual table offset -1157442765409226770, this adjustment
-1157442765409226769,
handler_name = 0xefefefefefefefef Address 0xefefefefefefefef out of
bounds, mutex = {m_ptr = 0xefefefefefefefef}, link = {SLinkContinuation
= {
[jira] [Commented] (TS-745) Support ssd
[ https://issues.apache.org/jira/browse/TS-745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13024839#comment-13024839 ] John Plevyak commented on TS-745: - Overall several comments: 1) Once we get it working we need to reorganize the patch so that we avoid code duplication. 2) The limitation of a single SSD is probably overly restrictive. SSDs are relatively inexpensive now and it is very likely that folks will want to have 1 per disk or better yet some combination of SSD and SATA. 3) The code uses xmalloc to store docs and creates another CacheVC to do the write in the background. We would be using the various allocators rather than xmalloc and we should be adding states rather than creating another CacheVC. The write can occur after calling back the user, so there will be no additional latency. 4) The code doesn't seem to have provision for handling multi-fragment documents. There are some tradeoffs there, but in any case the issues needs to be considered. Handling of multi-fragment documents requires tighter control over when the write is done and if and when it is successful. Again, this would indicate we should be doing the write on the same CacheVC in additional states. 5) The code needs to deal collisions after the initial directory is looked up. Again, this would be easier if the SSD code was operating in the same CacheVC. Please think about these comments. Let's use http://codereview.appspot.com/ for detailed reviews. I have already added traffic server as a repository. I have imported the patch as well, but I think we still have some design discussion to do before we can get into the details. Support ssd --- Key: TS-745 URL: https://issues.apache.org/jira/browse/TS-745 Project: Traffic Server Issue Type: New Feature Components: Cache Reporter: mohan_zl Assignee: mohan_zl Attachments: ssd_cache.patch A patch for supporting, not work well for a long time with --enable-debug -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-750) TS does not fail-over if one origin server for a 2 address hostname goes down
TS does not fail-over if one origin server for a 2 address hostname goes down - Key: TS-750 URL: https://issues.apache.org/jira/browse/TS-750 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 2.1.4, 2.1.5, 2.1.6, 2.1.7 Environment: Any Reporter: William Bardwell If you have a hostname that looks up to 2 addresses, and you make a request to TS for something at that hostname, and then kill the origin server at which ever address TS just talked to, your next request (if done promptly) will fail with a 502 status code. A request made after that will fail-over correctly. Tracing the code I see it doing proxy.config.http.connect_attempts_max_retries retries to the same address, and it does call code to mark the address down after proxy.config.http.connect_attempts_rr_retries attempts, the address does not get marked down. (The code calls HttpTransact::delete_server_rr_entry() which does TRANSACT_RETURN(OS_RR_MARK_DOWN, ReDNSRoundRobin) which in turns tries to set up the marking with HTTP_SM_SET_DEFAULT_HANDLER(HttpSM::state_mark_os_down), but state_mark_os_down never actually happens, instead it just goes into the retry, I think based on ReDNSRoundRobin doing s-next_action = how_to_open_connection(s).) I have a fix, although it doesn't seem like quite the right way to go about things, but I can't figure out how to get state_mark_os_down to get called at the right time. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-750) TS does not fail-over if one origin server for a 2 address hostname goes down
[ https://issues.apache.org/jira/browse/TS-750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Bardwell updated TS-750: Attachment: svn.diff2 This fixes it, but there might be a better way that just gets state_os_mark_down() to be called properly. TS does not fail-over if one origin server for a 2 address hostname goes down - Key: TS-750 URL: https://issues.apache.org/jira/browse/TS-750 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 2.1.7, 2.1.6, 2.1.5, 2.1.4 Environment: Any Reporter: William Bardwell Attachments: svn.diff2 If you have a hostname that looks up to 2 addresses, and you make a request to TS for something at that hostname, and then kill the origin server at which ever address TS just talked to, your next request (if done promptly) will fail with a 502 status code. A request made after that will fail-over correctly. Tracing the code I see it doing proxy.config.http.connect_attempts_max_retries retries to the same address, and it does call code to mark the address down after proxy.config.http.connect_attempts_rr_retries attempts, the address does not get marked down. (The code calls HttpTransact::delete_server_rr_entry() which does TRANSACT_RETURN(OS_RR_MARK_DOWN, ReDNSRoundRobin) which in turns tries to set up the marking with HTTP_SM_SET_DEFAULT_HANDLER(HttpSM::state_mark_os_down), but state_mark_os_down never actually happens, instead it just goes into the retry, I think based on ReDNSRoundRobin doing s-next_action = how_to_open_connection(s).) I have a fix, although it doesn't seem like quite the right way to go about things, but I can't figure out how to get state_mark_os_down to get called at the right time. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-752) cache scan issues
[ https://issues.apache.org/jira/browse/TS-752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Bardwell updated TS-752: Attachment: svn4.diff This fixes the crash on fast cache scan canceling. cache scan issues - Key: TS-752 URL: https://issues.apache.org/jira/browse/TS-752 Project: Traffic Server Issue Type: Bug Components: Cache Affects Versions: 2.1.7, 2.1.6, 2.1.5, 2.1.4 Environment: Any Reporter: William Bardwell Attachments: svn4.diff Using the CacheScan plugin APIs I found a few issues. Issue 1 is that if you cancel a scan really quickly you can get a NULL dereference, the fix for this is easy. Issue 2 is that the cache scan code can skip over entries if the initial header overlaps a buffer boundary. Issue 3 is that the cache scan code is crazy slow if your cache is not full, it still scans everything. I will attach a patch for Issues 2 3 mixed together... -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-752) cache scan issues
[ https://issues.apache.org/jira/browse/TS-752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Bardwell updated TS-752: Attachment: svn4.diff Lets try that again, previous patch was not properly ported to trunk. cache scan issues - Key: TS-752 URL: https://issues.apache.org/jira/browse/TS-752 Project: Traffic Server Issue Type: Bug Components: Cache Affects Versions: 2.1.7, 2.1.6, 2.1.5, 2.1.4 Environment: Any Reporter: William Bardwell Attachments: svn4.diff, svn4.diff Using the CacheScan plugin APIs I found a few issues. Issue 1 is that if you cancel a scan really quickly you can get a NULL dereference, the fix for this is easy. Issue 2 is that the cache scan code can skip over entries if the initial header overlaps a buffer boundary. Issue 3 is that the cache scan code is crazy slow if your cache is not full, it still scans everything. I will attach a patch for Issues 2 3 mixed together... -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-752) cache scan issues
[ https://issues.apache.org/jira/browse/TS-752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Bardwell updated TS-752: Attachment: svn5.diff Big fix to speed up cache scanning by skipping sections that have no entries in it. (A fancier system could be made but this helps for non-full caches and shouldn't be too expensive for empty ones.) And includes a fix to read part of a buffer when an entry overlaps a partition/volume boundary. cache scan issues - Key: TS-752 URL: https://issues.apache.org/jira/browse/TS-752 Project: Traffic Server Issue Type: Bug Components: Cache Affects Versions: 2.1.7, 2.1.6, 2.1.5, 2.1.4 Environment: Any Reporter: William Bardwell Attachments: svn4.diff, svn4.diff, svn5.diff Using the CacheScan plugin APIs I found a few issues. Issue 1 is that if you cancel a scan really quickly you can get a NULL dereference, the fix for this is easy. Issue 2 is that the cache scan code can skip over entries if the initial header overlaps a buffer boundary. Issue 3 is that the cache scan code is crazy slow if your cache is not full, it still scans everything. I will attach a patch for Issues 2 3 mixed together... -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-748) Client side transparency doesn't work on trunk.
[ https://issues.apache.org/jira/browse/TS-748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll resolved TS-748. Resolution: Fixed Committed fix. Some additional POSIX capability support code was added, and the user id changed was moved to before any thread spawns. Client side transparency doesn't work on trunk. --- Key: TS-748 URL: https://issues.apache.org/jira/browse/TS-748 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 2.1.8 Reporter: Alan M. Carroll Assignee: Alan M. Carroll Fix For: 2.1.8 Client side transparency doesn't work because of permissions problems (setting transparency on the socket fails). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-654) request for support of Layer7 http health checking for Origin Servers
[ https://issues.apache.org/jira/browse/TS-654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] mohan_zl updated TS-654: Attachment: health_check.patch Add a new patch to keep up with trunk, right now the autoconfig is not supported, that is , if you want to update the health check config file, you must trafficserver restart, the traffic_line -x can't do it.. request for support of Layer7 http health checking for Origin Servers - Key: TS-654 URL: https://issues.apache.org/jira/browse/TS-654 Project: Traffic Server Issue Type: New Feature Components: HTTP Affects Versions: 2.1.5 Reporter: Zhao Yongming Fix For: 2.1.9 Attachments: health_check.patch this ticket is for the L7 health checking project: https://cwiki.apache.org/confluence/display/TS/HttpHealthCheck -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-654) request for support of Layer7 http health checking for Origin Servers
[ https://issues.apache.org/jira/browse/TS-654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] mohan_zl updated TS-654: Attachment: (was: Passive-L7-Health-Check.patch) request for support of Layer7 http health checking for Origin Servers - Key: TS-654 URL: https://issues.apache.org/jira/browse/TS-654 Project: Traffic Server Issue Type: New Feature Components: HTTP Affects Versions: 2.1.5 Reporter: Zhao Yongming Fix For: 2.1.9 Attachments: health_check.patch this ticket is for the L7 health checking project: https://cwiki.apache.org/confluence/display/TS/HttpHealthCheck -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
