Hi guys, thanks for the support. I'm still considering open-sourcing the site; keep in mind the only reason it's not yet is because my last worker got voted out. Keeping it closed source protected me from giving everything away without getting paid.

Last week, I ran into server issues/constraints (as mentioned, server upgrade is on the wishlist) which caused some downtime. I then upgraded the bitshares node to latest version so I could have access to the max-ops-per-account option to get memory usage under control. I had postponed updating the node because I'd seen API changes on GitHub over the last few months and was concerned some of them could be breaking changes.

I've found the issue with the assets pages and some APIs was due to a change in get_market_history_api, now fixed.

Let me know if there are any other issues.

Hi @roadscape and all, i am about to submit a worker proposal that includes work in the new explorer: http://bitshares-explorer.io:9009/#/dashboard.

the worker is mainly for bitshares core development, the explorer development is just 1 of the tasks i was planning to work on. i started to work in a block explorer when the community claimed for it by different channels. it is not my intention to compete with cryptofresh for a worker or anything like that. i really like cryptofresh and it is probably the bitshares company standard. if it is updated and open source my explorer project will never started.

in the other hand i will love to continue with bitshares-explorer.io. we can maybe find a solution working together somehow.

let me know.

Great work, @oxarbitrage. I'll think about how we could collaborate, but there's room for more than one block explorer. A healthy ecosystem should have options!

Just brought CF back up. As far as I can determine, a double-produced block caused issues with cf sync, which then led to an out-of-memory condition. The node just finished replaying and the site is caught up with the chain.

I'd like to start a dialogue about cryptofresh and its future. My witness has been voted out for a while so I'm maintaining cryptofresh.com (plus witness node) out of pocket, including dev hours and hardware upgrades.

IMV the witness was a convenient method of funding maintenance. I understand the desire for separation of roles, but I have experience with both so it avoided worker overhead. Would voters support a cryptofresh.com maintenance worker?

I'm also evaluating ways to continue development of cryptofresh. Here's a brief list of pending projects/todos:

 - fork handling
 - upgrading node, evaluate new APIs & check compatibility
 - upgrade server
 - improve rate bridging calcs
 - load charts faster (async generation)
 - tuning views
 - check API load/performance
 - open source
 - custom reports
 - worker caching bug

Any other issues I should know about?

It has been fixed, thanks

Yes, I caught this the other day. For some reason Cryptofresh was having a hard time calculating USD values for some of the more illiquid tokens.. now you will see a '--' where dollar value could not be calculated!

Surprised to see my worker (Blockchain Explorer and API Development) back in, even though there's only a few days left.. these weeks are busy but I'll gladly put this pay towards more updates in June!

we need more posts like this! Let's stop arguing between ourselves when we all want the same thing, and recognize people such as Ronny that devote an incredible amount of energy to making this project successful. I agree with btswolf that the project wouldn't be the same without him.

Go Ronny!

Ya'll really kept me on my toes the last few weeks.. only on BitShares can devs
be regularly fired and hired the same day, yet be expected to plan weeks ahead.. :p

Regardless.. it was overall a positive experience & I learned a lot! And most
importantly, I accomplished a lot I wouldn't have without the worker, things that
continue to provide ongoing value for the community.

Thank you for that opportunity.

But it does seem like the right time to shift priorities.
Returns from this worker are diminishing, and I'm running low on steam.

Of course, I'll continue working on cryptofresh, at my own pace.
As always, I'll be focusing my skills and energy where they are most effective.

It's great to see the true leaders stepping up in this community.
Hopefully you can figure out the funding situation :p
Just glad to see @svk's worker (critical) is still in..

Quote from: cube on April 20, 2016, 11:51:14 pm

I tested it and confirm the issue to do with low resources - ie low cpu power or bandwidth.

It's strange that it occurs on exactly same block: 2821722.

I replaced the blockchain folder on one node with a full backup, then it runs well. And the other node is catching up as well.

Trying to reproduce.

//Update:
Reproduced.
Most probably you're correct. Lots of these kind of entries in the log:

Code: [Select]

2016-04-21T12:03:29 p2p:message read_loop fetch_next_batch_of_ ] sync: sending a request for the next items after 002b0e5a206413b5f17ee209705b51b3cb90fa4c to peer 188.165.233.53:54674, (full request is ["002b0e48227e963b3fa7ebede652334b696e59d8","002b0e528f2ba15ab707c3646bb8b07a0007615f","002b0e571c3f3d9a9c7713ddacd69531c615ebe3","002b0e5966422ef475e20ef2c96acdaec7d51127","002b0e5a206413b5f17ee209705b51b3cb90fa4c"])                     node.cpp:2427

2016-04-21T12:03:30 p2p:terminate_inactive_connections_loop terminate_inactive_c ] Disconnecting peer 188.165.233.53:54674 because they didn't respond to my request for sync item ids after ["002b0e48227e963b3fa7ebede652334b696e59d8","002b0e528f2ba15ab707c3646bb8b07a0007615f","002b0e571cf3d9a9c7713ddacd69531c615ebe3","002b0e5966422ef475e20ef2c96acdaec7d51127","002b0e5a206413b5f17ee209705b51b3cb90fa4c"]                   node.cpp:1403


I think it can be optimized. In the code :

Code: [Select]

        // set the ignored request time out to 1 second.  When we request a block
        // or transaction from a peer, this timeout determines how long we wait for them
        // to reply before we give up and ask another peer for the item.
        // Ideally this should be significantly shorter than the block interval, because
        // we'd like to realize the block isn't coming and fetch it from a different
        // peer before the next block comes in.  At the current target of 3 second blocks,
        // 1 second seems reasonable.  When we get closer to our eventual target of 1 second
        // blocks, this will need to be re-evaluated (i.e., can we set the timeout to 500ms
        // and still handle normal network & processing delays without excessive disconnects)
        fc::microseconds active_ignored_request_timeout = fc::seconds(1);
The timeout applies even when syncing (batch fetching), but 1 second is perhaps too short for that?
Further thinking: why it happens magically on block 2821722 ?
@cube @arhag @pc @theoretical @bytemaster

The block after this one contains a huge operation.. 1MB of text in the asset description field. Very likely the source of the problem.
http://cryptofresh.com/b/2821723