You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@trafficserver.apache.org by "Leif Hedstrom (JIRA)" <ji...@apache.org> on 2010/10/28 23:55:19 UTC
[jira] Resolved: (TS-499) INKVIONTodoGet() and INKVIONBytesGet()
returning obsense values ?
[ https://issues.apache.org/jira/browse/TS-499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Leif Hedstrom resolved TS-499.
------------------------------
Resolution: Won't Fix
Resolving this as won't fix, since we're deciding to go with TS-14 instead.
> INKVIONTodoGet() and INKVIONBytesGet() returning obsense values ?
> -----------------------------------------------------------------
>
> Key: TS-499
> URL: https://issues.apache.org/jira/browse/TS-499
> Project: Traffic Server
> Issue Type: Bug
> Affects Versions: 2.0.0
> Reporter: Leif Hedstrom
> Priority: Critical
> Fix For: 2.1.4
>
> Attachments: vio.diff
>
>
> In a transform plugin, with chunked data in the origin response, we're seeing obscene return values from
> INKVIONTodoGet(input_vio);
> e.g. (with some new tracers) using v2.0.1:
> Oct 27 21:34:32.770] Server {139651219031824} DIAG: (null-transform) Entering handle_transform()
> [Oct 27 21:34:32.770] Server {139651219031824} DIAG: (null-transform) toWrite is 2147348222
> [Oct 27 21:34:32.770] Server {139651219031824} DIAG: (null-transform) avail is 2896
> This sort of works in the v2.0.1 branch, but fails completely on trunk (it'll typically completely hang the transaction, due to integer overflows). In my test, using trunk, "toWrite" becomes -1 for the chunked data. A "working" solution is to not let the value overflow, but I think we should figure out why these numbers are so big in the first place (I'm guessing it's something related to 64-bit changes).
> There's a similar issue with INKVIONBytesGet() as well, and possible other APIs ?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.