exonum/ruExonum

Основной канал для обсуждения вопросов, связанных с разработкой на Exonum. Github: https://github.com/exonum/ Документация: https://exonum.com/doc/ English-speaking channel: https://gitter.im/exonum/exonum Telegram https://t.me/ExonumRU

Aleksey Sidorov

@alekseysidorov

Там есть возможность обратиться в service api builder к web backend, а в нем добавить raw handler с полным контролем над response

Vladislav Karnaukhov

@Asmor-K

@alekseysidorov это очень радует, попробую разобраться на днях. Спасибо за ответ)

Dmitry Timofeev

@dmitry-timofeev

Выпустили Exonum Java 0.7.0 с поддержкой тесткита для интеграционного тестирования Java-сервисов и огромным ускорением обработки транзакций :tada:

Подробнее на странице выпуска: https://github.com/exonum/exonum-java-binding/releases/tag/ejb%2Fv0.7.0

Arsen Guzhva

@Erchard

Где можно прочитать про запуск аудирующей ноды? Изменилось ли что-то по сравнению с версией 0.9 ?

Arsen Guzhva

@Erchard

@dmitry-timofeev спасибо. С вычислением хэша транзакции всё получилось

Michael Popsuev

@sheb-gregor

@Erchard вкратце - она просто так не запускается.
вариант 1 — первоначальный запуск сети ( с нулевого блока), когда в конфигах есть ноды валидаторы + ноды аудиторы — всё классно.
вариант 2 — подключение нового аудитора к запущенной сети — получи тапком в лицо, не подключается и не синкается.
Возможное решение: если в вашей ноде содержится configuration-service из поставки Exonum, нужно отправить транзакцию с апдейтом конфига (в нем добавить информацию про ноду-аудитора). Но я это так и не проверил ещё.

Arsen Guzhva

@Erchard

О! норм. Это подойдет

Возможность апдейтить конфиг была предусмотрена заранее

А самого аудитора нужно как-то настраивать по особому?

toml конфиг? Параметры command line при старте аудитора?

Arsen Guzhva

@Erchard

Проблема решена. Все оказалось проще

@sheb-gregor просто зарегать онлайн нового пира и все работает

Vladislav Karnaukhov

@Asmor-K

Добрый день, может ли блокчейн (апи и консенсус часть) использовать https?

Vladislav Karnaukhov

@Asmor-K

И еще один вопрос почему хранилище у аудиторов занимает гораздо меньше места 1.4gb против 13gb, он хранит не все данные? и если так, то что он делает когда нужны те, что у него отсутствуют

Arsen Guzhva

@Erchard

Есть сеть нод. Первая нода была поднята несколько месяцев назад. Новые ноды синхронизируются с ней, но скорост ьсинхронизации меньше чем скорость появления новых блоков. На что следует обратить внимание, чтобы ускорить синхронизацию?

Vladislav Karnaukhov

@Asmor-K

Добрый день, бывают случаи, что нода начинает бесконечно падать с ошибкой thread 'main' panicked at 'Node return error: ErrorMessage { msg: "An error in the Network thread occurred: Too many open files (os error 24)" }

В чем может быть проблема, почему она не закрывает соединения?

Vladislav Karnaukhov

@Asmor-K

