Quote from: spartako on October 09, 2015, 10:40:47 am

Many delegates went in a big minor fork (~35% partecipations) and also spartako and spartako_bot

I removed the blockchain and resynced with the main chain using this seed node:
188.165.233.53:1777

This is the error then I found:

Code: [Select]

3080000 unlinkable_block_exception: unlinkable block
block does not link to known chain
    {}
    th_a  fork_database.cpp:78 _push_block

    {"new_block":{"previous":"00018aeac52ac578eead894ddaefb832bab051d0","timestamp":"2015-10-09T10:10:21","witness":"1.6.19","transaction_merkle_root":"0000000000000000000000000000000000000000","extensions":[],"witness_signature":"1f6a191cc3c9f8ea6d06f1e3546931a35873961b0b0defe5689a35de504c448ddc3818793a52abbe65da08faa70b5700df2c13088629dd9c1c43a13a2f3ac9fc8c","transactions":[]}}
    th_a  db_block.cpp:197 _push_block
901261ms th_a       fork_database.cpp:57          push_block           ] Pushing block to fork database that failed to link: 00018aec0d81d4f086eaffcecc9a028749483c49, 101100
901262ms th_a       fork_database.cpp:58          push_block           ] Head: 101115, 00018afb2ccf99a7986cf678b67613061ba56d0f
901262ms th_a       application.cpp:429           handle_block         ] Error when pushing block:
3080000 unlinkable_block_exception: unlinkable block
block does not link to known chain
    {}


syncing from 104.236.51.238:2005 with latest master witout any problem
it requires a bit patience until it stops writing

Code: [Select]

1831000ms th_a       witness.cpp:179               block_production_loo ] Not producing block because production is disabled until we receive a
 recent block (see: --enable-stale-production)
1832000ms th_a       witness.cpp:179               block_production_loo ] Not producing block because production is disabled until we receive a
 recent block (see: --enable-stale-production)

and starts syncing.

here is my automatic failover script powered by xerocs python-graphenelib.  I am a noob at teh programming, and if I did anything wrong I would love the feedback.

Code: [Select]

#!/usr/bin/env python
# -*- coding: utf-8 -*-

import sys
import json
from grapheneapi import GrapheneWebsocket, GrapheneWebsocketProtocol
import time
import config

rpc = GrapheneWebsocket("localhost", 8092, "", "")
publickeys = config.publickeys
witnessname = config.witnessname


def getmissed(witnessname):
    witness = rpc.get_witness(witnessname)
    missed = witness["total_missed"]
    return missed

missed = getmissed(config.witnessname)


def switch(witnessname, publickeys, missed):
    keynumber = missed % len(publickeys)
    key = publickeys[keynumber]
    rpc.update_witness(witnessname, "", key, "true")
    print("witness down switching to " + key)
print ("Nothing in this window will change unless a block is missed")

while True:
    if missed < getmissed(config.witnessname):
        missed = getmissed(config.witnessname)
        switch(witnessname, publickeys, missed)
    else:
        time.sleep(3)
You need to add two lines to your config.py file.  witnessname as a string and publickeys as strings in a tuple of the public keys you want to switch between.  those lines look like this in my case.

Code: [Select]

witnessname = "dele-puppy"
publickeys = ("GPH75xxKG4ZeztPpnhmFch99smunUWMvDy9mB6Le497vpAA3XUXaD", "GPH8Sj81ncf8PK5QwJZvhWsvwp6m4bXzTFvp4bKycNNFvHaJpZSnH")

The wallet this script is running through needs to be unlocked, and must contain the owner key (I think its the owner key, rather than the active key) of the witness.

Quote from: thisisausername on October 08, 2015, 01:27:04 am

Someone: In 0.9.3 is the exporting just through the GUI export function or does it require the command line?

Bytemaster:I updated the menu in the menubar to use the new version.

Watch out - currently this is not true for Windows, until a bug is fixed you need to do it not via the menu-bar as BM says but via the console as recommended in xeroc's guide

Quote from: betax on October 07, 2015, 09:55:33 pm

is the web sockeds backed tcp loadbalanced? how many backend servers are used? To avoid the freezing, if an issue with the backed.

If it is an issue with the frontend can we delay response to the ui, or is it already throtle based on the tps / current screen.

Also I seemed to need to refresh the browser a couple of times to get the latest block whilst doing the load test.

Currently the backend pushes ALL state changes to the GUI whether or not the GUI cares about that particular state.   This was a shortcut taken to maximize reliability of the front end receiving updates.  We already have the filters in place to throttle this back to only the data the GUI has previously requested.   

So the GUI infrastructure is not well suited for these flood tests, but is well suited to serving 1000+ simultaneous users at normal transaction volumes.

Quote from: jakub on October 06, 2015, 11:03:31 pm

BM, I think there are now 3 witnesses waiting to be voted in:

bitshares-argentina
triox-delegate
pmc

Voted.   Any others?