Alex,
something interesting. After I've put the message for op_fetch into
output stream, I also added, just as I'm trying to bisect it, 1k of 0s
at the end (and these will be compressed). Then not only the
op_fetch_response code came, but also the rest of the response.
--
Mgr. Jiří Činčura
Indep
On 08/22/2016 11:53 AM, Jiří Činčura wrote:
with some debugging code turned on.
Can I turn that on?
Please :)
diff --git a/src/remote/protocol.cpp b/src/remote/protocol.cpp
index 042d879..7f0648b 100644
--- a/src/remote/protocol.cpp
+++ b/src/remote/protocol.cpp
@@ -285,6 +285,10 @@ bool_t x
> In that case please send me (preferably not too big, I use CDMA
> connection now) test database.
> Artificial test with select from rdb$database shows no errors. I've
> checked in on latest FB3 and it passed also fine.
I'm sending you privately test app (403kB) that surfaces it. But it's
On 08/22/2016 11:53 AM, Jiří Činčura wrote:
>> with some debugging code turned on.
> Can I turn that on?
>
>> So must say I see no problems with protocol.
> Oh no, sure. I'm not saying something is wrong with the protocol. It
> works fine when I turn compression off or if the data is all 0 (see my
On 08/22/2016 11:44 AM, Jiří Činčura wrote:
> OK, I was able to strip it down to single select on a fresh empty
> database.
>
> If I do "select
> x'681B03629D04E427E638384EF8117D8BC7B7312B7B03D0DB210DB2C4561A770283CADA0DB5A7E0A305E56C93DAFB91EF065F7C5B28EE94654A264190501FCFCBBF36C92E3570D51FD58C259
> with some debugging code turned on.
Can I turn that on?
> So must say I see no problems with protocol.
Oh no, sure. I'm not saying something is wrong with the protocol. It
works fine when I turn compression off or if the data is all 0 (see my
previous email).
BTW me running the "select first
OK, I was able to strip it down to single select on a fresh empty
database.
If I do "select
x'681B03629D04E427E638384EF8117D8BC7B7312B7B03D0DB210DB2C4561A770283CADA0DB5A7E0A305E56C93DAFB91EF065F7C5B28EE94654A264190501FCFCBBF36C92E3570D51FD58C2594963D00257BC2BDF59D1BD9943674C28F665053E5169FD2A43163
On 08/21/2016 12:51 PM, Jiří Činčura wrote:
> 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 o
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