Aug 07 12:14:17 Node blockchain_core[12990]: thread '<unnamed>' panicked at 'called Result::unwrap() on an Err value: Os { code: 107, kind: NotConnected, message: "Transport endpoint is not connected" }', src/libcore/result.rs:997:5
Aug 07 12:14:17 Node blockchain_core[12990]: note: Some details are omitted, run with RUST_BACKTRACE=full for a verbose backtrace.
Aug 07 12:14:17 Node blockchain_core[12990]: stack backtrace:
Aug 07 12:14:17 Node blockchain_core[12990]: 0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
Aug 07 12:14:17 Node blockchain_core[12990]: at src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:39
Aug 07 12:14:17 Node blockchain_core[12990]: 1: std::sys_common::backtrace::_print
Aug 07 12:14:17 Node blockchain_core[12990]: at src/libstd/sys_common/backtrace.rs:71
Aug 07 12:14:17 Node blockchain_core[12990]: 2: std::panicking::default_hook::{{closure}}
Aug 07 12:14:17 Node blockchain_core[12990]: at src/libstd/sys_common/backtrace.rs:59
Aug 07 12:14:17 Node blockchain_core[12990]: at src/libstd/panicking.rs:197
Aug 07 12:14:17 Node blockchain_core[12990]: 3: std::panicking::default_hook
Aug 07 12:14:17 Node blockchain_core[12990]: at src/libstd/panicking.rs:211
Aug 07 12:14:17 Node blockchain_core[12990]: 4: std::panicking::rust_panic_with_hook
Aug 07 12:14:17 Node blockchain_core[12990]: at src/libstd/panicking.rs:478
Aug 07 12:14:17 Node blockchain_core[12990]: 5: std::panicking::continue_panic_fmt
Aug 07 12:14:17 Node blockchain_core[12990]: at src/libstd/panicking.rs:381
Aug 07 12:14:17 Node blockchain_core[12990]: 6: rust_begin_unwind
Aug 07 12:14:17 Node blockchain_core[12990]: at src/libstd/panicking.rs:308
Aug 07 12:14:17 Node blockchain_core[12990]: 7: core::panicking::panic_fmt
Aug 07 12:14:17 Node blockchain_core[12990]: at src/libcore/panicking.rs:85
Aug 07 12:14:17 Node blockchain_core[12990]: 8: core::result::unwrap_failed
Aug 07 12:14:17 Node blockchain_core[12990]: 9: exonum::events::network::NetworkHandler::build_handshake_initiator

Так же заметил сейчас, что валидаторы постоянно стали паниковать. Делают пару коммитов, падают по данной причине и перезагружаются и так по кругу.
В чем может быть проблема? Раньше такого не было

Vladislav Karnaukhov

@Asmor-K

Добрый день, делал переезд нод на другую машину, скопировал базу от одного валидотара всем другим нодам, все работает, но в логах постоянно вылазит ошибка Received outdated Connect message from 192.168.88.45:6330 со старыми адресами пиров, можно это как то исправить?

Arsen Guzhva

@Erchard

аналогичная пробелема. В логах постоянно фигурируют старые пиры, котоыре давно уже не существуют. Как почистить "кэш" ?

Oleksandr Anyshchenko

@aleksuss

Опубликовали релиз Exonum 0.12 "Koepcke's Screech-Owl" c хранилищем MerkleDB и упрощенной процедурой запуска. Полный набор изменений можно посмотреть на странице релиза: https://github.com/exonum/exonum/releases/tag/v0.12

Добрый день, может ли блокчейн (апи и консенсус часть) использовать https?

На текущий момент нет. В планах имеется добавление протокола HTTPS.

ivan-ochc

@ivan-ochc

@Asmor-K ,привет. А зачем Вы копируете базу одного валидатора всем остальным нодам? Если переносите ноду на новый сервер, копировать бд этой ноды всем остальным нодам не нужно.

Michael Popsuev

@sheb-gregor

Кто-нибудь сталкивался с подобным?

После того, как ноды упали, при попытке переподнять их возникает вот такая вот проблема:

