Hi again,

While testing the code (now that it doesn't appear to be randomly breaking any more) something interesting occurred to me. A lot of the time, while the fbk to restore is not yet entirely sent, Firebird is responding with 0 requested bytes from stdin. Granted, some of the time there is output information in verbose mode but if the last sent packet is 32kb, there is no real chance that would produce more than 2-3 lines of output without further input.

Now, granted, the amount of those meaningless packets will depend highly on network speed, server hardware/load and so on but I'm thinking of introducing an option like 'throttleMsec' to do Thread.sleep() if we get a totally empty packet (probably 0 by default, but 15msec seems to drop pointless round-trips from 1 in 2 to about 1 in 5 in my specific setup). Any thoughts on that?

I also thought about waiting after we send information to the server but that would require the code to get a lot smarter an adapt to what's happening (for one thing, the server often accepts more than Short.MAX_VALUE bytes so waiting in between the packets would be pointless).

2016-02-17 22:15 GMT+02:00 Ivan Arabadzhiev <intelrullz@...>:

Yep, got that - the .net implementation was actually quite easy to read :) I have pushed another rework of the restore flow which should finally fix normal restore for good.

Compiled version is available at https://drive.google.com/folderview?id=0BxNlh1_CctC4N1RsLWRLaUZTSHM&usp=sharing

The dummy is used as follows :

java -cp "jaybird-full-3.0.0-SNAPSHOT.jar:dummy1-0.1.0-SNAPSHOT-standalone.jar" dummy1.core <the available options>

There is a helpfile, but :

  -p, --port PORT             3050       Firebird port
 -u, --user USER             SYSDBA     Firebird user
 -k, --key PASSWORD          masterkey  Firebird password
 -f, --backupfile file-path  test.fbk   The .fbk file to use for backup/restore
 -d, --database db-path      test.fdb
 -h, --host HOST             127.0.0.1  Hostname/IP of the Firebird host
 -l, --log logfile-path                 File to use for the verbose output of a restore operation
 -v, --verbose                          Verbose output of a restore operation (has no effect on backup). Will use stdout by default
 -b, --backup                           We would like to backup a databasse
 -r, --restore                          A restore function would take place
 -o, --replace                          A restore with enabled overwrite
 -g, --gzip                             Whether to use the built-in GZIP I/O streams in the JVM

Obviously, one of -o/-r/-b needs to be specified, if your test setup happens to match the defaults - everything else can be skipped.

PS While testing the dummy I did notice that the way I'm currently expecting to hit EOF doesn't work with GZIPInputStream. I'm thinking I can wrap the input in a BufferedInputStream so the code can 'if(read() < 0) quit; else reset()' after each read but, Alf willing, I'll be asleep in 15 minutes so it won't be tonight :) In the mean time - the other stuff should be working and somewhat stable.

2016-02-17 21:42 GMT+02:00 Jiří Činčura jiri@... [Firebird-Java] <Firebird-Java@yahoogroups.com>:

 

> I can, and I have. In fact you are a big part of why I got to a working
> solution so fast :)

:)

For backup there's just isc_info_svc_to_eof. That's fine-ish.
Restore sucks. You need to keep asking for next buffer from server or
you finish the file and then eventually wait isc_info_svc_line returning
zero lines.

--
Mgr. Jiří Činčura
Independent IT Specialist