[
https://issues.apache.org/jira/browse/THRIFT-749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12852705#action_12852705
]
Tim Wilson-Brown edited comment on THRIFT-749 at 4/2/10 4:50 AM:
-----------------------------------------------------------------
In the generated code I have from Thrift r760184, the sequence is:
oprot_->writeMessageEnd();
oprot_->getTransport() ->flush();
oprot_->getTransport() ->writeEnd();
writeEnd() is a no-op in most transports, but where it is implemented
(TPipedTransport), it does its own flush.
I wasn't aware of the flush in the processor - sorry for taking up your time.
There is no compelling issue - this was one potential cause of some issues I'm
having with Thrift and fork.
The proven causes are [THRIFT-747] and [THRIFT-748].
was (Author: twilsonb):
In the generated code I have from Thrift r760184, the sequence is:
oprot_->writeMessageEnd();
oprot_->getTransport()->flush();
oprot_->getTransport()->writeEnd();
writeEnd() is a no-op in most transports, but where it is implemented
(TPipedTransport), it does its own flush.
I wasn't aware of the flush in the processor - sorry for taking up your time.
There is no compelling issue - this was one potential cause of some issues I'm
having with Thrift and fork.
The proven causes are [THRIFT-747] and [THRIFT-748].
> 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.
