You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@thrift.apache.org by "Emily Leathers (JIRA)" <ji...@apache.org> on 2009/12/02 03:44:20 UTC

[jira] Created: (THRIFT-639) Timeouts Interrupting Read Can Leave Data in Read Queue, Corrupting Later Reads

Timeouts Interrupting Read Can Leave Data in Read Queue, Corrupting Later Reads
-------------------------------------------------------------------------------

                 Key: THRIFT-639
                 URL: https://issues.apache.org/jira/browse/THRIFT-639
             Project: Thrift
          Issue Type: Bug
          Components: Library (Ruby)
    Affects Versions: 0.1, 0.2
            Reporter: Emily Leathers
            Priority: Minor


When a Timeout interrupts a client that is reading a Thrift response, the client may leave unread bytes in the read queue.  If this transport instance/queue is reused in a later request, the extra bytes will corrupt that later response.

We're currently working around this by having the rescue blocks of our TimeoutExceptions close the transport so that subsequent requests will have to create a new, clean one.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Commented: (THRIFT-639) Timeouts Interrupting Read Can Leave Data in Read Queue, Corrupting Later Reads

Posted by "Bryan Duxbury (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/THRIFT-639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12910402#action_12910402 ] 

Bryan Duxbury commented on THRIFT-639:
--------------------------------------

I think any of the transports can experience this problem. If you stop reading when there's still data waiting to be read, then go on with writing, there will still be data to be read, but it'll be from the previous response.

> Timeouts Interrupting Read Can Leave Data in Read Queue, Corrupting Later Reads
> -------------------------------------------------------------------------------
>
>                 Key: THRIFT-639
>                 URL: https://issues.apache.org/jira/browse/THRIFT-639
>             Project: Thrift
>          Issue Type: Bug
>          Components: Ruby - Library
>    Affects Versions: 0.1, 0.2
>            Reporter: Emily Leathers
>            Priority: Minor
>
> When a Timeout interrupts a client that is reading a Thrift response, the client may leave unread bytes in the read queue.  If this transport instance/queue is reused in a later request, the extra bytes will corrupt that later response.
> We're currently working around this by having the rescue blocks of our TimeoutExceptions close the transport so that subsequent requests will have to create a new, clean one.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Commented: (THRIFT-639) Timeouts Interrupting Read Can Leave Data in Read Queue, Corrupting Later Reads

Posted by "Ryan King (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/THRIFT-639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12910395#action_12910395 ] 

Ryan King commented on THRIFT-639:
----------------------------------

What transport are you using?

> Timeouts Interrupting Read Can Leave Data in Read Queue, Corrupting Later Reads
> -------------------------------------------------------------------------------
>
>                 Key: THRIFT-639
>                 URL: https://issues.apache.org/jira/browse/THRIFT-639
>             Project: Thrift
>          Issue Type: Bug
>          Components: Ruby - Library
>    Affects Versions: 0.1, 0.2
>            Reporter: Emily Leathers
>            Priority: Minor
>
> When a Timeout interrupts a client that is reading a Thrift response, the client may leave unread bytes in the read queue.  If this transport instance/queue is reused in a later request, the extra bytes will corrupt that later response.
> We're currently working around this by having the rescue blocks of our TimeoutExceptions close the transport so that subsequent requests will have to create a new, clean one.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.