[2019-09-09T11:17:03.408284881Z INFO  exonum::node] Validator id = 'Some(ValidatorId(0))'
[2019-09-09T11:17:03.442365728Z INFO  exonum::helpers::config] ConfigManager started
[2019-09-09T11:17:03.442459399Z INFO  exonum::api::backends::actix] Starting public web api on 0.0.0.0:18002
[2019-09-09T11:17:03.442521456Z INFO  actix_net::server::server] Starting 8 workers
[2019-09-09T11:17:03.443372265Z INFO  actix_net::server::server] Starting server on 0.0.0.0:18002
[2019-09-09T11:17:03.443438153Z INFO  exonum::api::backends::actix] Starting private web api on 0.0.0.0:19002
[2019-09-09T11:17:03.443479929Z INFO  actix_net::server::server] Starting 8 workers
[2019-09-09T11:17:03.444183831Z INFO  actix_net::server::server] Starting server on 0.0.0.0:19002
[2019-09-09T11:17:03.444346098Z INFO  exonum::node] Start listening address=0.0.0.0:17002
[2019-09-09T11:17:03.444360506Z INFO  exonum::node] Trying to connect with peer b374d5c1...
[2019-09-09T11:17:03.444380027Z INFO  exonum::node] Trying to connect with peer c0f943b3...
[2019-09-09T11:17:03.444383827Z INFO  exonum::node] Trying to connect with peer 75171b46...
[2019-09-09T11:17:03.444412061Z INFO  exonum::node] Jump to round 8
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', src/libcore/option.rs:347:21
stack backtrace:
   0: backtrace::backtrace::libunwind::trace
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.29/src/backtrace/libunwind.rs:88
   .....
  10: core::panicking::panic
             at src/libcore/panicking.rs:49
  11: exonum_merkledb::proof_map_index::ProofMapIndex<T,K,V>::get_root_node
  12: <exonum_merkledb::proof_map_index::ProofMapIndex<T,K,V> as exonum_merkledb::hash::ObjectHash>::object_hash
  13: exonum::blockchain::schema::Schema<T>::core_state_hash
  14: exonum::blockchain::Blockchain::create_patch
  15: exonum::node::consensus::<impl exonum::node::NodeHandler>::execute
  16: exonum::node::consensus::<impl exonum::node::NodeHandler>::lock
  17: exonum::node::consensus::<impl exonum::node::NodeHandler>::handle_majority_prevotes
  18: exonum::node::consensus::<impl exonum::node::NodeHandler>::handle_consensus
  19: exonum::node::basic::<impl exonum::node::NodeHandler>::handle_message
  20: exonum::node::NodeHandler::initialize
  21: exonum::node::Node::run_handler
  22: exonum::node::Node::run
  23: exonum::helpers::fabric::builder::NodeBuilder::run
  24: node::main

ivan-ochc

@ivan-ochc

@sheb-gregor, а какая была причина падения?

Michael Popsuev

@sheb-gregor

@ivan-ochc место закончилось на сервере, тестовое окружение, после переноса на другой - вот такая фигня

ivan-ochc

@ivan-ochc

@sheb-gregor, сейчас проверю

ivan-ochc

@ivan-ochc

@sheb-gregor , все ноды были запущены на одном окружении?

ivan-ochc

@ivan-ochc

@sheb-gregor, повторить не получается: на одном сервере запустил две ноды, подождал пока закончилось место и ноды упали, скопировал бд и конфиги на новый сервер, запустил ноды - ошибки нет.

Michael Popsuev

@sheb-gregor

@ivan-ochc да, на одном

мне кажется проблема в Jump to round 8 — нужно подчистить прекоммит сообщения и незакрытые раунды консенсуса

ivan-ochc

@ivan-ochc

у меня было Jump to round 6

[2019-09-09T13:05:43.651044414Z INFO  exonum::node] Start listening address=0.0.0.0:6331
[2019-09-09T13:05:43.651068842Z INFO  exonum::node] Trying to connect with peer 60d8aba6...
[2019-09-09T13:05:43.651116693Z INFO  exonum::node] Jump to round 6
[2019-09-09T13:06:06.149348229Z WARN  exonum::node::consensus] ROUND TIMEOUT height=1618, round=6
[2019-09-09T13:06:10.949306748Z WARN  exonum::node::consensus] ROUND TIMEOUT height=1618, round=7
[2019-09-09T13:06:16.049354965Z WARN  exonum::node::consensus] ROUND TIMEOUT height=1618, round=8
[2019-09-09T13:06:21.449359547Z WARN  exonum::node::consensus] ROUND TIMEOUT height=1618, round=9
[2019-09-09T13:06:26.740166733Z INFO  exonum::node::basic] Received Connect message from peer: In(V4(127.0.0.1:26509))
[2019-09-09T13:06:26.740194196Z INFO  exonum::node::basic] Received Connect message from 127.0.0.1:6332. Need to connect: true
[2019-09-09T13:06:26.740263617Z INFO  exonum::node::basic] Send Connect message to 127.0.0.1:6332
[2019-09-09T13:06:27.149395253Z WARN  exonum::node::consensus] ROUND TIMEOUT height=1618, round=10
[2019-09-09T13:06:27.253701274Z INFO  exonum::node::consensus] COMMIT ====== height=1619, proposer=1, round=1,

