Watching a filter causes parity RPC to become unresponsive

[tymat]

Steps to reproduce

1. Start up parity

parity -j --jsonrpc-port 8545 daemon /tmp/parity.pid

2. In JavaScript (nodejs REPL)

var Web3 = require('web3')
var web3 = new Web3()
web3.setProvider(new web3.providers.HttpProvider('http://localhost:8545'))

var filter = web3.eth.filter();
filter.watch(function(error, result){
  if (!error)
    console.log(result);
});
web3.eth.blockNumber

Parity becomes unresponsive. Subsequent new connections to parity are also unresponsive.

appuser@parity01:~$ node
> var Web3 = require('web3')
undefined
> var web3 = new Web3()
undefined
> web3.setProvider(new web3.providers.HttpProvider('http://localhost:8545'))
undefined
>
> web3.eth.blockNumber

[gavofyork]

since a new filter will first call back with all matching events to date, you're asking parity to collate every log that has ever happened in frontier and homestead over ~1,300,000 blocks. that takes a while. while we can make sure other requests work ok, that request will necessarily take some time to collate since there are an awful lot of logs in the frontier/homestead chain.

if you restrict the filter to recent blocks and/or particular contracts/events then it'll complete a lot faster. e.g. restrict the events to those in the homestead chain:

var Web3 = require('web3')
var web3 = new Web3()
web3.setProvider(new web3.providers.HttpProvider('http://localhost:8545'))

var filter = web3.eth.filter({fromBlock: 1150000});
filter.watch(function(error, result){
  if (!error)
    console.log(result);
});
web3.eth.blockNumber

[tomusdrw]

So I guess when you don't specify any filter object it should default to:

{ from: 'latest', to: 'latest' }

https://github.com/ethereum/wiki/wiki/JavaScript-API#web3ethfilter

In parity the default was

{ from: 'earliest', to: 'latest' }

It should be fixed with #948.