October 2017

has anyone an idea why the following basic piece of code accessing the libbitcoin-server blockchain.fetch_last_height isn't working? https://pastebin.com/0MwAm1f9 The output is: Connecting to tcp://mainnet1.libbitcoin.net:9091 Sending blockchain.fetch_last_height requester.receiveTimeOut: 2000 Reply error: EAGAIN Received null I'm new to Kotlin..

Dunno, maybe set the timeout before calling send?

@lclc yeah, try increasing the timeout and seeing if it helps

The value of the timeout (2 secs) should be way more than sufficient, especially locally. Just wondering if it might be 0 by default. If the receive is non-blocking then yes, would need to loop it, as it would return immediately. Not sure how those ZMQ behaviors are encapsulated.

agreed. since it errored with EAGAIN, i would assume it's non-blocking, but hard to know being unfamiliar with the API

Thanks for the inputs. When I don't set a timeout it blocks forever. Also with looping a get a endless loop of EAGAIN every 2 seconds.. But at least now I know the libbitcoin side should be good / sending just "blockchain.fetch_last_height" should do it I'll try more and ask the Kotlin/ZMQ guys too

@lclc if you're familiar with wireshark, or tcpdump, try making sure the client side send is matching what bx would send

good morning

morning

okies

Good idea, will try

So I compared what I sends & receives with bx and what from my Kotlin call. The request is slightly different with bx, but looking at the source code of bx I don't see why.

Maybe someone has an idea. I'm using jeromq:0.4.2 (which is based on libzmq 4.1.7), libbitcoin is using libzmq 4.2.3 (from what I see). I assume that should not be the problem (/they don't break the protocol in minor releases).

@lclc, those look pretty similar, up to where the second one cut off anyway

Yes that's the answer of the server missing there.

"A libbitcoin query message (request and response) body contains a command frame and a payload frame. The command frame is a text string that identifies the type of query, such as "blockchain.fetch_block_header". "

@evoskuil I'm not familiar with zmq protocol wrappers, so I'm not sure if that part looks sane. It's possible there's a setting or something that is causing a mismatch in @lclc's case

I was responding to the comment about the server responding with the command, which is by design.

of course

I've merged an important patch to database/version3. This fixes a address history/balance tracking concurrency bug that can lead to lost entries. There is also an unrelated concurrency patch that fixes undefined behavior in the case of reads during a block pop (reorg) where the reorg affects entries in the hash table collision list (other than the first entry). Many thanks to Suvorov Ivan [https://github.com/magisterRab] for reporting and helping to resolve this issue! I'll be porting these fixes to master. In the mean time please update and resync v3 community servers.