Bitcoin Forum
May 07, 2024, 12:37:11 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 2 [3]  All
  Print  
Author Topic: [UPDATES] CryptoCoin Explorer III Development Updates (CryptoCoinExplorer.com)  (Read 6908 times)
dreamwatcher (OP)
Legendary
*
Offline Offline

Activity: 1064
Merit: 1000


View Profile WWW
September 28, 2013, 03:08:50 AM
 #41

I may have solved the issue (1) with a combo of using a persistent DB wrapper and specifically forking ledger requests.

I have applied the changes to all the explorers.

Keeping my fingers crossed.  Wink
1715085431
Hero Member
*
Offline Offline

Posts: 1715085431

View Profile Personal Message (Offline)

Ignore
1715085431
Reply with quote  #2

1715085431
Report to moderator
1715085431
Hero Member
*
Offline Offline

Posts: 1715085431

View Profile Personal Message (Offline)

Ignore
1715085431
Reply with quote  #2

1715085431
Report to moderator
There are several different types of Bitcoin clients. The most secure are full nodes like Bitcoin Core, which will follow the rules of the network no matter what miners do. Even if every miner decided to create 1000 bitcoins per block, full nodes would stick to the rules and reject those blocks.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1715085431
Hero Member
*
Offline Offline

Posts: 1715085431

View Profile Personal Message (Offline)

Ignore
1715085431
Reply with quote  #2

1715085431
Report to moderator
dreamwatcher (OP)
Legendary
*
Offline Offline

Activity: 1064
Merit: 1000


View Profile WWW
October 02, 2013, 07:38:55 PM
 #42

UPDATE 10/02/2013:

WHEW!!! What a roller-coaster the last few days. All kinds of bugs and reversions popped up, so the test explorers have been kind of screwy the last few days.

Fixed:

I finally tracked down the exact cause of the thread delay and lockup during a large ledger requests. I had been looking at the wrong part of the server function. The problem was not the threads themselves, but the database connection(s). The persistent database connection appeared to solve the issue, but caused many other issues that made me lose more hair off my already bald head.  Cheesy
It was causing major problems with the dbloader, and the whole of CCE3 went sideways for a bit.

I found the solution within Cherrypy itself (It is amazing how flexible this framework is!!). The web server now issues each thread its own database connection upon creation and closes the connection upon thread closing. No more sessions (cookies on the client end, the entire session tool is disabled) or persistent database connections. CCE3 is back to being the light, efficient application I wanted it to be.

The last major explorer issue is redirecting requests during a orphan database rebuild. I could take the easy way out and set a default error page that states the explorer is rebuilding its database and to try the request again in a few minutes, but that seems kind of a messy way to do it as it would go to that page regardless of the error. However, in the interest of getting the time table back on track, I may have to go that route and patch a more elegant solution after release.

API:

API solution is next on the table. The developers message box access is going to be included in the API as it seems the appropriate place for it.

The API is going to be a separate module from the web server. I feel this is the best way to do this for two reasons.

The API module can be streamlined into handling JSON request/response and Long Polling without all the HTML baggage.

When the need arises I can shut down web services and API services separately as needed. Since other sites depend on the API, if there is a problem with a web server, hopefully I can keep the API up while working on the web server issue. This of course works both ways, no need to take down the web server for an API issue.

Work on the API will begin tonight or tomorrow.

If things go smooth  Roll Eyes    I can see release being on time in the middle of this month.







dreamwatcher (OP)
Legendary
*
Offline Offline

Activity: 1064
Merit: 1000


View Profile WWW
October 07, 2013, 03:44:29 PM
 #43

BottleCaps has been added to the CCE3 test server:

http://cap.cryptocoinexplorer.com
dreamwatcher (OP)
Legendary
*
Offline Offline

Activity: 1064
Merit: 1000


View Profile WWW
October 11, 2013, 12:39:56 AM
 #44

