rust-web3 icon indicating copy to clipboard operation
rust-web3 copied to clipboard

A zombie connection occurs with the filter.logs function.

Open usd-yamazaki opened this issue 7 years ago • 4 comments
trafficstars

This problem also occurs on both Windows and Ubuntu. I am using the following crate.

  • jsonrpc-core 8.0.2 (git+https://github.com/paritytech/jsonrpc)
  • jsonrpc-http-server 8.0.1 (git+https://github.com/paritytech/jsonrpc)
  • jsonrpc-macros 8.0.1 (git+https://github.com/paritytech/jsonrpc)
  • web3 0.3.0 (registry+https://github.com/rust-lang/crates.io-index)

I am making a server program using jsonrpc-http-server. When there is a request from the client, the server accesses the parity and returns the acquired value.

When calling BaseFilter's logs function in the program, If there are a large number of result logs, the connection with Parity will remain and will remain. Finally, a "Too many open files" error occurs and you can not connect to Parity.

For example, this function works normally if the result is "Logs: 1" If the result is "Logs: 13530", a zombie connection will occur.

fn get_logs(web3: &Web3<web3::transports::Http>) {
    let filter_build = FilterBuilder::default()
        .topics(None, Some(vec![H256::from("0x000000000000000000000000a6e345c5f3cc2801f4892b6a67a670d897303d0d")]), None, None)
        .from_block(BlockNumber::Number(0))
        .build();
    let filter = web3.eth_filter().create_logs_filter(filter_build).wait().unwrap();
    let result = filter.logs().wait().unwrap();

    println!("Logs: {:?}", result.len());
}

However, this problem only occurs when calling the logs function on jsonrpc-http-server, otherwise it does not occur. I'm sorry if it is not a problem of rust-web3.

usd-yamazaki avatar Apr 10 '18 06:04 usd-yamazaki

Interesting might be an issue with web3 client library or http server. Perhaps the payload is just too big. Will investigate when I have a bit more time.

tomusdrw avatar Apr 10 '18 07:04 tomusdrw

I tried searching boundary values using "limit" of FilterBuilder.

In fact it is happening at smaller values, In "Logs: 9" it works fine In the case of "Logs: 10", a zombie connection occurred.

Furthermore, even when limit is set to 1, if you call it several times a second, A zombie connection occurred.

usd-yamazaki avatar Apr 11 '18 06:04 usd-yamazaki

For "Logs: 9", the data size is 7972 bytes For "Logs: 10" it was 8854 bytes. Perhaps there is a boundary of 8192 bytes.

usd-yamazaki avatar Apr 11 '18 06:04 usd-yamazaki

@usd-yamazaki thanks for the input, will try out to reproduce today. Perhaps we can create a mock server (say in node.js) to figure out if the issue is part of the http server or rust-web3 (I suspect the latter)

tomusdrw avatar Apr 11 '18 07:04 tomusdrw