You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@thrift.apache.org by "James E. King III (JIRA)" <ji...@apache.org> on 2019/01/03 13:22:00 UTC

[jira] [Closed] (THRIFT-1619) Implement TSocket buffer methods

     [ https://issues.apache.org/jira/browse/THRIFT-1619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James E. King III closed THRIFT-1619.
-------------------------------------
    Resolution: Invalid
      Assignee: James E. King III

I see no evidence of a rewind.  The TMessage is stored and the remainder of the message read normally.  No rewind is happening.

> Implement TSocket buffer methods
> --------------------------------
>
>                 Key: THRIFT-1619
>                 URL: https://issues.apache.org/jira/browse/THRIFT-1619
>             Project: Thrift
>          Issue Type: Improvement
>          Components: Java - Library
>    Affects Versions: 0.7
>            Reporter: mck
>            Assignee: James E. King III
>            Priority: Minor
>
> TSocket buffers its input socket.
> Therefore getBuffer(), getBufferPosition(), getBytesRemainingInBuffer(), and consumeBuffer(..) can be implemented.
> Use case:
> We use our own multiplexing code, something similar to THRIFT-66.
> The server has a default service registered so that if a vanilla (non-multiplexing) client tries to access the server it still works.
> But for it to work the server must rewind the inputTransport (since it called readMessageBegin() to check for the multiplexing TMessage type).
> Currently we've solved it by using reflection to get access to TIOStreamTransport.inputStream_ but this isn't elegant. With getBuffer() implemented something more elegant could be provided... (although two new methods TSocket.mark(int) and TSocket.reset() would be even more elegant particularly performance-wise).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)