You are viewing a single comment's thread from:

RE: Opening an issue to discuss the Condenser/Hivemind problem ... and to find a solution

in Steem Dev4 months ago

Correct, I strongly assume that the measures introduced at the API node to prevent the attack now also cause Hivemind not to receive the data reliably. However, I cannot check this without the help of ety001. I hope he will reply, or we can get in touch in some other way. But perhaps he has already checked this himself. We don't know anything for sure, as nothing is being communicated...

It's very difficult to know where to start. The behaviour is pretty inconsistent. I have been able to observe and reproduce some things, but not others...

Sort:  

Correct, I strongly assume that the measures introduced at the API node to prevent the attack now also cause Hivemind not to receive the data reliably.

Interesting. So, the rate-limiting is too slow for hivemind to keep up(?). I have never learned to understand the hivemind architecture, but that theory is definitely consistent with the link, above. It still appears to be updating, but it's glacially slow. For example, when I glanced at it on the day I posted the comment above, it showed 8 rewards from September 10. Now, it shows 11.

 4 months ago 

the rate-limiting is too slow for hivemind to keep up(?)

Maybe. In addition, the way requests are handled has obviously been changed. I explained here that the batch requests may have been disabled... and also the request limits... maybe all together. But I'm almost convinced that Hivemind itself is fine, except for the caching delays...

The votes are very strange (differences). This is my next step of investigation.