Somehow, hit the ‘reply’ instead of reply all...

---------- Forwarded message ----------
From: Manish Sethi <manish.sethi@...>
Date: Wed, May 16, 2018 at 11:56 AM
Subject: Re: [Hyperledger Fabric] One suggestion to the fuction named createLedgerID
To: wangzp <wangzhipengxlj@...>

Yes, it can be be dropped. As you see that this parameter is not used in this function as such.

Thanks,

Manish

On Wed, May 16, 2018 at 11:37 AM, wangzp <wangzhipengxlj@...> wrote:

If you are right,  gb can be removed.

发自OPPO邮件客户端

在 Manish Sethi <manish.sethi@...>，2018年5月16日 21:05写道：

Before putting a `nil` value, block is already written to the block storage. It can survive a crash after that.

Even if we add the genesis block to the leveldb, a crash can happen before, in the middle, or after writting it to the db.

It does not reduce the amount of work that needs to be performed for maintaining it a crash-consistent.

On Wed, May 16, 2018 at 4:06 AM, ??? <wangzhipengxlj@...> wrote:

func (s *idStore) createLedgerID(ledgerID string, gb *common.Block) error {
key := s.encodeLedgerKey(ledgerID)
var val []byte
var err error
if val, err = proto.Marshal(gb); err != nil {
return err
}
if val, err = s.db.Get(key); err != nil {
return err
}
if val != nil {
return ErrLedgerIDExists
}
batch := &leveldb.Batch{}
batch.Put(key, val)
batch.Delete(underConstructionLedgerKey)
return s.db.WriteBatch(batch, true)
}

func (s *idStore) ledgerIDExists(ledgerID string) (bool, error) {
key := s.encodeLedgerKey(ledgerID)
val := []byte{}
err := error(nil)
if val, err = s.db.Get(key); err != nil {
return false, err
}
return val != nil, nil
}

Two functions in `core/ledger/kvledger/kv_ledger_provider.go` in version v1.10;
 In `createLedgerID()`, put `nil` value with the key of `ledgerID` into the `ledgerProviderDB` . Why not put the genesis block into the `ledgerProviderDB` ?  When a crash occurs, the ledger can still be generated with the genesis block after restart.

 

If you are right,  gb can be removed.

发自OPPO邮件客户端

在 Manish Sethi <manish.sethi@...>，2018年5月16日 21:05写道：

Before putting a `nil` value, block is already written to the block storage. It can survive a crash after that.

Even if we add the genesis block to the leveldb, a crash can happen before, in the middle, or after writting it to the db.

It does not reduce the amount of work that needs to be performed for maintaining it a crash-consistent.

On Wed, May 16, 2018 at 4:06 AM, ??? <wangzhipengxlj@...> wrote:

func (s *idStore) createLedgerID(ledgerID string, gb *common.Block) error {
key := s.encodeLedgerKey(ledgerID)
var val []byte
var err error
if val, err = proto.Marshal(gb); err != nil {
return err
}
if val, err = s.db.Get(key); err != nil {
return err
}
if val != nil {
return ErrLedgerIDExists
}
batch := &leveldb.Batch{}
batch.Put(key, val)
batch.Delete(underConstructionLedgerKey)
return s.db.WriteBatch(batch, true)
}

func (s *idStore) ledgerIDExists(ledgerID string) (bool, error) {
key := s.encodeLedgerKey(ledgerID)
val := []byte{}
err := error(nil)
if val, err = s.db.Get(key); err != nil {
return false, err
}
return val != nil, nil
}

Two functions in `core/ledger/kvledger/kv_ledger_provider.go` in version v1.10;
 In `createLedgerID()`, put `nil` value with the key of `ledgerID` into the `ledgerProviderDB` . Why not put the genesis block into the `ledgerProviderDB` ?  When a crash occurs, the ledger can still be generated with the genesis block after restart.

 

Hi Yash -

gRPC keepalives should work with nghttpx (we've used it in the past as a reverse proxy as well).
Can you share your settings (keep alive settings for the peer as well as the various timeouts for front/back for nghttpx) as well as any logs which show the keepalives not going through?

As an aside, if you are not wed to nghttpx, you might also want to try Envoy as well (https://www.envoyproxy.io/) as it seems to be gaining traction as a gRPC proxy.

-- G


 -----------------------------------------
 Gari Singh
 Distinguished Engineer, CTO - IBM Blockchain
 IBM Middleware
 550 King St
 Littleton, MA 01460
 Cell: 978-846-7499
 garis@...
 ----------------------------------------- 

-----fabric@....org wrote: -----
To: hyperledger-fabric <hyperledger-fabric@lists.hyperledger.org>
From: "Yash"
Sent by: fabric@...
Date: 05/16/2018 04:57AM
Subject: [Hyperledger Fabric] Keeping Peer-Orderer connection alive

Hi,

The Peer to Orderer connection needs to be kept alive so that whenever there are new transactions, the orderer can send them to the peer for committing. The Peer already uses a TCP keepAlive to maintain this connection.

In our case, the orderer is behind a reverse proxy call nghttpx. This reverse proxy does not seem to forward the keepAlives to the orderer. Due to this, the connection between peer and orderer is lost after some time and new transactions do not reach the peer for committing.

Is there a way we can get Peer to periodically send a message to the orderer so that the connection is kept alive at the application level?

Thanks,
Yash

H,

    It is said that kafka can tolerate about one half nodes's failure with about 10000 tps and sbft can tolerate about one third nodes's failure with about 2000 tps. 

    From this comparison, kafka take an great advantage over sbft. why to use sbft? or they each have different appliation senarios

   Thank you.

   Regards,

qs Meng