Re: [Firebird-devel] Response to op_get_segment under with compression on
Maybe surprisingly, when the blob I'm trying to read is all zeros, the server responds in expected way. Random bytes make it all fall apart. I have a simple test app, that surfaces it. If some core devs would like to have a look from the other side. -- Mgr. Jiří Činčura Independent IT Specialist -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] RFC: Timeouts
On 18-8-2016 00:19, Vlad Khorsun wrote: >> Considering API calls, network times, etc, I doubt < 1s would be good >> for anything here. > >What about 2500 ms ? :) > >I don't insist on milliseconds for statement timeouts. I want to hear more > opinions. Btw, PG uses milliseconds :) I'd prefer milliseconds, because that is the right granularity, and the JDBC API also uses timeouts in milliseconds. Mark -- Mark Rotteveel -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] RFC: Timeouts
On 18-8-2016 17:51, Dimitry Sibiryakov wrote: >On the other hand it provides DBA a choice, not kill the query > unconditionally. >You are not going to make an option "log, but do not kill", are you?.. > >> PS why do you waste my time speaking about feature you not going to use ? > >Because you asked for comments (which is very unusual) and no real > consumers for this > feature are anywhere nearby. > At my job, we use timeouts for all resources we use; if it takes too long we abort and either fail the task at hand (and maybe return a fallback) or retry it at a later time. If we fail too often in a short time window, we back off for a while. If we consistently get timeouts, then it is time to consider either increasing the timeout, or investigating why a certain action takes too long. We do this to achieve better throughput, ensure snappy response for customer facing applications (even if that means that occasionally part of the information is missing), **and** reducing loads on the services, database, etc that we use. Mark -- Mark Rotteveel -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] Stopping firebird.exe
Hi *, if I start firebird using "firebird.exe -a", is there a way to stop it? In a scripted way. -- Mgr. Jiří Činčura Independent IT Specialist -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] RFC: Timeouts
On 21-8-2016 09:39, Mark Rotteveel wrote: > On 18-8-2016 00:19, Vlad Khorsun wrote: >>> Considering API calls, network times, etc, I doubt < 1s would be good >>> for anything here. >> >>What about 2500 ms ? :) >> >>I don't insist on milliseconds for statement timeouts. I want to hear more >> opinions. Btw, PG uses milliseconds :) > > I'd prefer milliseconds, because that is the right granularity, and the > JDBC API also uses timeouts in milliseconds. Actually, I'm wrong, for query timeout JDBC expects seconds... In any case, it says: """ Sets the number of seconds the driver will wait for a Statement object to execute to the given number of seconds. By default there is no limit on the amount of time allowed for a running statement to complete. If the limit is exceeded, an SQLTimeoutException is thrown. A JDBC driver must apply this limit to the execute, executeQuery and executeUpdate methods. Note: JDBC driver implementations may also apply this limit to ResultSet methods (consult your driver vendor documentation for details). Note: In the case of Statement batching, it is implementation defined as to whether the time-out is applied to individual SQL commands added via the addBatch method or to the entire batch of SQL commands invoked by the executeBatch method (consult your driver vendor documentation for details). """ I think a single timeout that is measured over the entire execute + all fetches is too brittle. I'd prefer if the timeout is applied to the execute and each individual fetch. Mark -- Mark Rotteveel -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] Response to op_get_segment under with compression on
Hi *, when I try to read response to op_get_segment (which works fine without compression), after flush I only get op_response (9) code and then nothing is in the stream. The next piece I'm trying to read is 4 bytes/integer for object handle of generic response. So I clearly get some response from server (I get the op_response), aka flush went fine, server was able to process my request and it was properly compressed. But why I get only the 4 bytes and nothing more to get complete response? I'm running x64 3.0.0.32483. -- Mgr. Jiří Činčura Independent IT Specialist -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
