<CAGiAgVdoVrJqET5xrFDkQGYhQLhkqW3R2cESeR95MN5r0y=Sjg@...> <56cadfc7.4b0a6b0a.5f31e.fffff818SMTPIN_ADDED_MISSING@...> <CAGiAgVcJt=NwQeqK=AhMZnQJucFZ7cVqC37+881UAfkrbxfHKA@...>
Message-ID: <8638d712b76a153801a451bd61a3591b@...>
X-Sender: mark@...
User-Agent: RoundCube Webmail/0.2

On Mon, 22 Feb 2016 12:50:37 +0200, "Ivan Arabadzhiev intelrullz@...
[Firebird-Java]" <Firebird-Java@yahoogroups.com> wrote:

> Hi again,
> 1 mark()/reset() is why I switched to BufferedInputStream to begin with

and

> it appears to be holding as a solution. I went through the GNU
> implementation and it appears to be simple enough to not add any
> significant overhead. I could check for markSupported() but I'd rather

have

> a specific stream on top (perhaps add a check to not wrap when given
> BufferedInputStream), mostly because restore is ... horrific :) and that
> way I can rely on some consistency

I had missed you already wrapped in a BufferedInputStream. Sounds good to
me then.

> 2 I did look at fbsvcmgr.cpp and noticed it passes isc_info_svc_timeout,
> which I couldn't exactly figure out how to add (byte sequence is

[64,4,0,1]

> and I got lost in Jaybird's way of figuring out what param is what).
> Fortunately, it appears not to matter as my last commit at 2 am seems to

be

> the final piece (more explanation coming in a few lines)

The ArgumentType and ParameterBufferMetaData is pretty new because it was
necessary to address changes in the parameter buffers between Firebird 2.x
and Firebird 3, it might need some further improvements.

isc_info_svc_timeout = 64 and it is - by the looks of it - a
TraditionalDpb (at least in Firebird 2.5 and earlier), but it looks like it
is missing a few bytes, because 4 means length 4 with 0,1{,0,0} (2 bytes
missing) = 256. You should be able to add it with addArgument(int
argumentType, int value).

I also took another look at your earlier question about ByteArrayArgument,
and you should be OK if you replace the current check with the check that
is also in StringArgument (so that it allows TraditionalDpb, Wide and
StringSpb). And as far as I can tell you should be able to use arrays of
size up to 65536 for Firebird 2.5, and even up to Integer.MAX_VALUE for
Firebird 3 (instead of just 32768).

> 3 I live in Emacs/Chrome and I don't really do raw Java that often (read
> 'haven't tuned it that much') so at PR time I will once again pass

things

> through the Eclipse formater, which I will tune however you wish (if you
> want, you could pass me a settings file to use) - last time I made a new
> workspace specifically for jaybird. IntellyJ is also not a problem

You can find the formatting definitions in build/formatting in the
repository.

> 4 After the commit last night I left my machine restoring the

problematic

> case while(true) and woke up to it still going, so I'm thinking of
> extracting FBBackupManagerBase, formatting squashing and making a PR so

we

> can continue the discussion there?

Sounds good to me.

> Now ... for the restore :
> Long version (feel free to skip) goes like this - I've been tech support
> since I was ~13 years old so backups have caused me a lot of relief (and
> pain over the years) and I did jump at StreamingBackups when they were
> introduced. In fact, I'm the one mentioned in the first .Net provider
> release to support them :) So when I finally started on a Jaybird, even
> before Jiri suggested, I figured I'd take a look at an implementation

I've

> personally tested. Now, it would appear I haven't used it enough to hit

the

> bug I described last time, because the code starts with adding the

request

> codes and skips isc_info_svc_line if the backup isn't verbose (which
> fbsvcmgr.cpp doesn't do). For whatever reason, the FirebirdSQL engine

would

> decide from time to time that it has had enough input if

isc_info_svc_line

> isn't present in the request. Didn't find a pattern but no amount of
> restarting or deleting the .fdb file helps and some combinations of
> fbk+engine would not restore more than 2-3 times in a row.
> --------------------------------------------------------------------
> Short version :
> isc_info_svc_line needs to be present in the SRB even on non-verbose
> backups or not even god knows if restore would ever finish. Thought of
> reporting it to firebird-devel but it appears to be the way fbsvcmgr

works

> so that might be the actually expected behavior. It also appears to help
> with my concerns about receiving a lot of 0-length stdin responses and
> drops CPU load dramatically (both on the JVM and the FirebirdSQL side).

The

> effect is not *that* noticeable on your typical server but one of my

test

> machines is a Cubieboard2 which experiences about half the load after

the

> last commit :)

Great find. It makes me wonder if there is anything that needs to be
changed in the original backup/restore implementation as well.

Mark