On 17-2-2016 09:54, Ivan Arabadzhiev intelrullz@...
[Firebird-Java] wrote:

> Just a quick status update. I'm now almost happy with how the code looks
> but I have come to a spot where I could use a second opinion on
> InputStream - I chased my restore issues down to the fact that my
> OpenJDK (1.8.0_72, OpenSUSE x64) would start rereading the final block
> over and over and over again if the size the input file happens to be a
> multitude of the buffer. In that same environment, .available() behaves
> as expected so I moved to that. I can (and will) test on every JDK I can
> get my hands on within a few days but I'm open to ideas (or a preferred
> way to do things). Also not sure what would happen with other streams
> (GZIPInputStream also works), which may or may not make sense - other
> compression streams, other sockets and so on.

I'll look it over either today or during the weekend and do some tests.

Please consider carefully if you really want (or need) to use
available(), in my experience using available() is almost always the
wrong choice. For example, some input streams will always report 0 for
available(), and an input stream reporting 0 doesn't mean there is
nothing left to read, just that it will (or might) block on the next read!

Could you point me to the problematic piece of code?

>
> As pushed, it has been tested to backup, restore (with and without
> verbose output), with a small database on
> Linux x64, LI-V2.5.4.26856
> Windows x64, WI-V2.5.5.26952
> Windows x86, WI-V2.5.5.26952
> Linux armv7, LI-V2.5.2.26540
>
> I'll try to upload a .jar later to make it easier for anyone interested
> to test for possible client-side issues with some OS/JVM combo.

Sure, that would be great.

In the mean time, could you take a look at the contributor license
agreement at
https://raw.githubusercontent.com/FirebirdSQL/jaybird/master/licenses/jaybird-icla.txt
and send me a signed copy (either digitally signed with GPG or PGP, or
with a real signature and scanned).

I want to keep options open to release Jaybird under a different open
source license in the future.

Mark
--
Mark Rotteveel