ivan-ochc

@ivan-ochc

попробовал вариант когда заканчивается место во время принятия и обработки транзакций - так же ошибок не возникло

Michael Popsuev

@sheb-gregor

хм, буду пытаться дальше ковырять

Michael Popsuev

@sheb-gregor

[2019-09-10T14:41:23.598719879Z INFO  exonum::node::basic] Received Connect message from 0.0.0.0:17004. Need to connect: false
[2019-09-10T14:41:33.598873319Z INFO  exonum::node::basic] Received Connect message from 0.0.0.0:17001. Need to connect: false
[2019-09-10T14:41:33.599055887Z INFO  exonum::node::basic] Received Connect message from 0.0.0.0:17002. Need to connect: false
[2019-09-10T14:41:43.600487308Z INFO  exonum::node::basic] Received Connect message from 0.0.0.0:17001. Need to connect: false
[2019-09-10T14:41:43.600675047Z INFO  exonum::node::basic] Received Connect message from 0.0.0.0:17002. Need to connect: false
[2019-09-10T14:41:47.562212900Z WARN  exonum::node::consensus] ROUND TIMEOUT height=11871804, round=40
[2019-09-10T14:41:53.601312843Z INFO  exonum::node::basic] Received Connect message from 0.0.0.0:17004. Need to connect: false
[2019-09-10T14:41:53.601495522Z INFO  exonum::node::basic] Received Connect message from 0.0.0.0:17002. Need to connect: false
[2019-09-10T14:42:02.562317217Z WARN  exonum::node::consensus] ROUND TIMEOUT height=11871804, round=41
[2019-09-10T14:42:02.762414634Z INFO  exonum::node::consensus] LEADER: pool = 0, cache = 0
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', src/libcore/option.rs:347:21
stack backtrace:
   0:     0x5604c625631b - backtrace::backtrace::libunwind::trace::hfe5db90796807973
                               at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.29/src/backtrace/libunwind.rs:88
   1:     0x5604c625631b - backtrace::backtrace::trace_unsynchronized::h34b865a835594335
                               at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.29/src/backtrace/mod.rs:66
   2:     0x5604c625631b - std::sys_common::backtrace::_print::h527254ae44989167
                               at src/libstd/sys_common/backtrace.rs:47
   3:     0x5604c625631b - std::sys_common::backtrace::print::he85dd5ddddf46503
                               at src/libstd/sys_common/backtrace.rs:36
   4:     0x5604c625631b - std::panicking::default_hook::{{closure}}::h847a2eb38b396f14
                               at src/libstd/panicking.rs:200
   5:     0x5604c6255ff7 - std::panicking::default_hook::h2ca0f9a30a0e206b
                               at src/libstd/panicking.rs:214
   6:     0x5604c6256b79 - std::panicking::rust_panic_with_hook::hffcefc09751839d1
                               at src/libstd/panicking.rs:481
   7:     0x5604c6256612 - std::panicking::continue_panic_fmt::hc0f142c930c846fc
                               at src/libstd/panicking.rs:384
   8:     0x5604c62564f6 - rust_begin_unwind
                               at src/libstd/panicking.rs:311
   9:     0x5604c627798d - core::panicking::panic_fmt::h2daf88b2616ca2b2
                               at src/libcore/panicking.rs:85
  10:     0x5604c62778cc - core::panicking::panic::h2d0bc53a963fb996
                               at src/libcore/panicking.rs:49
  11:     0x5604c5b2b01a - exonum_merkledb::proof_map_index::ProofMapIndex<T,K,V>::get_root_node::ha2a1f60e285bfe04
  12:     0x5604c5b29d25 - <exonum_merkledb::proof_map_index::ProofMapIndex<T,K,V> as exonum_merkledb::hash::ObjectHash>::object_hash::h5af234c972d8344d
  13:     0x5604c5a30fef - exonum::blockchain::schema::Schema<T>::core_state_hash::h44801c972bf3e638
  14:     0x5604c5b7f7d9 - exonum::blockchain::Blockchain::create_patch::h60023d4156a96062
  15:     0x5604c5c015a0 - exonum::node::consensus::<impl exonum::node::NodeHandler>::execute::he00384f9a3e8c590
  16:     0x5604c5bfc19d - exonum::node::consensus::<impl exonum::node::NodeHandler>::lock::h194ef9c313111d3e
  17:     0x5604c5bfb7d4 - exonum::node::consensus::<impl exonum::node::NodeHandler>::handle_majority_prevotes::h6b590da2fd3fcf9c
  18:     0x5604c5bf72d7 - exonum::node::consensus::<impl exonum::node::NodeHandler>::handle_consensus::hd5b8c83023b4c029
  19:     0x5604c5bf39ef - exonum::node::basic::<impl exonum::node::NodeHandler>::handle_message::hf7e461ea01821507
  20:     0x5604c5c03576 - exonum::node::events::<im

