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

Tim Wilson-Brown reopened THRIFT-749:
-------------------------------------


Sorry, I didn't see Adam's and David's comments about discarding the data in 
wBuf_ when I closed this bug.

At the very least, we should document (& fix where necessary) buffered 
transport behaviour.
The options for Buffered Transports are:
  * flush in destructor - likely to throw exceptions in destructor
  * write in destructor - can throw exceptions in destructor
  * discard data in wBuf_ - no guarantee that data is written to underlying 
transport
    - (but thrift processors currently have an explicit flush after every 
message)

Whatever option is chosen, we can implement Adam's suggestion that "callers 
should still be encouraged to explicitly call flush() before destroying any 
transport."

I can't see a way to guarantee that we don't throw exceptions in destructors, 
and guarantee that we write out all the buffered data.
How do other C++ networking libraries do it?

> C++ TBufferedTransports do not flush their buffers on delete
> ------------------------------------------------------------
>
>                 Key: THRIFT-749
>                 URL: https://issues.apache.org/jira/browse/THRIFT-749
>             Project: Thrift
>          Issue Type: Bug
>          Components: Library (C++)
>    Affects Versions: 0.2, 0.3
>         Environment: Cygwin 1.7.1 on Windows XP SP3, Thrift 0.2.0 & r760184 & 
> Trunk 
>            Reporter: Tim Wilson-Brown
>            Priority: Trivial
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> Edit: replaced 'close underlying transport' with 'flush buffers'
> The C++ TBufferedTransports (such as TBufferedTransport) do not flush their 
> buffers on delete.
> The workaround is to manually flush the TBufferedTransport before deleting 
> it. If the TBufferedTransport owned the last instance of the underlying 
> transport, it will be deleted and close itself.
> This may be worth fixing - at the moment, substituting a buffered TSocket for 
> an unbuffered one changes the behaviour on delete.
> Data may be buffered then lost when the TBufferedTransport is deleted.
> This is undesirable  - they should behave identically except for the 
> buffering.

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

Reply via email to