long running transaction can block processing

[jeffallen]

in service_test.go, make slowContractFunc sleep for testInterval/2. In that case, every time it is pre-run to try to put it into a block, it will fail to get into the block, resulting in "Got more transactions than what I can do in half the blockInterval".

On the next attempt to create a block, the same transaction will use up the whole time again, and no other transactions will be taken.

[ineiti]

I see two possibilities:

1. we simply add the last transaction, even if it goes over the time-budget
2. if it is only one transaction, and it is over the time budget, silently discard it from the input buffer

I have a preference for 2.

[jeffallen]

Discarding transactions is not currently possible with createStateChanges, see #1409 for notes on how this has to be attacked.

[kc1212]

I see two possibilities:

1. we simply add the last transaction, even if it goes over the time-budget

2. if it is only one transaction, and it is over the time budget, silently discard it from the input buffer

I have a preference for 2.

Either way it's the leader that decides the time budget with s.createStateChanges(..., blockinterval/2) hence which transactions to include. The followers do not check, they use noTimeout as the time budget. I think it's safe to say any changes to how to leader decides which transactions to include is backward-compatible, so we'll move this issue after v3.