On 13.01.2015 15:30, Jiří Činčura wrote: > Hi *, > > When I'm doing restore using service_mgr and isc_info_svc_stdin. I'm facing > some issue, but I don't know what's wrong. > > My backup file is 13824 bytes. When I query Firebird server it asks for 8k > data (aka file will be sent in two chunks). > > My first query contains only isc_info_svc_stdin (not isc_info_svc_line, I > don't want to get progress messages back) and I get 8k as a response. > Then I prepare the data and query again, this time with isc_info_svc_line and > the data in SPB. > The server responds with another 8k request. So send 5632 bytes I have left. > Now the server responds with length 0. > > Now because I've sent whole file and there are no messages (no > isc_info_svc_line in query, see above) and length is 0, I just disconnect > (op_service_detach, op_disconnect). But this leaves the restore incomplete. > Of course when I delay the disconnect few ms, it's fine. > > What else should I wait for? Looking at fbsvcmgr I see in printInfo just if > (stdinRq > 0) check. Basically the same. >
Jiri, when working with services items isc_info_svc_line, isc_info_svc_to_eof and isc_info_svc_get_users (choosing appropriate item is service type dependent) also work as kind of progress / completion indicator. To be sure that service thread finished it's operation you must get empty reply to request for data from service, not accompanied with isc_info_truncated / isc_info_svc_timeout / isc_info_data_not_ready. And yes, certainly getting non-zero reply to isc_info_svc_stdin also means that service is active, but that's not single condition. For example, server may read all gbak data from client and proceed with indexes creation for a rather long time not asking for more data. ------------------------------------------------------------------------------ New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