I will be placing i0coin on cryptocoinexplorer.com as one of the coins testing CCE3. This means it is a permanent [art of CCE (as long as it stays active), but to be introduced under the CCE3 test program.

Address will follow the normal CCE address scheme:

i0c.cryptocoinexplorer.com

i0coin has a couple year old block chain, so it will take some time for for the initial database to be built, more than likely overnight and even into tomorrow.

I will probably turn on the web server before the database is complete, but I will post here when complete.
dreamwatcher (OP)
Legendary
*
Offline Offline

Activity: 1064
Merit: 1000


View Profile WWW
October 11, 2013, 05:03:18 PM
 #45

It looks like it will be least a day or two before before the entire i0coin chain (over 900K blocks!!) is fully analyzed and CCE3 has made a complete database.It might be quicker as it hits the range where the coin lost popularity and there is only coinbase transactions.

I will open up the web server later today, though I doubt the database will complete.
dreamwatcher (OP)
Legendary
*
Offline Offline

Activity: 1064
Merit: 1000


View Profile WWW
October 11, 2013, 10:18:41 PM
 #46

To the site-developers out there that would be using the API/Long poll system in CCE3:

How do you want the long poll to work?

As of now it looks like the long poll system will be completely separate from CCE3, it could even be used with the current ABE explorers.

How would you like to handle the variety of coins? Do you have a separate URL for each coin to poll too, or one address and have a JSON field giving the 3 letter code the coin that has polled?

Would just a simple poll with the coin code be enough, or would you like the poll system to push the block information also?

The issue I see here is it does take at least a few seconds for the database loader to process block and transactions information before it becomes available on the explorer and API.

If the Long Poll pushes the block, it will get the block information directly from the daemon and just pass on the RPC response from the daemon.
dreamwatcher (OP)
Legendary
*
Offline Offline

Activity: 1064
Merit: 1000


View Profile WWW
October 11, 2013, 10:20:50 PM
 #47

Looks cool. How about you add one for CGB?

Once CCE3 goes live, I will be adding the majority of coins to CCE.

However, I am slowly adding coins to the test server in an attempt to stress test and see how many coins a server can comfortably serve under cce3.

I will consider adding CGB as one of the test coins when I get ready to add another.

ahmed_bodi
Hero Member
*****
Offline Offline

Activity: 518
Merit: 500

Bitrated user: ahmedbodi.


View Profile
October 11, 2013, 11:13:04 PM
 #48

To the site-developers out there that would be using the API/Long poll system in CCE3:

How do you want the long poll to work?

As of now it looks like the long poll system will be completely separate from CCE3, it could even be used with the current ABE explorers.

How would you like to handle the variety of coins? Do you have a separate URL for each coin to poll too, or one address and have a JSON field giving the 3 letter code the coin that has polled?

Would just a simple poll with the coin code be enough, or would you like the poll system to push the block information also?

The issue I see here is it does take at least a few seconds for the database loader to process block and transactions information before it becomes available on the explorer and API.

If the Long Poll pushes the block, it will get the block information directly from the daemon and just pass on the RPC response from the daemon.

thats a good idea and something i would use if u implement it. The Small delay would be negligable imo. Even the long polling by miners (when notify scripts arent used on a pool) has a small delay. IMO id prefer the method of having a seperate URL per coin.

Bitrated user: ahmedbodi.
dreamwatcher (OP)
Legendary
*
Offline Offline

Activity: 1064
Merit: 1000


View Profile WWW
October 14, 2013, 03:13:57 PM
 #49

Update on i0coin -  The database is still building, it is going much slower then any of the coins I have put on the test server so far. I am not quite sure why, unless the daemon is just a bit slower with RPC responses.

Developers:

What is your opinion on Ubuntu 13.10 server:

Quote
Ubuntu Server 13.10 is available from 17th October; first fully supported release of the new OpenStack Havana, with faster node installation and a new version of Juju that supports ultra-dense containerised application deployment.

http://insights.ubuntu.com/news/ubuntu-13-10-delivers-faster-cloud-setup-and-management-for-scale-out-environments/
RoadTrain
Legendary
*
Offline Offline

Activity: 1386
Merit: 1009


View Profile
October 21, 2013, 05:31:33 PM
 #50

Good progress, just wanted to complain about colors and overall design. Smiley
Could you use something like twitter-bootstrap to build your layout on? Smiley
dreamwatcher (OP)
Legendary
*
Offline Offline

Activity: 1064
Merit: 1000


View Profile WWW
October 21, 2013, 08:44:46 PM
 #51

Good progress, just wanted to complain about colors and overall design. Smiley
Could you use something like twitter-bootstrap to build your layout on? Smiley

It has been awhile since I updated. So many fires on other projects  Cheesy

There are going to be many changes in version 4.0:

1. I have found that orphans can be trickier then I thought. I have caught the explorers in endless loops of restore from what should be a orphan free backups.I am going to have to completely change the way the database is indexed, so individual blocks and all their related transactions can be updated individually without a complete database restore.I did not want to go to that level of complexity, but it appears it is going to be needed.

2. As long as I am making a major revision, I am going to change the web lay out to be completely HTML 5 compliant  and use a different kind of page template system. A new look is in store for version 4.

3 .I may write some C++ modules for certain functions to gain speed. I need to run some more tests to see if the bottlenecks in the system are due to the database or code,  but most likely I will start rewriting parts of the explorer in C++.

4. I am going to push the release estimate to Mid November. I want to put out a quality product, not just rush out a sub standard piece of software.

5. I will continue to add coins to the test project, as it is important to test along a variety of block chains and stress test the servers.


dreamwatcher (OP)
Legendary
*
Offline Offline

Activity: 1064
Merit: 1000


View Profile WWW
November 14, 2013, 03:47:46 AM
 #52

UPDATE!!!!!!

I am now currently installing test version 3.99 on the test server. The explorers will be coming back up as the new databases are created.

New in test version 3.99:

New database structure -  The new database structure is smaller and makes "hot-fixing" orphans possible.

Rewrite of much of the core logic - Core logic updated to use the new database  + addtional features listed below.

HOT_FIX OF ORPHAN BLOCKS - Every time the database loader is called, it will check the last number of blocks set in the configuration file. I have all the explorers set to 250 for now. If an orphan block is found, the loader will "Hot-Fix" the block in the database. No more dumping the database and reloading from backup!!! The web server will remain up during a hot-fix, as it only takes a second or two.

Automatic database backups every ~1000 blocks - Whenever the loader detects 1000+ blocks since the last backup, it will auto backup the database.

Major changes to the address ledger page - The ledger page now has two tables, one for credits and one for debits, this makes the ledger much more readable. Web page ledgers are limited to the last 1000 credit and 1000 debit transactions. Longer searches will be available through the API. Anything more then 1000 (Even that is a high number) is pretty much unusable while looking at a web page. Transactions are listed newest to oldest.



mercSuey
Sr. Member
****
Offline Offline

Activity: 364
Merit: 250


View Profile
November 14, 2013, 04:12:13 AM
 #53

Looks cool. How about you add one for CGB?

Once CCE3 goes live, I will be adding the majority of coins to CCE.

However, I am slowly adding coins to the test server in an attempt to stress test and see how many coins a server can comfortably serve under cce3.

I will consider adding CGB as one of the test coins when I get ready to add another.





Thanks. Smiley
dreamwatcher (OP)
Legendary
*
Offline Offline

Activity: 1064
Merit: 1000


View Profile WWW
November 28, 2013, 03:10:52 AM
 #54

Update:

I think I have finally kicked the Db/user thread issue.

I have stopped using Cherrypy for the DB connection/user thread matching. It works well opening database connections as user threads start, but does not appear to have any way of closing the connection when the thread is closed. This was so unbelievable , it took me weeks to finally give in... Cheesy

I am now using DButils persistent DB connections system and it appears to be working well. Database processes appear to be stable in number and well within limits.

This means I can move back to working on the API and the CCE3 project can move forward.


zuper
Full Member
***
Offline Offline

Activity: 162
Merit: 100


View Profile
December 01, 2013, 02:06:13 PM
 #55

Update:

I think I have finally kicked the Db/user thread issue.

I have stopped using Cherrypy for the DB connection/user thread matching. It works well opening database connections as user threads start, but does not appear to have any way of closing the connection when the thread is closed. This was so unbelievable , it took me weeks to finally give in... Cheesy

I am now using DButils persistent DB connections system and it appears to be working well. Database processes appear to be stable in number and well within limits.

This means I can move back to working on the API and the CCE3 project can move forward.




Great! Please consider to add DMD (Diamond Coin)
Mad_Max
Hero Member
*****
Offline Offline

Activity: 894
Merit: 1001


View Profile
December 16, 2013, 03:25:54 AM
 #56

How about add CHNCoin?
It actually already was on CCE but you threw it out this summer when the network almost died due to "Difficulty trap" (hight diff and slow retarget = miners exodus).
But ~1.5 month ago diff retarget algo was replaced (now PPC type - little diff retarget every block):
https://bitcointalk.org/index.php?topic=322488.0

And now (after update to new version) coin works good and active:
~ 500 MH/s active mining
traded on two exchanges at least and have descent market cap (~ 600 000 - 800 000 USD)

He знaя пoкoя и oтдыxa, Пpи лyннoм и coлнeчнoм cвeтe, Mы дeлaeм дeньги из вoздyxa, Чтoб cнoвa cпycтить иx нa вeтep!
ProfMac
Legendary
*
Offline Offline

Activity: 1246
Merit: 1001



View Profile
January 21, 2014, 08:56:58 PM
 #57

http://bte.cryptocoinexplorer.com/chain/Bytecoin is down.

I try to be respectful and informed.
dreamwatcher (OP)
Legendary
*
Offline Offline

Activity: 1064
Merit: 1000


View Profile WWW
January 21, 2014, 09:29:53 PM
 #58


At this Time I have multiple VPS down. I will try to get everything back up ASAP.
Byates
Newbie
*
Offline Offline

Activity: 35
Merit: 0


View Profile
February 18, 2014, 11:25:39 AM
 #59

Can you add VegasCoin?
dreamwatcher (OP)
Legendary
*
Offline Offline

Activity: 1064
Merit: 1000


View Profile WWW
April 18, 2014, 11:12:24 PM
 #60

Cryptocoinexplorer.com will be converting to CCE3 over the weekend.

Please see the thread at:

https://bitcointalk.org/index.php?topic=576209.0
Pages: « 1 2 [3]  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!