[jira] [Commented] (TS-4317) Cache recovery can stall, prevent disk from becoming ready.
[
https://issues.apache.org/jira/browse/TS-4317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15223090#comment-15223090
]
Alan M. Carroll commented on TS-4317:
-
Set {{recover_wrapped}} in a case where it wraps so the recovery doesn't loop
over the stripe forever.
> Cache recovery can stall, prevent disk from becoming ready.
> ---
>
> Key: TS-4317
> URL: https://issues.apache.org/jira/browse/TS-4317
> Project: Traffic Server
> Issue Type: Bug
> Components: Cache
>Reporter: Alan M. Carroll
>Assignee: Alan M. Carroll
> Fix For: 6.2.0
>
>
> Recovery scans a stripe to find recoverable data. In a certain case it can
> loop forever, although at a limited rate which is not always noticeable. The
> disk, however, never enters a ready state.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (TS-4317) Cache recovery can stall, prevent disk from becoming ready.
[ https://issues.apache.org/jira/browse/TS-4317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll resolved TS-4317. - Resolution: Fixed Fix Version/s: 6.2.0 > Cache recovery can stall, prevent disk from becoming ready. > --- > > Key: TS-4317 > URL: https://issues.apache.org/jira/browse/TS-4317 > Project: Traffic Server > Issue Type: Bug > Components: Cache >Reporter: Alan M. Carroll >Assignee: Alan M. Carroll > Fix For: 6.2.0 > > > Recovery scans a stripe to find recoverable data. In a certain case it can > loop forever, although at a limited rate which is not always noticeable. The > disk, however, never enters a ready state. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-4317) Cache recovery can stall, prevent disk from becoming ready.
[ https://issues.apache.org/jira/browse/TS-4317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll reassigned TS-4317: --- Assignee: Alan M. Carroll > Cache recovery can stall, prevent disk from becoming ready. > --- > > Key: TS-4317 > URL: https://issues.apache.org/jira/browse/TS-4317 > Project: Traffic Server > Issue Type: Bug > Components: Cache >Reporter: Alan M. Carroll >Assignee: Alan M. Carroll > Fix For: 6.2.0 > > > Recovery scans a stripe to find recoverable data. In a certain case it can > loop forever, although at a limited rate which is not always noticeable. The > disk, however, never enters a ready state. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-4317) Cache recovery can stall, prevent disk from becoming ready.
[ https://issues.apache.org/jira/browse/TS-4317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15223089#comment-15223089 ] ASF subversion and git services commented on TS-4317: - Commit 6ff7aafe42d3d51d3ed8d12828920451c1d3fd34 in trafficserver's branch refs/heads/master from [~amc] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=6ff7aaf ] TS-4317: Prevent cache stripe recovery from infinite loop. > Cache recovery can stall, prevent disk from becoming ready. > --- > > Key: TS-4317 > URL: https://issues.apache.org/jira/browse/TS-4317 > Project: Traffic Server > Issue Type: Bug > Components: Cache >Reporter: Alan M. Carroll > Fix For: 6.2.0 > > > Recovery scans a stripe to find recoverable data. In a certain case it can > loop forever, although at a limited rate which is not always noticeable. The > disk, however, never enters a ready state. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-4317) Cache recovery can stall, prevent disk from becoming ready.
Alan M. Carroll created TS-4317: --- Summary: Cache recovery can stall, prevent disk from becoming ready. Key: TS-4317 URL: https://issues.apache.org/jira/browse/TS-4317 Project: Traffic Server Issue Type: Bug Components: Cache Reporter: Alan M. Carroll Recovery scans a stripe to find recoverable data. In a certain case it can loop forever, although at a limited rate which is not always noticeable. The disk, however, never enters a ready state. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-4313) MIMEHdr fails to find header fields
[
https://issues.apache.org/jira/browse/TS-4313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15222915#comment-15222915
]
ASF GitHub Bot commented on TS-4313:
Github user maskit commented on a diff in the pull request:
https://github.com/apache/trafficserver/pull/542#discussion_r58294627
--- Diff: proxy/hdrs/test_mime.cc ---
@@ -0,0 +1,80 @@
+/** @file
+
+ A brief file description
+
+ @section license License
+
+ Licensed to the Apache Software Foundation (ASF) under one
+ or more contributor license agreements. See the NOTICE file
+ distributed with this work for additional information
+ regarding copyright ownership. The ASF licenses this file
+ to you under the Apache License, Version 2.0 (the
+ "License"); you may not use this file except in compliance
+ with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+ */
+
+
+#include "P_Eventsystem.h"
+#include "MIME.h"
+
+static void
+test_mime()
+{
+ int failed = 0;
+ MIMEField *field;
+ MIMEHdr hdr;
+ hdr.create(NULL);
+
+ hdr.field_create("Test1", 5);
+ hdr.field_create("Test2", 5);
+ hdr.field_create("Test3", 5);
+ hdr.field_create("Test4", 5);
+ field = hdr.field_create("Test5", 5);
+ if (!hdr.m_mime->m_first_fblock.contains(field)) {
+printf("FAILED: The field block doesn't contain the field but it
should\n\n");
+failed = 1;
+ }
+ if (hdr.m_mime->m_first_fblock.contains(field + (1L << 32))) {
+printf("FAILED: The field block contains the field but it
shouldn't\n\n");
+failed = 1;
+ }
+
+ int slot_num = mime_hdr_field_slotnum(hdr.m_mime, field);
+ if (slot_num != 4) {
+printf("FAILED: Slot number is %d but should be 4\n\n", slot_num);
+failed = 1;
+ }
+
+ slot_num = mime_hdr_field_slotnum(hdr.m_mime, field + (1L << 32));
+ if (slot_num != -1) {
+printf("FAILED: Slot number is %d but should be -1\n\n", slot_num);
+failed = 1;
+ }
+
+ hdr.destroy();
+
+ printf("*** %s ***\n", (failed ? "FAILED" : "PASSED"));
+ if (failed) {
+exit(1);
+ }
+}
+
+int
+main(int argc, char *argv[])
+{
+ Thread *main_thread = new EThread;
+ main_thread->set_specific();
+ mime_init();
+
+ test_mime();
--- End diff --
Done. :)
> MIMEHdr fails to find header fields
> ---
>
> Key: TS-4313
> URL: https://issues.apache.org/jira/browse/TS-4313
> Project: Traffic Server
> Issue Type: Bug
> Components: MIME
>Reporter: Masakazu Kitajo
>Assignee: Masakazu Kitajo
> Fix For: 6.2.0
>
>
> MIMEHdr fails to find a MIMEField occasionally due to improper type
> conversion.
> It happens if the lower 32 bits of addresses of m_field_slots are the same.
> The logic below picks up wrong block.
> mime_hdr_field_slotnum():
> {code}
> for (fblock = &(mh->m_first_fblock); fblock != NULL; fblock = fblock->m_next)
> {
> MIMEField *first = &(fblock->m_field_slots[0]);
> int block_slot = (int)(field - first); // in units of MIMEField
> if ((block_slot >= 0) && (block_slot < MIME_FIELD_BLOCK_SLOTS))
> {code}
> The type of block_slot should be intptr_t.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-4313) MIMEHdr fails to find header fields
[
https://issues.apache.org/jira/browse/TS-4313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15222914#comment-15222914
]
ASF GitHub Bot commented on TS-4313:
Github user maskit commented on a diff in the pull request:
https://github.com/apache/trafficserver/pull/542#discussion_r58294561
--- Diff: proxy/hdrs/MIME.cc ---
@@ -473,7 +473,8 @@ mime_hdr_set_accelerator_slotnum(MIMEHdrImpl *mh,
int32_t slot_id, uint32_t slot
inline void
mime_hdr_set_accelerators_and_presence_bits(MIMEHdrImpl *mh, MIMEField
*field)
{
- int slot_id, slot_num;
+ int slot_id;
+ ptrdiff_t slot_num;
--- End diff --
I added a comment and filed a jira ticket.
https://issues.apache.org/jira/browse/TS-4316
> MIMEHdr fails to find header fields
> ---
>
> Key: TS-4313
> URL: https://issues.apache.org/jira/browse/TS-4313
> Project: Traffic Server
> Issue Type: Bug
> Components: MIME
>Reporter: Masakazu Kitajo
>Assignee: Masakazu Kitajo
> Fix For: 6.2.0
>
>
> MIMEHdr fails to find a MIMEField occasionally due to improper type
> conversion.
> It happens if the lower 32 bits of addresses of m_field_slots are the same.
> The logic below picks up wrong block.
> mime_hdr_field_slotnum():
> {code}
> for (fblock = &(mh->m_first_fblock); fblock != NULL; fblock = fblock->m_next)
> {
> MIMEField *first = &(fblock->m_field_slots[0]);
> int block_slot = (int)(field - first); // in units of MIMEField
> if ((block_slot >= 0) && (block_slot < MIME_FIELD_BLOCK_SLOTS))
> {code}
> The type of block_slot should be intptr_t.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-4316) Slot accelerator doesn't effect under certain condition
[
https://issues.apache.org/jira/browse/TS-4316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-4316:
--
Fix Version/s: 6.2.0
> Slot accelerator doesn't effect under certain condition
> ---
>
> Key: TS-4316
> URL: https://issues.apache.org/jira/browse/TS-4316
> Project: Traffic Server
> Issue Type: Bug
> Components: MIME
>Reporter: Masakazu Kitajo
> Fix For: 6.2.0
>
>
> Slot accelerators seem to not effect if the stored slot number is 14 or 15.
> This is because {{mime_hdr_set_accelerators_and_presence_bits()}} regards
> slot number 14+ as "unknown" and stores MIME_FIELD_SLOTNUM_UNKNOWN(14) to an
> accelerator, and it causes slower search. Although there is no critical
> effect, it would decreases performance slightly.
> The numbers, 14 and 15, comes from constants below in MIME.h:
> {code}
> #define MIME_FIELD_SLOTNUM_BITS 4
> #define MIME_FIELD_SLOTNUM_MASK ((1 << MIME_FIELD_SLOTNUM_BITS) - 1)
> #define MIME_FIELD_SLOTNUM_MAX (MIME_FIELD_SLOTNUM_MASK - 1)
> #define MIME_FIELD_SLOTNUM_UNKNOWN MIME_FIELD_SLOTNUM_MAX
> {code}
> MIME_FIELD_SLOTNUM_MASK is 15.
> MIME_FIELD_SLOTNUM_MAX is 14.
> MIME_FIELD_SLOTNUM_UNKNOWN is 14 too.
> Though it still needs more careful confirmation, it seems we can simply
> change {{MIME_FIELD_SLOTNUM_UNKNOWN}} to the value of
> {{MIME_FIELD_SLOTNUM_MASK}} (15). But we still cannot use 15.
> To use 15 as a valid slot number in slot accelerators, we need to change
> {{MIME_FIELD_SLOTNUM_UNKNOWN}} to 16 or -1, however it would need to change
> some codes also (not only the number).
> This bug has been found while I was tackling TS-4313.
> https://github.com/apache/trafficserver/pull/542#discussion-diff-58226891
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TS-4316) Slot accelerator doesn't effect under certain condition
Masakazu Kitajo created TS-4316:
---
Summary: Slot accelerator doesn't effect under certain condition
Key: TS-4316
URL: https://issues.apache.org/jira/browse/TS-4316
Project: Traffic Server
Issue Type: Bug
Components: MIME
Reporter: Masakazu Kitajo
Slot accelerators seem to not effect if the stored slot number is 14 or 15.
This is because {{mime_hdr_set_accelerators_and_presence_bits()}} regards slot
number 14+ as "unknown" and stores MIME_FIELD_SLOTNUM_UNKNOWN(14) to an
accelerator, and it causes slower search. Although there is no critical effect,
it would decreases performance slightly.
The numbers, 14 and 15, comes from constants below in MIME.h:
{code}
#define MIME_FIELD_SLOTNUM_BITS 4
#define MIME_FIELD_SLOTNUM_MASK ((1 << MIME_FIELD_SLOTNUM_BITS) - 1)
#define MIME_FIELD_SLOTNUM_MAX (MIME_FIELD_SLOTNUM_MASK - 1)
#define MIME_FIELD_SLOTNUM_UNKNOWN MIME_FIELD_SLOTNUM_MAX
{code}
MIME_FIELD_SLOTNUM_MASK is 15.
MIME_FIELD_SLOTNUM_MAX is 14.
MIME_FIELD_SLOTNUM_UNKNOWN is 14 too.
Though it still needs more careful confirmation, it seems we can simply change
{{MIME_FIELD_SLOTNUM_UNKNOWN}} to the value of {{MIME_FIELD_SLOTNUM_MASK}}
(15). But we still cannot use 15.
To use 15 as a valid slot number in slot accelerators, we need to change
{{MIME_FIELD_SLOTNUM_UNKNOWN}} to 16 or -1, however it would need to change
some codes also (not only the number).
This bug has been found while I was tackling TS-4313.
https://github.com/apache/trafficserver/pull/542#discussion-diff-58226891
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