3 ноды запущены, 4 пытается догнать блоки

Все три периодически падают с паникой

ivan-ochc

@ivan-ochc

Это тот же сценарий когда переносят ноды на новый сервер или уже другое?

Michael Popsuev

@sheb-gregor

и не поднимаются пока не сделаешь maintenance --action clear-cache

потом снова падают

4я в фоне блоке тащит, пока все три не отпадут

ivan-ochc

@ivan-ochc

@sheb-gregor, это тот же сценарий с переносом на новый сервер или уже на одном и том же сервере паникуют?

Michael Popsuev

@sheb-gregor

на новом сервере

Gab0

@breseda

Hola desde mexico

Rouc4

@Rouc4

Всем привет! Ребят подскажите, существует ли такая возможность запустить сервис на java-binding параллельно существующему проекту exonum на 0.12.0 версии (возможно с рестартом сети узлов или без такового)? Т.е. один блокчейн с двумя рантаймами, но одной базой?

Dmitry Timofeev

@dmitry-timofeev

Привет, @Rouc4 ,

Да, это возможно, если добавить в список растовых сервисов, вкомпилированных в приложение exonum-java, необходимые растовые сервисы. Пока это не очень удобно с т.з. сопровождения, т.к. exonum-java пока является только приложением, т.е. его нельзя, как икзонум, подключить в качестве библиотеки и при создании узла зарегистрировать дополнительные растовые сервисы, а нужно патчить. Кроме того, в 0.12 регистрация новых сервисов в запущенной сети имеет некоторые ограничения: требуется остановка сети, и отсутствие конфигурационных параметров у нового сервиса (всё это будет исправлено с поддержкой динамических сервисов, над которой сейчас работаем).

Подробнее о том, как это сделать сейчас, не дожидаясь ДС (Exonum Java 0.8.0 based on Exonum 0.12.0):

Ваши существующие растовые сервисы извлечь в отдельную библиотеку
Склонировать exonum-java
Модифицировать exonum-java, расширив список системных сервисов (см. метод prepare_service_factories as of ejb/v0.8.0). В exonum-java они конфигурируются, вы же можете регистрировать необходимые сервисы безусловно, что будет еще проще.
Собрать модифицированное приложение (см. CONTRIBUTING.md) и использовать его для запуска узлов сети.

 Последнее: стоит учитывать при планировании, что нативный код exonum-java, связанный с инстанциированием системных сервисов, существенно изменится в ближайшие недели при реализации динамических сервисов.

Rouc4

@Rouc4

@dmitry-timofeev спасибо! Очень признателен за ответ!

Aleksey Sidorov

@alekseysidorov

Еще хочу заметить, что если добавленый таким ad-hoc способом сервис имеет state hash, то он его не должен вычислять для высот меньше, чем момент добавления сервиса. Иначе это сломает работу аудиторов

Rouc4

@Rouc4

@alekseysidorov, понял. Спасибо! Буду изучать.

Elena Buzovska

@Buzovska

@/all Самое время зарегистрироваться на бесплатный вебинар для разработчиков от Exonum. Мы покажем как разработать электронный аукцион на блокчейн. Зарегистрироваться сейчас: https://bitfury.zoom.us/webinar/register/6315689822497/WN_pZf4qC9YQWKrm_6poKyzIA

Where communities thrive

People

Repo info

Activity