This is primarily a sync issue, it is not likely on a fully-synced node (with the exception of a DOS attack).

I am planning on fixing it once I return from holiday. I'm not sure the exact approach yet, but basically we need to more closely manage connection behavior. The last fix was a quick patch to prevent block starvation due to lack of polling and did not address the more general issue of DOS.

e


> On Jul 3, 2015, at 12:56 PM, mlmikael <mlmikael@???> wrote:
>
>> On 2015-07-03 16:27, Eric Voskuil wrote:
>> It would be fine, apart from the possibility of database corruption
>> from hard shutdown. But I have not seen that happen. I have not
>> reviewed the source thoroughly enough to exclude the possibility.
>> I wouldn't ca it an architectural issue, it's an implementation issue.
>> The current code is not robust enough and was recently incomplete in
>> terms of sync.
>
> What do you see as best way to make also this really work? (Store the queue to persistence, or/and somehow implement overload protection on the entry points?)
>
> Do you think anyone may be intending to rework this this year? I mean it's like a ticking bomb in a sense, while complete reliability is possible.
>
>
> Btw, can reorganization or particular node API use trig it specifically, or is it mostly performance imbalance, that is particularly prevalent during sync only?
>
> Thanks
>