RFR 8185719 [testlibrary] : RMI TestSocketFactory does not flush

[Daniel Fuchs]

Hi Roger,

I wonder if the MatchReplaceOutputStream should store the
partial match index at the time the partial bytes are flushed
in order to verify that this was indeed a partial match,
and report an error if it later finds that flush() was indeed
called during a full match? The potential Error to throw could
be created and recorded in flush() in order to diagnose
the offending flush() call...

On the other hand to do this properly you'd probably need
to maintain a stack of partial match indexes and corresponding
potential Errors to throw in case flush() is called again with
a partial match while the previous partial matching hasn't
been invalidated yet...

I mean - if your matched bytes are stg like  0 0 0 6
and the stream looks like:

   3 0 0 <flush> 0 <flush> ...

then either 6 or 0 0 6 coming after  the second flush would
make the test fail to find & replace the full match...

But maybe it's not worth it if you are sure that flush() cannot
be called during a full match/replace sequence?

best regards,

-- daniel



On 02/08/2017 15:21, Roger Riggs wrote:
> Please review a correction in the RMI TestSocketFactory 
> MatchReplaceOutputStream to correctly flush
> partial matches.  It can cause hangs when the one or more bytes before a 
> flush are a partial match
> for the pattern and the consumer is waiting for the pending bytes.
> 
> Webrev:
>    http://cr.openjdk.java.net/~rriggs/webrev-flush-8185719/index.html
> 
> Issue:
>    https://bugs.openjdk.java.net/browse/JDK-8185719
> 
> Thanks, Roger
>