[jira] [Updated] (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:all-tabpanel
]
Yakov Markovitch updated TS-702:
Attachment: (was: trafficserver.2.1.7.too.many.mimefields.patch)
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
Priority: Critical
Fix For: 2.1.8
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-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:all-tabpanel
]
Yakov Markovitch updated TS-702:
Attachment: trafficserver.2.1.7.too.many.mimefields.patch
Updated patch for mime_hdr_field_block_list_adjust
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
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] [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=13022780#comment-13022780
]
Yakov Markovitch commented on TS-702:
-
I've attached an updated patch with all issues addressed.
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
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] [Created] (TS-745) Support ssd
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 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] [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_support.patch The demand is described in https://cwiki.apache.org/TS/ssdsupport.html, now i write a simple patch for supporting ssd. This is obviously a temporary scheme, and now it only supports one ssd plus several sata. 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_support.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] [Commented] (TS-475) HTTP SM should support efficient byte range requests
[ https://issues.apache.org/jira/browse/TS-475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13023059#comment-13023059 ] vijaya bhaskar mamidi commented on TS-475: -- Eric, I am looking at some of the stuff that i can work on. Are you working on this? if not, can i take over ? HTTP SM should support efficient byte range requests Key: TS-475 URL: https://issues.apache.org/jira/browse/TS-475 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: Leif Hedstrom Assignee: Eric Balsa Priority: Critical Fix For: 2.1.9 The cache has support for efficiently locate a particular range in the cached object, but the HTTP SM does not support this. In order to make Range: request efficient (particularly on large objects), the SM should support this new cache feature. -- 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_support2.patch Add missing file 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_support.patch, ssd_support2.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] [Commented] (TS-475) HTTP SM should support efficient byte range requests
[ https://issues.apache.org/jira/browse/TS-475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13023071#comment-13023071 ] Eric Balsa commented on TS-475: --- VJ, yes, you can take it or we can collaborate to finish it up. I would say my local copy is 80% there but needs some work and i've been stupid busy with work baby. Here's what i've done so far: John (and me to a small extent) got CacheVC::do_io_pread() working on the cache so we can now (theoretically, though barely tested) seek to arbitrary locations on a cache object. The SM currently uses a transform for handling Range requests. The logic is something like: * lookup full object from cache * check for range header * setup a transform hook to be handled during HttpTunnel ... * do_io_read() on the object and hand that vio to the transform hook * transform the object by re-reading certain headers, parse the C-L Range headers, and do Range: transform work What I was working on was changing the model to store the Range: logic in the SM rather than inside the Transform (RangeTransform objects). In HttpSM::do_range_setup_if_necessary() i bounce into a couple other fns to parse the Range: header similar to what the transform does now (almost 1:1 with RangeTransform:: and setup various Range settings in the t_state) Then, when we read from the cache, we can simply do a do_io_pread() with the proper known offsets. Problems: 1) This only handles the simple case of Range:bytes=1-10 but not the complicated case of Range:bytes=1-10,70-80,100-500 . I think this would satisfy 90% of the uses cases (Leif thinks most clients don't do anything too crazy :) ). For the complicated case, I still am using the transform (if # of Ranges 1). Ideally, we should somehow handle this with only object::do_io_pread()s but the issue, as I see it, is we are so far down in processing (at the point where we tunnel the cache object to the client), that it would be difficult (I think) to re-tunnel multiple partial contents (along with each added Range content separator). Just a pita b/c you have work with the VIO, loop(read the i-th range, add separators, i++), and finally, make sure you have the C-L right. I'm sure it's doable, but I punted and figured I would just hand it to the existing transform but then complicated Range: requests would still do_io_read() the whole object. 2) My patch needs a ton of cleanup but IIRC (been a few weeks) I had it serving the simple case without any transforms using do_io_pread() along with the right C-L (always a good thing), but i'll email it to you and you give give it a whirl. 3) ...more We can chat on IRC if you want to talk more about this. --Eric HTTP SM should support efficient byte range requests Key: TS-475 URL: https://issues.apache.org/jira/browse/TS-475 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: Leif Hedstrom Assignee: Eric Balsa Priority: Critical Fix For: 2.1.9 The cache has support for efficiently locate a particular range in the cached object, but the HTTP SM does not support this. In order to make Range: request efficient (particularly on large objects), the SM should support this new cache feature. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-746) Not possible to completel delete e.g. the Query part of a URL via plugins
[
https://issues.apache.org/jira/browse/TS-746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom reassigned TS-746:
Assignee: Leif Hedstrom
Not possible to completel delete e.g. the Query part of a URL via plugins
-
Key: TS-746
URL: https://issues.apache.org/jira/browse/TS-746
Project: Traffic Server
Issue Type: Improvement
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
Fix For: 2.1.8
If you use an API call like
{code}
TSUrlHttpQuerySet(rri-requestBufp, rri-requestUrl, , 0);
{code}
the resulting request will still include a '?' e.g.
{code}
GET /? HTTP/1.1
{code}
I believe the same is true for other similar URL APIs, e.g. Path and matrix
parameters. We really ought to have a way to completely delete the component.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-746) Not possible to completel delete e.g. the Query part of a URL via plugins
[
https://issues.apache.org/jira/browse/TS-746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-746:
-
Issue Type: Improvement (was: Bug)
Not possible to completel delete e.g. the Query part of a URL via plugins
-
Key: TS-746
URL: https://issues.apache.org/jira/browse/TS-746
Project: Traffic Server
Issue Type: Improvement
Reporter: Leif Hedstrom
Fix For: 2.1.8
If you use an API call like
{code}
TSUrlHttpQuerySet(rri-requestBufp, rri-requestUrl, , 0);
{code}
the resulting request will still include a '?' e.g.
{code}
GET /? HTTP/1.1
{code}
I believe the same is true for other similar URL APIs, e.g. Path and matrix
parameters. We really ought to have a way to completely delete the component.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-746) Not possible to completel delete e.g. the Query part of a URL via plugins
[
https://issues.apache.org/jira/browse/TS-746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-746:
-
Description:
If you use an API call like
{code}
TSUrlHttpQuerySet(rri-requestBufp, rri-requestUrl, , 0);
{code}
the resulting request will still include a '?' e.g.
{code}
GET /? HTTP/1.1
{code}
I believe the same is true for other similar URL APIs matrix parameters and
port. We really ought to have a way to completely delete the component.
was:
If you use an API call like
{code}
TSUrlHttpQuerySet(rri-requestBufp, rri-requestUrl, , 0);
{code}
the resulting request will still include a '?' e.g.
{code}
GET /? HTTP/1.1
{code}
I believe the same is true for other similar URL APIs, e.g. Path and matrix
parameters. We really ought to have a way to completely delete the component.
Not possible to completel delete e.g. the Query part of a URL via plugins
-
Key: TS-746
URL: https://issues.apache.org/jira/browse/TS-746
Project: Traffic Server
Issue Type: Improvement
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
Fix For: 2.1.8
If you use an API call like
{code}
TSUrlHttpQuerySet(rri-requestBufp, rri-requestUrl, , 0);
{code}
the resulting request will still include a '?' e.g.
{code}
GET /? HTTP/1.1
{code}
I believe the same is true for other similar URL APIs matrix parameters and
port. We really ought to have a way to completely delete the component.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-746) Not possible to completel delete e.g. the Query part of a URL via plugins
[
https://issues.apache.org/jira/browse/TS-746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-746:
-
Attachment: TS-746.diff
I'm thinking of an approach to change the semantics of these URL setter APIs
slightly, to have a NULL string argument mean nuke me completely. E.g.
TSUrlHttpQuerySet(rri-requestBufp, rri-requestUrl, NULL, 0);
See proposed patch for details. This has the advantage that no APIs changes,
and there are no changes to the core (the core already handles the NULL pointer
properly).
Not possible to completel delete e.g. the Query part of a URL via plugins
-
Key: TS-746
URL: https://issues.apache.org/jira/browse/TS-746
Project: Traffic Server
Issue Type: Improvement
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
Fix For: 2.1.8
Attachments: TS-746.diff
If you use an API call like
{code}
TSUrlHttpQuerySet(rri-requestBufp, rri-requestUrl, , 0);
{code}
the resulting request will still include a '?' e.g.
{code}
GET /? HTTP/1.1
{code}
I believe the same is true for other similar URL APIs matrix parameters and
port. We really ought to have a way to completely delete the component.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
