Add subscribe/unsubscribe RPCs. Add session, sessionManager, and serve JSON RPC (without HTTP). #66
4
db/db.go
|
@ -650,7 +650,7 @@ func (db *ReadOnlyDBColumnFamily) Shutdown() {
|
||||||
// RunDetectChanges Go routine the runs continuously while the hub is active
|
// RunDetectChanges Go routine the runs continuously while the hub is active
|
||||||
// to keep the db readonly view up to date and handle reorgs on the
|
// to keep the db readonly view up to date and handle reorgs on the
|
||||||
// blockchain.
|
// blockchain.
|
||||||
func (db *ReadOnlyDBColumnFamily) RunDetectChanges(notifCh chan *internal.HeightHash) {
|
func (db *ReadOnlyDBColumnFamily) RunDetectChanges(notifCh chan<- interface{}) {
|
||||||
go func() {
|
go func() {
|
||||||
lastPrint := time.Now()
|
lastPrint := time.Now()
|
||||||
for {
|
for {
|
||||||
|
@ -674,7 +674,7 @@ func (db *ReadOnlyDBColumnFamily) RunDetectChanges(notifCh chan *internal.Height
|
||||||
}
|
}
|
||||||
|
|
||||||
// DetectChanges keep the rocksdb db in sync and handle reorgs
|
// DetectChanges keep the rocksdb db in sync and handle reorgs
|
||||||
func (db *ReadOnlyDBColumnFamily) detectChanges(notifCh chan *internal.HeightHash) error {
|
func (db *ReadOnlyDBColumnFamily) detectChanges(notifCh chan<- interface{}) error {
|
||||||
err := db.DB.TryCatchUpWithPrimary()
|
err := db.DB.TryCatchUpWithPrimary()
|
||||||
if err != nil {
|
if err != nil {
|
||||||
return err
|
return err
|
||||||
|
|
67
db/db_get.go
|
@ -3,6 +3,7 @@ package db
|
||||||
// db_get.go contains the basic access functions to the database.
|
// db_get.go contains the basic access functions to the database.
|
||||||
|
|
||||||
import (
|
import (
|
||||||
|
"crypto/sha256"
|
||||||
"encoding/hex"
|
"encoding/hex"
|
||||||
"fmt"
|
"fmt"
|
||||||
"log"
|
"log"
|
||||||
|
@ -266,6 +267,72 @@ func (db *ReadOnlyDBColumnFamily) GetHistory(hashX []byte) ([]TxInfo, error) {
|
||||||
return results, nil
|
return results, nil
|
||||||
}
|
}
|
||||||
|
|
||||||
|
func (db *ReadOnlyDBColumnFamily) GetStatus(hashX []byte) ([]byte, error) {
|
||||||
|
// Lookup in HashXMempoolStatus first.
|
||||||
|
status, err := db.getMempoolStatus(hashX)
|
||||||
|
if err == nil && status != nil {
|
||||||
|
return status, err
|
||||||
|
}
|
||||||
|
|
||||||
|
// No indexed mempool status. Lookup in HashXStatus second.
|
||||||
|
handle, err := db.EnsureHandle(prefixes.HashXStatus)
|
||||||
|
if err != nil {
|
||||||
|
return nil, err
|
||||||
|
}
|
||||||
|
key := &prefixes.HashXStatusKey{
|
||||||
|
Prefix: []byte{prefixes.HashXStatus},
|
||||||
|
HashX: hashX,
|
||||||
|
}
|
||||||
|
rawKey := key.PackKey()
|
||||||
Resolved at meeting. Resolved at meeting.
|
|||||||
|
slice, err := db.DB.GetCF(db.Opts, handle, rawKey)
|
||||||
|
defer slice.Free()
|
||||||
|
if err == nil && slice.Size() > 0 {
|
||||||
|
rawValue := make([]byte, len(slice.Data()))
|
||||||
|
copy(rawValue, slice.Data())
|
||||||
|
value := prefixes.HashXStatusValue{}
|
||||||
|
value.UnpackValue(rawValue)
|
||||||
|
return value.Status, nil
|
||||||
|
}
|
||||||
|
|
||||||
|
// No indexed status. Fall back to enumerating HashXHistory.
|
||||||
|
txs, err := db.GetHistory(hashX)
|
||||||
|
if err != nil {
|
||||||
|
return nil, err
|
||||||
|
}
|
||||||
|
hash := sha256.New()
|
||||||
|
for _, tx := range txs {
|
||||||
|
hash.Write([]byte(fmt.Sprintf("%s:%d:", tx.TxHash.String(), tx.Height)))
|
||||||
|
}
|
||||||
|
// TODO: Mempool history
|
||||||
|
return hash.Sum(nil), err
|
||||||
|
}
|
||||||
|
|
||||||
|
func (db *ReadOnlyDBColumnFamily) getMempoolStatus(hashX []byte) ([]byte, error) {
|
||||||
|
handle, err := db.EnsureHandle(prefixes.HashXMempoolStatus)
|
||||||
|
if err != nil {
|
||||||
|
return nil, err
|
||||||
|
}
|
||||||
|
|
||||||
|
key := &prefixes.HashXMempoolStatusKey{
|
||||||
|
Prefix: []byte{prefixes.HashXMempoolStatus},
|
||||||
|
HashX: hashX,
|
||||||
|
}
|
||||||
|
rawKey := key.PackKey()
|
||||||
|
slice, err := db.DB.GetCF(db.Opts, handle, rawKey)
|
||||||
|
defer slice.Free()
|
||||||
|
if err != nil {
|
||||||
|
return nil, err
|
||||||
|
} else if slice.Size() == 0 {
|
||||||
|
return nil, nil
|
||||||
|
}
|
||||||
|
|
||||||
|
rawValue := make([]byte, len(slice.Data()))
|
||||||
|
copy(rawValue, slice.Data())
|
||||||
|
value := prefixes.HashXMempoolStatusValue{}
|
||||||
|
value.UnpackValue(rawValue)
|
||||||
|
return value.Status, nil
|
||||||
|
}
|
||||||
|
|
||||||
// GetStreamsAndChannelRepostedByChannelHashes returns a map of streams and channel hashes that are reposted by the given channel hashes.
|
// GetStreamsAndChannelRepostedByChannelHashes returns a map of streams and channel hashes that are reposted by the given channel hashes.
|
||||||
func (db *ReadOnlyDBColumnFamily) GetStreamsAndChannelRepostedByChannelHashes(reposterChannelHashes [][]byte) (map[string][]byte, map[string][]byte, error) {
|
func (db *ReadOnlyDBColumnFamily) GetStreamsAndChannelRepostedByChannelHashes(reposterChannelHashes [][]byte) (map[string][]byte, map[string][]byte, error) {
|
||||||
handle, err := db.EnsureHandle(prefixes.ChannelToClaim)
|
handle, err := db.EnsureHandle(prefixes.ChannelToClaim)
|
||||||
|
|
|
@ -3,6 +3,7 @@ package server
|
||||||
import (
|
import (
|
||||||
"log"
|
"log"
|
||||||
"os"
|
"os"
|
||||||
|
"strconv"
|
||||||
"strings"
|
"strings"
|
||||||
|
|
||||||
"github.com/akamensky/argparse"
|
"github.com/akamensky/argparse"
|
||||||
|
@ -27,7 +28,10 @@ type Args struct {
|
||||||
EsPort string
|
EsPort string
|
||||||
PrometheusPort string
|
PrometheusPort string
|
||||||
NotifierPort string
|
NotifierPort string
|
||||||
JSONRPCPort string
|
JSONRPCPort int
|
||||||
|
JSONRPCHTTPPort int
|
||||||
|
MaxSessions int
|
||||||
|
SessionTimeout int
|
||||||
EsIndex string
|
EsIndex string
|
||||||
RefreshDelta int
|
RefreshDelta int
|
||||||
CacheTTL int
|
CacheTTL int
|
||||||
|
@ -58,7 +62,9 @@ const (
|
||||||
DefaultEsPort = "9200"
|
DefaultEsPort = "9200"
|
||||||
DefaultPrometheusPort = "2112"
|
DefaultPrometheusPort = "2112"
|
||||||
DefaultNotifierPort = "18080"
|
DefaultNotifierPort = "18080"
|
||||||
DefaultJSONRPCPort = "50001"
|
DefaultJSONRPCPort = 50001
|
||||||
|
DefaultMaxSessions = 10000
|
||||||
|
DefaultSessionTimeout = 300
|
||||||
DefaultRefreshDelta = 5
|
DefaultRefreshDelta = 5
|
||||||
DefaultCacheTTL = 5
|
DefaultCacheTTL = 5
|
||||||
DefaultPeerFile = "peers.txt"
|
DefaultPeerFile = "peers.txt"
|
||||||
|
@ -111,6 +117,11 @@ func ParseArgs(searchRequest *pb.SearchRequest) *Args {
|
||||||
searchCmd := parser.NewCommand("search", "claim search")
|
searchCmd := parser.NewCommand("search", "claim search")
|
||||||
dbCmd := parser.NewCommand("db", "db testing")
|
dbCmd := parser.NewCommand("db", "db testing")
|
||||||
|
|
||||||
|
validatePort := func(arg []string) error {
|
||||||
|
_, err := strconv.ParseUint(arg[0], 10, 16)
|
||||||
|
return err
|
||||||
|
}
|
||||||
|
|
||||||
host := parser.String("", "rpchost", &argparse.Options{Required: false, Help: "RPC host", Default: DefaultHost})
|
host := parser.String("", "rpchost", &argparse.Options{Required: false, Help: "RPC host", Default: DefaultHost})
|
||||||
port := parser.String("", "rpcport", &argparse.Options{Required: false, Help: "RPC port", Default: DefaultPort})
|
port := parser.String("", "rpcport", &argparse.Options{Required: false, Help: "RPC port", Default: DefaultPort})
|
||||||
dbPath := parser.String("", "db-path", &argparse.Options{Required: false, Help: "RocksDB path", Default: DefaultDBPath})
|
dbPath := parser.String("", "db-path", &argparse.Options{Required: false, Help: "RocksDB path", Default: DefaultDBPath})
|
||||||
|
@ -120,7 +131,10 @@ func ParseArgs(searchRequest *pb.SearchRequest) *Args {
|
||||||
esPort := parser.String("", "esport", &argparse.Options{Required: false, Help: "elasticsearch port", Default: DefaultEsPort})
|
esPort := parser.String("", "esport", &argparse.Options{Required: false, Help: "elasticsearch port", Default: DefaultEsPort})
|
||||||
prometheusPort := parser.String("", "prometheus-port", &argparse.Options{Required: false, Help: "prometheus port", Default: DefaultPrometheusPort})
|
prometheusPort := parser.String("", "prometheus-port", &argparse.Options{Required: false, Help: "prometheus port", Default: DefaultPrometheusPort})
|
||||||
notifierPort := parser.String("", "notifier-port", &argparse.Options{Required: false, Help: "notifier port", Default: DefaultNotifierPort})
|
notifierPort := parser.String("", "notifier-port", &argparse.Options{Required: false, Help: "notifier port", Default: DefaultNotifierPort})
|
||||||
jsonRPCPort := parser.String("", "json-rpc-port", &argparse.Options{Required: false, Help: "JSON RPC port", Default: DefaultJSONRPCPort})
|
jsonRPCPort := parser.Int("", "json-rpc-port", &argparse.Options{Required: false, Help: "JSON RPC port", Validate: validatePort})
|
||||||
|
jsonRPCHTTPPort := parser.Int("", "json-rpc-http-port", &argparse.Options{Required: false, Help: "JSON RPC over HTTP port", Validate: validatePort})
|
||||||
|
maxSessions := parser.Int("", "max-sessions", &argparse.Options{Required: false, Help: "Maximum number of electrum clients that can be connected", Default: DefaultMaxSessions})
|
||||||
|
sessionTimeout := parser.Int("", "session-timeout", &argparse.Options{Required: false, Help: "Session inactivity timeout (seconds)", Default: DefaultSessionTimeout})
|
||||||
esIndex := parser.String("", "esindex", &argparse.Options{Required: false, Help: "elasticsearch index name", Default: DefaultEsIndex})
|
esIndex := parser.String("", "esindex", &argparse.Options{Required: false, Help: "elasticsearch index name", Default: DefaultEsIndex})
|
||||||
refreshDelta := parser.Int("", "refresh-delta", &argparse.Options{Required: false, Help: "elasticsearch index refresh delta in seconds", Default: DefaultRefreshDelta})
|
refreshDelta := parser.Int("", "refresh-delta", &argparse.Options{Required: false, Help: "elasticsearch index refresh delta in seconds", Default: DefaultRefreshDelta})
|
||||||
cacheTTL := parser.Int("", "cachettl", &argparse.Options{Required: false, Help: "Cache TTL in minutes", Default: DefaultCacheTTL})
|
cacheTTL := parser.Int("", "cachettl", &argparse.Options{Required: false, Help: "Cache TTL in minutes", Default: DefaultCacheTTL})
|
||||||
|
@ -158,6 +172,11 @@ func ParseArgs(searchRequest *pb.SearchRequest) *Args {
|
||||||
log.Fatalln(parser.Usage(err))
|
log.Fatalln(parser.Usage(err))
|
||||||
}
|
}
|
||||||
|
|
||||||
|
// Use default JSON RPC port only if *neither* JSON RPC arg is specified.
|
||||||
|
if *jsonRPCPort == 0 && *jsonRPCHTTPPort == 0 {
|
||||||
|
*jsonRPCPort = DefaultJSONRPCPort
|
||||||
|
}
|
||||||
|
|
||||||
args := &Args{
|
args := &Args{
|
||||||
CmdType: SearchCmd,
|
CmdType: SearchCmd,
|
||||||
Host: *host,
|
Host: *host,
|
||||||
|
@ -169,6 +188,9 @@ func ParseArgs(searchRequest *pb.SearchRequest) *Args {
|
||||||
PrometheusPort: *prometheusPort,
|
PrometheusPort: *prometheusPort,
|
||||||
NotifierPort: *notifierPort,
|
NotifierPort: *notifierPort,
|
||||||
JSONRPCPort: *jsonRPCPort,
|
JSONRPCPort: *jsonRPCPort,
|
||||||
|
JSONRPCHTTPPort: *jsonRPCHTTPPort,
|
||||||
|
MaxSessions: *maxSessions,
|
||||||
|
SessionTimeout: *sessionTimeout,
|
||||||
EsIndex: *esIndex,
|
EsIndex: *esIndex,
|
||||||
RefreshDelta: *refreshDelta,
|
RefreshDelta: *refreshDelta,
|
||||||
CacheTTL: *cacheTTL,
|
CacheTTL: *cacheTTL,
|
||||||
|
|
|
@ -9,10 +9,7 @@ import (
|
||||||
"encoding/hex"
|
"encoding/hex"
|
||||||
"errors"
|
"errors"
|
||||||
"fmt"
|
"fmt"
|
||||||
"net/http"
|
|
||||||
"strings"
|
|
||||||
|
|
||||||
"github.com/gorilla/rpc"
|
|
||||||
"github.com/lbryio/herald.go/db"
|
"github.com/lbryio/herald.go/db"
|
||||||
"github.com/lbryio/herald.go/internal"
|
"github.com/lbryio/herald.go/internal"
|
||||||
"github.com/lbryio/lbcd/chaincfg"
|
"github.com/lbryio/lbcd/chaincfg"
|
||||||
|
@ -23,56 +20,37 @@ import (
|
||||||
"golang.org/x/exp/constraints"
|
"golang.org/x/exp/constraints"
|
||||||
)
|
)
|
||||||
|
|
||||||
type BlockchainCodec struct {
|
// BlockchainBlockService methods handle "blockchain.block.*" RPCs
|
||||||
rpc.Codec
|
type BlockchainBlockService struct {
|
||||||
}
|
|
||||||
|
|
||||||
func (c *BlockchainCodec) NewRequest(r *http.Request) rpc.CodecRequest {
|
|
||||||
return &BlockchainCodecRequest{c.Codec.NewRequest(r)}
|
|
||||||
}
|
|
||||||
|
|
||||||
// BlockchainCodecRequest provides ability to rewrite the incoming
|
|
||||||
// request "method" field. For example:
|
|
||||||
// blockchain.block.get_header -> blockchain_block.Get_header
|
|
||||||
// blockchain.address.listunspent -> blockchain_address.Listunspent
|
|
||||||
// This makes the "method" string compatible with Gorilla/RPC
|
|
||||||
// requirements.
|
|
||||||
type BlockchainCodecRequest struct {
|
|
||||||
rpc.CodecRequest
|
|
||||||
}
|
|
||||||
|
|
||||||
func (cr *BlockchainCodecRequest) Method() (string, error) {
|
|
||||||
rawMethod, err := cr.CodecRequest.Method()
|
|
||||||
if err != nil {
|
|
||||||
return rawMethod, err
|
|
||||||
}
|
|
||||||
parts := strings.Split(rawMethod, ".")
|
|
||||||
if len(parts) < 2 {
|
|
||||||
return rawMethod, fmt.Errorf("blockchain rpc: service/method ill-formed: %q", rawMethod)
|
|
||||||
}
|
|
||||||
service := strings.Join(parts[0:len(parts)-1], "_")
|
|
||||||
method := parts[len(parts)-1]
|
|
||||||
if len(method) < 1 {
|
|
||||||
return rawMethod, fmt.Errorf("blockchain rpc: method ill-formed: %q", method)
|
|
||||||
}
|
|
||||||
method = strings.ToUpper(string(method[0])) + string(method[1:])
|
|
||||||
return service + "." + method, err
|
|
||||||
}
|
|
||||||
|
|
||||||
// BlockchainService methods handle "blockchain.block.*" RPCs
|
|
||||||
type BlockchainService struct {
|
|
||||||
DB *db.ReadOnlyDBColumnFamily
|
DB *db.ReadOnlyDBColumnFamily
|
||||||
Chain *chaincfg.Params
|
Chain *chaincfg.Params
|
||||||
}
|
}
|
||||||
|
|
||||||
|
// BlockchainBlockService methods handle "blockchain.headers.*" RPCs
|
||||||
|
type BlockchainHeadersService struct {
|
||||||
|
DB *db.ReadOnlyDBColumnFamily
|
||||||
|
Chain *chaincfg.Params
|
||||||
|
// needed for subscribe/unsubscribe
|
||||||
|
sessionMgr *sessionManager
|
||||||
|
session *session
|
||||||
|
}
|
||||||
|
|
||||||
// BlockchainAddressService methods handle "blockchain.address.*" RPCs
|
// BlockchainAddressService methods handle "blockchain.address.*" RPCs
|
||||||
type BlockchainAddressService struct {
|
type BlockchainAddressService struct {
|
||||||
BlockchainService
|
DB *db.ReadOnlyDBColumnFamily
|
||||||
|
Chain *chaincfg.Params
|
||||||
|
// needed for subscribe/unsubscribe
|
||||||
|
sessionMgr *sessionManager
|
||||||
|
session *session
|
||||||
}
|
}
|
||||||
|
|
||||||
// BlockchainScripthashService methods handle "blockchain.scripthash.*" RPCs
|
// BlockchainScripthashService methods handle "blockchain.scripthash.*" RPCs
|
||||||
type BlockchainScripthashService struct {
|
type BlockchainScripthashService struct {
|
||||||
BlockchainService
|
DB *db.ReadOnlyDBColumnFamily
|
||||||
|
Chain *chaincfg.Params
|
||||||
|
// needed for subscribe/unsubscribe
|
||||||
|
sessionMgr *sessionManager
|
||||||
|
session *session
|
||||||
}
|
}
|
||||||
|
|
||||||
const CHUNK_SIZE = 96
|
const CHUNK_SIZE = 96
|
||||||
|
@ -87,10 +65,45 @@ func min[Ord constraints.Ordered](x, y Ord) Ord {
|
||||||
return y
|
return y
|
||||||
}
|
}
|
||||||
|
|
||||||
|
func max[Ord constraints.Ordered](x, y Ord) Ord {
|
||||||
|
if x > y {
|
||||||
|
return x
|
||||||
|
}
|
||||||
|
return y
|
||||||
|
}
|
||||||
|
|
||||||
|
type BlockHeaderElectrum struct {
|
||||||
|
Version uint32 `json:"version"`
|
||||||
|
PrevBlockHash string `json:"prev_block_hash"`
|
||||||
|
MerkleRoot string `json:"merkle_root"`
|
||||||
|
ClaimTrieRoot string `json:"claim_trie_root"`
|
||||||
|
Timestamp uint32 `json:"timestamp"`
|
||||||
|
Bits uint32 `json:"bits"`
|
||||||
|
Nonce uint32 `json:"nonce"`
|
||||||
|
BlockHeight uint32 `json:"block_height"`
|
||||||
|
}
|
||||||
|
|
||||||
|
func newBlockHeaderElectrum(header *[HEADER_SIZE]byte, height uint32) *BlockHeaderElectrum {
|
||||||
|
var h1, h2, h3 chainhash.Hash
|
||||||
|
h1.SetBytes(header[4:36])
|
||||||
|
h2.SetBytes(header[36:68])
|
||||||
|
h3.SetBytes(header[68:100])
|
||||||
|
return &BlockHeaderElectrum{
|
||||||
|
Version: binary.LittleEndian.Uint32(header[0:]),
|
||||||
|
PrevBlockHash: h1.String(),
|
||||||
|
MerkleRoot: h2.String(),
|
||||||
|
ClaimTrieRoot: h3.String(),
|
||||||
|
Timestamp: binary.LittleEndian.Uint32(header[100:]),
|
||||||
|
Bits: binary.LittleEndian.Uint32(header[104:]),
|
||||||
|
Nonce: binary.LittleEndian.Uint32(header[108:]),
|
||||||
|
BlockHeight: height,
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
type BlockGetServerHeightReq struct{}
|
type BlockGetServerHeightReq struct{}
|
||||||
type BlockGetServerHeightResp uint32
|
type BlockGetServerHeightResp uint32
|
||||||
|
|
||||||
func (s *BlockchainService) Get_server_height(r *http.Request, req *BlockGetServerHeightReq, resp **BlockGetServerHeightResp) error {
|
func (s *BlockchainBlockService) Get_server_height(req *BlockGetServerHeightReq, resp **BlockGetServerHeightResp) error {
|
||||||
if s.DB == nil || s.DB.LastState == nil {
|
if s.DB == nil || s.DB.LastState == nil {
|
||||||
return fmt.Errorf("unknown height")
|
return fmt.Errorf("unknown height")
|
||||||
}
|
}
|
||||||
|
@ -103,7 +116,7 @@ type BlockGetChunkReq uint32
|
||||||
type BlockGetChunkResp string
|
type BlockGetChunkResp string
|
||||||
|
|
||||||
// 'blockchain.block.get_chunk'
|
// 'blockchain.block.get_chunk'
|
||||||
func (s *BlockchainService) Get_chunk(r *http.Request, req *BlockGetChunkReq, resp **BlockGetChunkResp) error {
|
func (s *BlockchainBlockService) Get_chunk(req *BlockGetChunkReq, resp **BlockGetChunkResp) error {
|
||||||
index := uint32(*req)
|
index := uint32(*req)
|
||||||
db_headers, err := s.DB.GetHeaders(index*CHUNK_SIZE, CHUNK_SIZE)
|
db_headers, err := s.DB.GetHeaders(index*CHUNK_SIZE, CHUNK_SIZE)
|
||||||
if err != nil {
|
if err != nil {
|
||||||
|
@ -120,18 +133,11 @@ func (s *BlockchainService) Get_chunk(r *http.Request, req *BlockGetChunkReq, re
|
||||||
|
|
||||||
type BlockGetHeaderReq uint32
|
type BlockGetHeaderReq uint32
|
||||||
type BlockGetHeaderResp struct {
|
type BlockGetHeaderResp struct {
|
||||||
Version uint32 `json:"version"`
|
BlockHeaderElectrum
|
||||||
PrevBlockHash string `json:"prev_block_hash"`
|
|
||||||
MerkleRoot string `json:"merkle_root"`
|
|
||||||
ClaimTrieRoot string `json:"claim_trie_root"`
|
|
||||||
Timestamp uint32 `json:"timestamp"`
|
|
||||||
Bits uint32 `json:"bits"`
|
|
||||||
Nonce uint32 `json:"nonce"`
|
|
||||||
BlockHeight uint32 `json:"block_height"`
|
|
||||||
}
|
}
|
||||||
|
|
||||||
// 'blockchain.block.get_header'
|
// 'blockchain.block.get_header'
|
||||||
func (s *BlockchainService) Get_header(r *http.Request, req *BlockGetHeaderReq, resp **BlockGetHeaderResp) error {
|
func (s *BlockchainBlockService) Get_header(req *BlockGetHeaderReq, resp **BlockGetHeaderResp) error {
|
||||||
height := uint32(*req)
|
height := uint32(*req)
|
||||||
headers, err := s.DB.GetHeaders(height, 1)
|
headers, err := s.DB.GetHeaders(height, 1)
|
||||||
if err != nil {
|
if err != nil {
|
||||||
|
@ -140,23 +146,7 @@ func (s *BlockchainService) Get_header(r *http.Request, req *BlockGetHeaderReq,
|
||||||
if len(headers) < 1 {
|
if len(headers) < 1 {
|
||||||
return errors.New("not found")
|
return errors.New("not found")
|
||||||
}
|
}
|
||||||
decode := func(header *[HEADER_SIZE]byte, height uint32) *BlockGetHeaderResp {
|
*resp = &BlockGetHeaderResp{*newBlockHeaderElectrum(&headers[0], height)}
|
||||||
var h1, h2, h3 chainhash.Hash
|
|
||||||
h1.SetBytes(header[4:36])
|
|
||||||
h2.SetBytes(header[36:68])
|
|
||||||
h3.SetBytes(header[68:100])
|
|
||||||
return &BlockGetHeaderResp{
|
|
||||||
Version: binary.LittleEndian.Uint32(header[0:]),
|
|
||||||
PrevBlockHash: h1.String(),
|
|
||||||
MerkleRoot: h2.String(),
|
|
||||||
ClaimTrieRoot: h3.String(),
|
|
||||||
Timestamp: binary.LittleEndian.Uint32(header[100:]),
|
|
||||||
Bits: binary.LittleEndian.Uint32(header[104:]),
|
|
||||||
Nonce: binary.LittleEndian.Uint32(header[108:]),
|
|
||||||
BlockHeight: height,
|
|
||||||
}
|
|
||||||
}
|
|
||||||
*resp = decode(&headers[0], height)
|
|
||||||
return err
|
return err
|
||||||
}
|
}
|
||||||
|
|
||||||
|
@ -177,7 +167,7 @@ type BlockHeadersResp struct {
|
||||||
}
|
}
|
||||||
|
|
||||||
// 'blockchain.block.headers'
|
// 'blockchain.block.headers'
|
||||||
func (s *BlockchainService) Headers(r *http.Request, req *BlockHeadersReq, resp **BlockHeadersResp) error {
|
func (s *BlockchainBlockService) Headers(req *BlockHeadersReq, resp **BlockHeadersResp) error {
|
||||||
count := min(req.Count, MAX_CHUNK_SIZE)
|
count := min(req.Count, MAX_CHUNK_SIZE)
|
||||||
db_headers, err := s.DB.GetHeaders(req.StartHeight, count)
|
db_headers, err := s.DB.GetHeaders(req.StartHeight, count)
|
||||||
if err != nil {
|
if err != nil {
|
||||||
|
@ -209,6 +199,47 @@ func (s *BlockchainService) Headers(r *http.Request, req *BlockHeadersReq, resp
|
||||||
return err
|
return err
|
||||||
}
|
}
|
||||||
|
|
||||||
|
type HeadersSubscribeReq struct {
|
||||||
|
Raw bool `json:"raw"`
|
||||||
|
}
|
||||||
|
|
||||||
|
type HeadersSubscribeResp struct {
|
||||||
|
BlockHeaderElectrum
|
||||||
|
}
|
||||||
|
type HeadersSubscribeRawResp struct {
|
||||||
|
Hex string `json:"hex"`
|
||||||
|
Height uint32 `json:"height"`
|
||||||
|
}
|
||||||
|
|
||||||
|
// 'blockchain.headers.subscribe'
|
||||||
|
func (s *BlockchainHeadersService) Subscribe(req *HeadersSubscribeReq, resp *interface{}) error {
|
||||||
|
if s.sessionMgr == nil || s.session == nil {
|
||||||
|
return errors.New("no session, rpc not supported")
|
||||||
|
}
|
||||||
|
s.sessionMgr.headersSubscribe(s.session, req.Raw, true /*subscribe*/)
|
||||||
|
height := s.DB.Height
|
||||||
|
if s.DB.LastState != nil {
|
||||||
|
height = s.DB.LastState.Height
|
||||||
|
}
|
||||||
|
headers, err := s.DB.GetHeaders(height, 1)
|
||||||
|
if err != nil {
|
||||||
|
s.sessionMgr.headersSubscribe(s.session, req.Raw, false /*subscribe*/)
|
||||||
|
return err
|
||||||
|
}
|
||||||
|
if len(headers) < 1 {
|
||||||
|
return errors.New("not found")
|
||||||
|
}
|
||||||
|
if req.Raw {
|
||||||
|
*resp = &HeadersSubscribeRawResp{
|
||||||
|
Hex: hex.EncodeToString(headers[0][:]),
|
||||||
|
Height: height,
|
||||||
|
}
|
||||||
|
} else {
|
||||||
|
*resp = &HeadersSubscribeResp{*newBlockHeaderElectrum(&headers[0], height)}
|
||||||
|
}
|
||||||
|
return err
|
||||||
|
}
|
||||||
|
|
||||||
func decodeScriptHash(scripthash string) ([]byte, error) {
|
func decodeScriptHash(scripthash string) ([]byte, error) {
|
||||||
sh, err := hex.DecodeString(scripthash)
|
sh, err := hex.DecodeString(scripthash)
|
||||||
if err != nil {
|
if err != nil {
|
||||||
|
@ -249,7 +280,7 @@ type AddressGetBalanceResp struct {
|
||||||
}
|
}
|
||||||
|
|
||||||
// 'blockchain.address.get_balance'
|
// 'blockchain.address.get_balance'
|
||||||
func (s *BlockchainAddressService) Get_balance(r *http.Request, req *AddressGetBalanceReq, resp **AddressGetBalanceResp) error {
|
func (s *BlockchainAddressService) Get_balance(req *AddressGetBalanceReq, resp **AddressGetBalanceResp) error {
|
||||||
address, err := lbcutil.DecodeAddress(req.Address, s.Chain)
|
address, err := lbcutil.DecodeAddress(req.Address, s.Chain)
|
||||||
if err != nil {
|
if err != nil {
|
||||||
return err
|
return err
|
||||||
|
@ -276,7 +307,7 @@ type ScripthashGetBalanceResp struct {
|
||||||
}
|
}
|
||||||
|
|
||||||
// 'blockchain.scripthash.get_balance'
|
// 'blockchain.scripthash.get_balance'
|
||||||
func (s *BlockchainScripthashService) Get_balance(r *http.Request, req *scripthashGetBalanceReq, resp **ScripthashGetBalanceResp) error {
|
func (s *BlockchainScripthashService) Get_balance(req *scripthashGetBalanceReq, resp **ScripthashGetBalanceResp) error {
|
||||||
scripthash, err := decodeScriptHash(req.ScriptHash)
|
scripthash, err := decodeScriptHash(req.ScriptHash)
|
||||||
if err != nil {
|
if err != nil {
|
||||||
return err
|
return err
|
||||||
|
@ -307,7 +338,7 @@ type AddressGetHistoryResp struct {
|
||||||
}
|
}
|
||||||
|
|
||||||
// 'blockchain.address.get_history'
|
// 'blockchain.address.get_history'
|
||||||
func (s *BlockchainAddressService) Get_history(r *http.Request, req *AddressGetHistoryReq, resp **AddressGetHistoryResp) error {
|
func (s *BlockchainAddressService) Get_history(req *AddressGetHistoryReq, resp **AddressGetHistoryResp) error {
|
||||||
address, err := lbcutil.DecodeAddress(req.Address, s.Chain)
|
address, err := lbcutil.DecodeAddress(req.Address, s.Chain)
|
||||||
if err != nil {
|
if err != nil {
|
||||||
return err
|
return err
|
||||||
|
@ -346,7 +377,7 @@ type ScripthashGetHistoryResp struct {
|
||||||
}
|
}
|
||||||
|
|
||||||
// 'blockchain.scripthash.get_history'
|
// 'blockchain.scripthash.get_history'
|
||||||
func (s *BlockchainScripthashService) Get_history(r *http.Request, req *ScripthashGetHistoryReq, resp **ScripthashGetHistoryResp) error {
|
func (s *BlockchainScripthashService) Get_history(req *ScripthashGetHistoryReq, resp **ScripthashGetHistoryResp) error {
|
||||||
scripthash, err := decodeScriptHash(req.ScriptHash)
|
scripthash, err := decodeScriptHash(req.ScriptHash)
|
||||||
if err != nil {
|
if err != nil {
|
||||||
return err
|
return err
|
||||||
|
@ -378,7 +409,7 @@ type AddressGetMempoolReq struct {
|
||||||
type AddressGetMempoolResp []TxInfoFee
|
type AddressGetMempoolResp []TxInfoFee
|
||||||
|
|
||||||
// 'blockchain.address.get_mempool'
|
// 'blockchain.address.get_mempool'
|
||||||
func (s *BlockchainAddressService) Get_mempool(r *http.Request, req *AddressGetMempoolReq, resp **AddressGetMempoolResp) error {
|
func (s *BlockchainAddressService) Get_mempool(req *AddressGetMempoolReq, resp **AddressGetMempoolResp) error {
|
||||||
address, err := lbcutil.DecodeAddress(req.Address, s.Chain)
|
address, err := lbcutil.DecodeAddress(req.Address, s.Chain)
|
||||||
if err != nil {
|
if err != nil {
|
||||||
return err
|
return err
|
||||||
|
@ -402,7 +433,7 @@ type ScripthashGetMempoolReq struct {
|
||||||
type ScripthashGetMempoolResp []TxInfoFee
|
type ScripthashGetMempoolResp []TxInfoFee
|
||||||
|
|
||||||
// 'blockchain.scripthash.get_mempool'
|
// 'blockchain.scripthash.get_mempool'
|
||||||
func (s *BlockchainScripthashService) Get_mempool(r *http.Request, req *ScripthashGetMempoolReq, resp **ScripthashGetMempoolResp) error {
|
func (s *BlockchainScripthashService) Get_mempool(req *ScripthashGetMempoolReq, resp **ScripthashGetMempoolResp) error {
|
||||||
scripthash, err := decodeScriptHash(req.ScriptHash)
|
scripthash, err := decodeScriptHash(req.ScriptHash)
|
||||||
if err != nil {
|
if err != nil {
|
||||||
return err
|
return err
|
||||||
|
@ -428,7 +459,7 @@ type TXOInfo struct {
|
||||||
type AddressListUnspentResp []TXOInfo
|
type AddressListUnspentResp []TXOInfo
|
||||||
|
|
||||||
// 'blockchain.address.listunspent'
|
// 'blockchain.address.listunspent'
|
||||||
func (s *BlockchainAddressService) Listunspent(r *http.Request, req *AddressListUnspentReq, resp **AddressListUnspentResp) error {
|
func (s *BlockchainAddressService) Listunspent(req *AddressListUnspentReq, resp **AddressListUnspentResp) error {
|
||||||
address, err := lbcutil.DecodeAddress(req.Address, s.Chain)
|
address, err := lbcutil.DecodeAddress(req.Address, s.Chain)
|
||||||
if err != nil {
|
if err != nil {
|
||||||
return err
|
return err
|
||||||
|
@ -460,7 +491,7 @@ type ScripthashListUnspentReq struct {
|
||||||
type ScripthashListUnspentResp []TXOInfo
|
type ScripthashListUnspentResp []TXOInfo
|
||||||
|
|
||||||
// 'blockchain.scripthash.listunspent'
|
// 'blockchain.scripthash.listunspent'
|
||||||
func (s *BlockchainScripthashService) Listunspent(r *http.Request, req *ScripthashListUnspentReq, resp **ScripthashListUnspentResp) error {
|
func (s *BlockchainScripthashService) Listunspent(req *ScripthashListUnspentReq, resp **ScripthashListUnspentResp) error {
|
||||||
scripthash, err := decodeScriptHash(req.ScriptHash)
|
scripthash, err := decodeScriptHash(req.ScriptHash)
|
||||||
if err != nil {
|
if err != nil {
|
||||||
return err
|
return err
|
||||||
|
@ -481,3 +512,94 @@ func (s *BlockchainScripthashService) Listunspent(r *http.Request, req *Scriptha
|
||||||
*resp = &result
|
*resp = &result
|
||||||
return err
|
return err
|
||||||
}
|
}
|
||||||
|
|
||||||
|
type AddressSubscribeReq []string
|
||||||
|
type AddressSubscribeResp []string
|
||||||
|
|
||||||
|
// 'blockchain.address.subscribe'
|
||||||
|
func (s *BlockchainAddressService) Subscribe(req *AddressSubscribeReq, resp **AddressSubscribeResp) error {
|
||||||
|
if s.sessionMgr == nil || s.session == nil {
|
||||||
|
return errors.New("no session, rpc not supported")
|
||||||
|
}
|
||||||
|
result := make([]string, 0, len(*req))
|
||||||
|
for _, addr := range *req {
|
||||||
|
address, err := lbcutil.DecodeAddress(addr, s.Chain)
|
||||||
|
if err != nil {
|
||||||
|
return err
|
||||||
|
}
|
||||||
|
script, err := txscript.PayToAddrScript(address)
|
||||||
|
if err != nil {
|
||||||
|
return err
|
||||||
|
}
|
||||||
|
hashX := hashXScript(script, s.Chain)
|
||||||
|
s.sessionMgr.hashXSubscribe(s.session, hashX, addr, true /*subscribe*/)
|
||||||
|
status, err := s.DB.GetStatus(hashX)
|
||||||
|
if err != nil {
|
||||||
|
return err
|
||||||
|
}
|
||||||
|
result = append(result, hex.EncodeToString(status))
|
||||||
|
}
|
||||||
|
*resp = (*AddressSubscribeResp)(&result)
|
||||||
|
return nil
|
||||||
|
}
|
||||||
|
|
||||||
|
// 'blockchain.address.unsubscribe'
|
||||||
|
func (s *BlockchainAddressService) Unsubscribe(req *AddressSubscribeReq, resp **AddressSubscribeResp) error {
|
||||||
|
if s.sessionMgr == nil || s.session == nil {
|
||||||
|
return errors.New("no session, rpc not supported")
|
||||||
|
}
|
||||||
|
for _, addr := range *req {
|
||||||
|
address, err := lbcutil.DecodeAddress(addr, s.Chain)
|
||||||
|
if err != nil {
|
||||||
|
return err
|
||||||
|
}
|
||||||
|
script, err := txscript.PayToAddrScript(address)
|
||||||
|
if err != nil {
|
||||||
|
return err
|
||||||
|
}
|
||||||
|
hashX := hashXScript(script, s.Chain)
|
||||||
|
s.sessionMgr.hashXSubscribe(s.session, hashX, addr, false /*subscribe*/)
|
||||||
|
}
|
||||||
|
*resp = (*AddressSubscribeResp)(nil)
|
||||||
|
return nil
|
||||||
|
}
|
||||||
|
|
||||||
|
type ScripthashSubscribeReq string
|
||||||
|
type ScripthashSubscribeResp string
|
||||||
|
|
||||||
|
// 'blockchain.scripthash.subscribe'
|
||||||
|
func (s *BlockchainScripthashService) Subscribe(req *ScripthashSubscribeReq, resp **ScripthashSubscribeResp) error {
|
||||||
|
if s.sessionMgr == nil || s.session == nil {
|
||||||
|
return errors.New("no session, rpc not supported")
|
||||||
|
}
|
||||||
|
var result string
|
||||||
|
scripthash, err := decodeScriptHash(string(*req))
|
||||||
|
if err != nil {
|
||||||
|
return err
|
||||||
|
}
|
||||||
|
hashX := hashX(scripthash)
|
||||||
|
s.sessionMgr.hashXSubscribe(s.session, hashX, string(*req), true /*subscribe*/)
|
||||||
|
|
||||||
|
status, err := s.DB.GetStatus(hashX)
|
||||||
|
if err != nil {
|
||||||
|
return err
|
||||||
|
}
|
||||||
|
result = hex.EncodeToString(status)
|
||||||
|
*resp = (*ScripthashSubscribeResp)(&result)
|
||||||
|
return nil
|
||||||
|
}
|
||||||
|
|
||||||
|
// 'blockchain.scripthash.unsubscribe'
|
||||||
|
func (s *BlockchainScripthashService) Unsubscribe(req *ScripthashSubscribeReq, resp **ScripthashSubscribeResp) error {
|
||||||
|
if s.sessionMgr == nil || s.session == nil {
|
||||||
|
return errors.New("no session, rpc not supported")
|
||||||
|
}
|
||||||
|
scripthash, err := decodeScriptHash(string(*req))
|
||||||
|
if err != nil {
|
||||||
|
return err
|
||||||
|
}
|
||||||
|
hashX := hashX(scripthash)
|
||||||
|
s.sessionMgr.hashXSubscribe(s.session, hashX, string(*req), false /*subscribe*/)
|
||||||
|
*resp = (*ScripthashSubscribeResp)(nil)
|
||||||
|
return nil
|
||||||
|
}
|
||||||
|
|
|
@ -1,12 +1,18 @@
|
||||||
package server
|
package server
|
||||||
|
|
||||||
import (
|
import (
|
||||||
|
"encoding/hex"
|
||||||
"encoding/json"
|
"encoding/json"
|
||||||
|
"net"
|
||||||
"strconv"
|
"strconv"
|
||||||
|
"sync"
|
||||||
"testing"
|
"testing"
|
||||||
|
|
||||||
"github.com/lbryio/herald.go/db"
|
"github.com/lbryio/herald.go/db"
|
||||||
|
"github.com/lbryio/herald.go/internal"
|
||||||
"github.com/lbryio/lbcd/chaincfg"
|
"github.com/lbryio/lbcd/chaincfg"
|
||||||
|
"github.com/lbryio/lbcd/txscript"
|
||||||
|
"github.com/lbryio/lbcutil"
|
||||||
)
|
)
|
||||||
|
|
||||||
// Source: test_variety_of_transactions_and_longish_history (lbry-sdk/tests/integration/transactions)
|
// Source: test_variety_of_transactions_and_longish_history (lbry-sdk/tests/integration/transactions)
|
||||||
|
@ -58,14 +64,14 @@ func TestServerGetHeight(t *testing.T) {
|
||||||
return
|
return
|
||||||
}
|
}
|
||||||
|
|
||||||
s := &BlockchainService{
|
s := &BlockchainBlockService{
|
||||||
DB: db,
|
DB: db,
|
||||||
Chain: &chaincfg.RegressionNetParams,
|
Chain: &chaincfg.RegressionNetParams,
|
||||||
}
|
}
|
||||||
|
|
||||||
req := BlockGetServerHeightReq{}
|
req := BlockGetServerHeightReq{}
|
||||||
var resp *BlockGetServerHeightResp
|
var resp *BlockGetServerHeightResp
|
||||||
err = s.Get_server_height(nil, &req, &resp)
|
err = s.Get_server_height(&req, &resp)
|
||||||
if err != nil {
|
if err != nil {
|
||||||
t.Errorf("handler err: %v", err)
|
t.Errorf("handler err: %v", err)
|
||||||
}
|
}
|
||||||
|
@ -88,7 +94,7 @@ func TestGetChunk(t *testing.T) {
|
||||||
return
|
return
|
||||||
}
|
}
|
||||||
|
|
||||||
s := &BlockchainService{
|
s := &BlockchainBlockService{
|
||||||
DB: db,
|
DB: db,
|
||||||
Chain: &chaincfg.RegressionNetParams,
|
Chain: &chaincfg.RegressionNetParams,
|
||||||
}
|
}
|
||||||
|
@ -96,7 +102,7 @@ func TestGetChunk(t *testing.T) {
|
||||||
for index := 0; index < 10; index++ {
|
for index := 0; index < 10; index++ {
|
||||||
req := BlockGetChunkReq(index)
|
req := BlockGetChunkReq(index)
|
||||||
var resp *BlockGetChunkResp
|
var resp *BlockGetChunkResp
|
||||||
err := s.Get_chunk(nil, &req, &resp)
|
err := s.Get_chunk(&req, &resp)
|
||||||
if err != nil {
|
if err != nil {
|
||||||
t.Errorf("index: %v handler err: %v", index, err)
|
t.Errorf("index: %v handler err: %v", index, err)
|
||||||
}
|
}
|
||||||
|
@ -131,7 +137,7 @@ func TestGetHeader(t *testing.T) {
|
||||||
return
|
return
|
||||||
}
|
}
|
||||||
|
|
||||||
s := &BlockchainService{
|
s := &BlockchainBlockService{
|
||||||
DB: db,
|
DB: db,
|
||||||
Chain: &chaincfg.RegressionNetParams,
|
Chain: &chaincfg.RegressionNetParams,
|
||||||
}
|
}
|
||||||
|
@ -139,7 +145,7 @@ func TestGetHeader(t *testing.T) {
|
||||||
for height := 0; height < 700; height += 100 {
|
for height := 0; height < 700; height += 100 {
|
||||||
req := BlockGetHeaderReq(height)
|
req := BlockGetHeaderReq(height)
|
||||||
var resp *BlockGetHeaderResp
|
var resp *BlockGetHeaderResp
|
||||||
err := s.Get_header(nil, &req, &resp)
|
err := s.Get_header(&req, &resp)
|
||||||
if err != nil && height <= 500 {
|
if err != nil && height <= 500 {
|
||||||
t.Errorf("height: %v handler err: %v", height, err)
|
t.Errorf("height: %v handler err: %v", height, err)
|
||||||
}
|
}
|
||||||
|
@ -151,6 +157,128 @@ func TestGetHeader(t *testing.T) {
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
|
|
||||||
|
func TestHeaders(t *testing.T) {
|
||||||
|
secondaryPath := "asdf"
|
||||||
|
db, toDefer, err := db.GetProdDB(regTestDBPath, secondaryPath)
|
||||||
|
defer toDefer()
|
||||||
|
if err != nil {
|
||||||
|
t.Error(err)
|
||||||
|
return
|
||||||
|
}
|
||||||
|
|
||||||
|
s := &BlockchainBlockService{
|
||||||
|
DB: db,
|
||||||
|
Chain: &chaincfg.RegressionNetParams,
|
||||||
|
}
|
||||||
|
|
||||||
|
for height := uint32(0); height < 700; height += 100 {
|
||||||
|
req := BlockHeadersReq{
|
||||||
|
StartHeight: height,
|
||||||
|
Count: 1,
|
||||||
|
CpHeight: 0,
|
||||||
|
B64: false,
|
||||||
|
}
|
||||||
|
var resp *BlockHeadersResp
|
||||||
|
err := s.Headers(&req, &resp)
|
||||||
|
marshalled, err := json.MarshalIndent(resp, "", " ")
|
||||||
|
if err != nil {
|
||||||
|
t.Errorf("height: %v unmarshal err: %v", height, err)
|
||||||
|
}
|
||||||
|
t.Logf("height: %v resp: %v", height, string(marshalled))
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
|
func TestHeadersSubscribe(t *testing.T) {
|
||||||
|
secondaryPath := "asdf"
|
||||||
|
db, toDefer, err := db.GetProdDB(regTestDBPath, secondaryPath)
|
||||||
|
defer toDefer()
|
||||||
|
if err != nil {
|
||||||
|
t.Error(err)
|
||||||
|
return
|
||||||
|
}
|
||||||
|
|
||||||
|
sm := newSessionManager(db, &chaincfg.RegressionNetParams, DefaultMaxSessions, DefaultSessionTimeout)
|
||||||
|
sm.start()
|
||||||
|
defer sm.stop()
|
||||||
|
|
||||||
|
client1, server1 := net.Pipe()
|
||||||
|
sess1 := sm.addSession(server1)
|
||||||
|
client2, server2 := net.Pipe()
|
||||||
|
sess2 := sm.addSession(server2)
|
||||||
|
|
||||||
|
// Set up logic to read a notification.
|
||||||
|
var received sync.WaitGroup
|
||||||
|
recv := func(client net.Conn) {
|
||||||
|
buf := make([]byte, 1024)
|
||||||
|
len, err := client.Read(buf)
|
||||||
|
if err != nil {
|
||||||
|
t.Errorf("read err: %v", err)
|
||||||
|
}
|
||||||
|
t.Logf("len: %v notification: %v", len, string(buf))
|
||||||
|
received.Done()
|
||||||
|
}
|
||||||
|
received.Add(2)
|
||||||
|
go recv(client1)
|
||||||
|
go recv(client2)
|
||||||
|
|
||||||
|
s1 := &BlockchainHeadersService{
|
||||||
|
DB: db,
|
||||||
|
Chain: &chaincfg.RegressionNetParams,
|
||||||
|
sessionMgr: sm,
|
||||||
|
session: sess1,
|
||||||
|
}
|
||||||
|
s2 := &BlockchainHeadersService{
|
||||||
|
DB: db,
|
||||||
|
Chain: &chaincfg.RegressionNetParams,
|
||||||
|
sessionMgr: sm,
|
||||||
|
session: sess2,
|
||||||
|
}
|
||||||
|
|
||||||
|
// Subscribe with Raw: false.
|
||||||
|
req1 := HeadersSubscribeReq{Raw: false}
|
||||||
|
var r any
|
||||||
|
err = s1.Subscribe(&req1, &r)
|
||||||
|
if err != nil {
|
||||||
|
t.Errorf("handler err: %v", err)
|
||||||
|
}
|
||||||
|
resp1 := r.(*HeadersSubscribeResp)
|
||||||
|
marshalled1, err := json.MarshalIndent(resp1, "", " ")
|
||||||
|
if err != nil {
|
||||||
|
t.Errorf("unmarshal err: %v", err)
|
||||||
|
}
|
||||||
|
// Subscribe with Raw: true.
|
||||||
|
t.Logf("resp: %v", string(marshalled1))
|
||||||
|
req2 := HeadersSubscribeReq{Raw: true}
|
||||||
|
err = s2.Subscribe(&req2, &r)
|
||||||
|
if err != nil {
|
||||||
|
t.Errorf("handler err: %v", err)
|
||||||
|
}
|
||||||
|
resp2 := r.(*HeadersSubscribeRawResp)
|
||||||
|
marshalled2, err := json.MarshalIndent(resp2, "", " ")
|
||||||
|
if err != nil {
|
||||||
|
t.Errorf("unmarshal err: %v", err)
|
||||||
|
}
|
||||||
|
t.Logf("resp: %v", string(marshalled2))
|
||||||
|
|
||||||
|
// Now send a notification.
|
||||||
|
header500, err := hex.DecodeString("00000020e9537f98ae80a3aa0936dd424439b2b9305e5e9d9d5c7aa571b4422c447741e739b3109304ed4f0330d6854271db17da221559a46b68db4ceecfebd9f0c75dbe0100000000000000000000000000000000000000000000000000000000000000b3e02063ffff7f2001000000")
|
||||||
|
if err != nil {
|
||||||
|
t.Errorf("decode err: %v", err)
|
||||||
|
}
|
||||||
|
note1 := headerNotification{
|
||||||
|
HeightHash: internal.HeightHash{Height: 500},
|
||||||
|
blockHeader: [112]byte{},
|
||||||
|
blockHeaderElectrum: nil,
|
||||||
|
blockHeaderStr: "",
|
||||||
|
}
|
||||||
|
copy(note1.blockHeader[:], header500)
|
||||||
|
t.Logf("sending notification")
|
||||||
|
sm.doNotify(note1)
|
||||||
|
|
||||||
|
t.Logf("waiting to receive notification(s)...")
|
||||||
|
received.Wait()
|
||||||
|
}
|
||||||
|
|
||||||
func TestGetBalance(t *testing.T) {
|
func TestGetBalance(t *testing.T) {
|
||||||
secondaryPath := "asdf"
|
secondaryPath := "asdf"
|
||||||
db, toDefer, err := db.GetProdDB(regTestDBPath, secondaryPath)
|
db, toDefer, err := db.GetProdDB(regTestDBPath, secondaryPath)
|
||||||
|
@ -161,16 +289,14 @@ func TestGetBalance(t *testing.T) {
|
||||||
}
|
}
|
||||||
|
|
||||||
s := &BlockchainAddressService{
|
s := &BlockchainAddressService{
|
||||||
BlockchainService{
|
DB: db,
|
||||||
DB: db,
|
Chain: &chaincfg.RegressionNetParams,
|
||||||
Chain: &chaincfg.RegressionNetParams,
|
|
||||||
},
|
|
||||||
}
|
}
|
||||||
|
|
||||||
for _, addr := range regTestAddrs {
|
for _, addr := range regTestAddrs {
|
||||||
req := AddressGetBalanceReq{addr}
|
req := AddressGetBalanceReq{addr}
|
||||||
var resp *AddressGetBalanceResp
|
var resp *AddressGetBalanceResp
|
||||||
err := s.Get_balance(nil, &req, &resp)
|
err := s.Get_balance(&req, &resp)
|
||||||
if err != nil {
|
if err != nil {
|
||||||
t.Errorf("address: %v handler err: %v", addr, err)
|
t.Errorf("address: %v handler err: %v", addr, err)
|
||||||
}
|
}
|
||||||
|
@ -192,16 +318,14 @@ func TestGetHistory(t *testing.T) {
|
||||||
}
|
}
|
||||||
|
|
||||||
s := &BlockchainAddressService{
|
s := &BlockchainAddressService{
|
||||||
BlockchainService{
|
DB: db,
|
||||||
DB: db,
|
Chain: &chaincfg.RegressionNetParams,
|
||||||
Chain: &chaincfg.RegressionNetParams,
|
|
||||||
},
|
|
||||||
}
|
}
|
||||||
|
|
||||||
for _, addr := range regTestAddrs {
|
for _, addr := range regTestAddrs {
|
||||||
req := AddressGetHistoryReq{addr}
|
req := AddressGetHistoryReq{addr}
|
||||||
var resp *AddressGetHistoryResp
|
var resp *AddressGetHistoryResp
|
||||||
err := s.Get_history(nil, &req, &resp)
|
err := s.Get_history(&req, &resp)
|
||||||
if err != nil {
|
if err != nil {
|
||||||
t.Errorf("address: %v handler err: %v", addr, err)
|
t.Errorf("address: %v handler err: %v", addr, err)
|
||||||
}
|
}
|
||||||
|
@ -223,16 +347,14 @@ func TestListUnspent(t *testing.T) {
|
||||||
}
|
}
|
||||||
|
|
||||||
s := &BlockchainAddressService{
|
s := &BlockchainAddressService{
|
||||||
BlockchainService{
|
DB: db,
|
||||||
DB: db,
|
Chain: &chaincfg.RegressionNetParams,
|
||||||
Chain: &chaincfg.RegressionNetParams,
|
|
||||||
},
|
|
||||||
}
|
}
|
||||||
|
|
||||||
for _, addr := range regTestAddrs {
|
for _, addr := range regTestAddrs {
|
||||||
req := AddressListUnspentReq{addr}
|
req := AddressListUnspentReq{addr}
|
||||||
var resp *AddressListUnspentResp
|
var resp *AddressListUnspentResp
|
||||||
err := s.Listunspent(nil, &req, &resp)
|
err := s.Listunspent(&req, &resp)
|
||||||
if err != nil {
|
if err != nil {
|
||||||
t.Errorf("address: %v handler err: %v", addr, err)
|
t.Errorf("address: %v handler err: %v", addr, err)
|
||||||
}
|
}
|
||||||
|
@ -243,3 +365,92 @@ func TestListUnspent(t *testing.T) {
|
||||||
t.Logf("address: %v resp: %v", addr, string(marshalled))
|
t.Logf("address: %v resp: %v", addr, string(marshalled))
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
|
|
||||||
|
func TestAddressSubscribe(t *testing.T) {
|
||||||
|
secondaryPath := "asdf"
|
||||||
|
db, toDefer, err := db.GetProdDB(regTestDBPath, secondaryPath)
|
||||||
|
defer toDefer()
|
||||||
|
if err != nil {
|
||||||
|
t.Error(err)
|
||||||
|
return
|
||||||
|
}
|
||||||
|
|
||||||
|
sm := newSessionManager(db, &chaincfg.RegressionNetParams, DefaultMaxSessions, DefaultSessionTimeout)
|
||||||
|
sm.start()
|
||||||
|
defer sm.stop()
|
||||||
|
|
||||||
|
client1, server1 := net.Pipe()
|
||||||
|
sess1 := sm.addSession(server1)
|
||||||
|
client2, server2 := net.Pipe()
|
||||||
|
sess2 := sm.addSession(server2)
|
||||||
|
|
||||||
|
// Set up logic to read a notification.
|
||||||
|
var received sync.WaitGroup
|
||||||
|
recv := func(client net.Conn) {
|
||||||
|
buf := make([]byte, 1024)
|
||||||
|
len, err := client.Read(buf)
|
||||||
|
if err != nil {
|
||||||
|
t.Errorf("read err: %v", err)
|
||||||
|
}
|
||||||
|
t.Logf("len: %v notification: %v", len, string(buf))
|
||||||
|
received.Done()
|
||||||
|
}
|
||||||
|
received.Add(2)
|
||||||
|
go recv(client1)
|
||||||
|
go recv(client2)
|
||||||
|
|
||||||
|
s1 := &BlockchainAddressService{
|
||||||
|
DB: db,
|
||||||
|
Chain: &chaincfg.RegressionNetParams,
|
||||||
|
sessionMgr: sm,
|
||||||
|
session: sess1,
|
||||||
|
}
|
||||||
|
s2 := &BlockchainAddressService{
|
||||||
|
DB: db,
|
||||||
|
Chain: &chaincfg.RegressionNetParams,
|
||||||
|
sessionMgr: sm,
|
||||||
|
session: sess2,
|
||||||
|
}
|
||||||
|
|
||||||
|
addr1, addr2 := regTestAddrs[1], regTestAddrs[2]
|
||||||
|
// Subscribe to addr1 and addr2.
|
||||||
|
req1 := AddressSubscribeReq{addr1, addr2}
|
||||||
|
var resp1 *AddressSubscribeResp
|
||||||
|
err = s1.Subscribe(&req1, &resp1)
|
||||||
|
if err != nil {
|
||||||
|
t.Errorf("handler err: %v", err)
|
||||||
|
}
|
||||||
|
marshalled1, err := json.MarshalIndent(resp1, "", " ")
|
||||||
|
if err != nil {
|
||||||
|
t.Errorf("unmarshal err: %v", err)
|
||||||
|
}
|
||||||
|
// Subscribe to addr2 only.
|
||||||
|
t.Logf("resp: %v", string(marshalled1))
|
||||||
|
req2 := AddressSubscribeReq{addr2}
|
||||||
|
var resp2 *AddressSubscribeResp
|
||||||
|
err = s2.Subscribe(&req2, &resp2)
|
||||||
|
if err != nil {
|
||||||
|
t.Errorf("handler err: %v", err)
|
||||||
|
}
|
||||||
|
marshalled2, err := json.MarshalIndent(resp2, "", " ")
|
||||||
|
if err != nil {
|
||||||
|
t.Errorf("unmarshal err: %v", err)
|
||||||
|
}
|
||||||
|
t.Logf("resp: %v", string(marshalled2))
|
||||||
|
|
||||||
|
// Now send a notification for addr2.
|
||||||
|
address, _ := lbcutil.DecodeAddress(addr2, sm.chain)
|
||||||
|
script, _ := txscript.PayToAddrScript(address)
|
||||||
|
note := hashXNotification{}
|
||||||
|
copy(note.hashX[:], hashXScript(script, sm.chain))
|
||||||
|
status, err := hex.DecodeString((*resp1)[1])
|
||||||
|
if err != nil {
|
||||||
|
t.Errorf("decode err: %v", err)
|
||||||
|
}
|
||||||
|
note.status = append(note.status, []byte(status)...)
|
||||||
|
t.Logf("sending notification")
|
||||||
|
sm.doNotify(note)
|
||||||
|
|
||||||
|
t.Logf("waiting to receive notification(s)...")
|
||||||
|
received.Wait()
|
||||||
|
}
|
||||||
|
|
27
server/jsonrpc_claimtrie.go
Normal file
|
@ -0,0 +1,27 @@
|
||||||
|
package server
|
||||||
|
|
||||||
|
import (
|
||||||
|
"github.com/lbryio/herald.go/db"
|
||||||
|
pb "github.com/lbryio/herald.go/protobuf/go"
|
||||||
|
log "github.com/sirupsen/logrus"
|
||||||
|
)
|
||||||
|
|
||||||
|
type ClaimtrieService struct {
|
||||||
|
DB *db.ReadOnlyDBColumnFamily
|
||||||
|
}
|
||||||
|
|
||||||
|
type ResolveData struct {
|
||||||
|
Data []string `json:"data"`
|
||||||
|
}
|
||||||
|
|
||||||
|
type Result struct {
|
||||||
|
Data string `json:"data"`
|
||||||
|
}
|
||||||
|
|
||||||
|
// Resolve is the json rpc endpoint for 'blockchain.claimtrie.resolve'.
|
||||||
|
func (t *ClaimtrieService) Resolve(args *ResolveData, result **pb.Outputs) error {
|
||||||
|
log.Println("Resolve")
|
||||||
|
res, err := InternalResolve(args.Data, t.DB)
|
||||||
|
*result = res
|
||||||
|
return err
|
||||||
|
}
|
|
@ -1,69 +1,133 @@
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
package server
|
package server
|
||||||
|
|
||||||
import (
|
import (
|
||||||
|
"fmt"
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
|
"net"
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
"net/http"
|
"net/http"
|
||||||
|
"strconv"
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
|
"strings"
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
|
|
||||||
"github.com/gorilla/mux"
|
gorilla_mux "github.com/gorilla/mux"
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
"github.com/gorilla/rpc"
|
gorilla_rpc "github.com/gorilla/rpc"
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
"github.com/gorilla/rpc/json"
|
gorilla_json "github.com/gorilla/rpc/json"
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
"github.com/lbryio/herald.go/db"
|
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
pb "github.com/lbryio/herald.go/protobuf/go"
|
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
log "github.com/sirupsen/logrus"
|
log "github.com/sirupsen/logrus"
|
||||||
|
"golang.org/x/net/netutil"
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
)
|
)
|
||||||
|
|
||||||
type ClaimtrieService struct {
|
type gorillaRpcCodec struct {
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
DB *db.ReadOnlyDBColumnFamily
|
gorilla_rpc.Codec
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
}
|
}
|
||||||
|
|
||||||
type ResolveData struct {
|
func (c *gorillaRpcCodec) NewRequest(r *http.Request) gorilla_rpc.CodecRequest {
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
Data []string `json:"data"`
|
return &gorillaRpcCodecRequest{c.Codec.NewRequest(r)}
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
}
|
}
|
||||||
|
|
||||||
type Result struct {
|
// gorillaRpcCodecRequest provides ability to rewrite the incoming
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
Data string `json:"data"`
|
// request "method" field. For example:
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
|
// blockchain.block.get_header -> blockchain_block.Get_header
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
|
// blockchain.address.listunspent -> blockchain_address.Listunspent
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
|
// This makes the "method" string compatible with Gorilla/RPC
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
|
// requirements.
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
|
type gorillaRpcCodecRequest struct {
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
|
gorilla_rpc.CodecRequest
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
}
|
}
|
||||||
|
|
||||||
// Resolve is the json rpc endpoint for 'blockchain.claimtrie.resolve'.
|
func (cr *gorillaRpcCodecRequest) Method() (string, error) {
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
func (t *ClaimtrieService) Resolve(r *http.Request, args *ResolveData, result **pb.Outputs) error {
|
rawMethod, err := cr.CodecRequest.Method()
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
log.Println("Resolve")
|
if err != nil {
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
res, err := InternalResolve(args.Data, t.DB)
|
return rawMethod, err
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
*result = res
|
}
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
return err
|
parts := strings.Split(rawMethod, ".")
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
|
if len(parts) < 2 {
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
|
return rawMethod, fmt.Errorf("blockchain rpc: service/method ill-formed: %q", rawMethod)
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
|
}
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
|
service := strings.Join(parts[0:len(parts)-1], "_")
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
|
method := parts[len(parts)-1]
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
|
if len(method) < 1 {
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
|
return rawMethod, fmt.Errorf("blockchain rpc: method ill-formed: %q", method)
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
|
}
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
|
method = strings.ToUpper(string(method[0])) + string(method[1:])
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
|
return service + "." + method, err
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
}
|
}
|
||||||
|
|
||||||
// StartJsonRPC starts the json rpc server and registers the endpoints.
|
// StartJsonRPC starts the json rpc server and registers the endpoints.
|
||||||
func (s *Server) StartJsonRPC() error {
|
func (s *Server) StartJsonRPC() error {
|
||||||
port := ":" + s.Args.JSONRPCPort
|
s.sessionManager.start()
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
|
defer s.sessionManager.stop()
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
|
|
||||||
s1 := rpc.NewServer() // Create a new RPC server
|
// Set up the pure JSONRPC server with persistent connections/sessions.
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
// Register the type of data requested as JSON, with custom codec.
|
if s.Args.JSONRPCPort != 0 {
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
s1.RegisterCodec(&BlockchainCodec{json.NewCodec()}, "application/json")
|
port := ":" + strconv.FormatUint(uint64(s.Args.JSONRPCPort), 10)
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
|
laddr, err := net.ResolveTCPAddr("tcp", port)
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
// Register "blockchain.claimtrie.*"" handlers.
|
if err != nil {
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
claimtrieSvc := &ClaimtrieService{s.DB}
|
log.Errorf("ResoveIPAddr: %v\n", err)
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
err := s1.RegisterService(claimtrieSvc, "blockchain_claimtrie")
|
goto fail1
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
if err != nil {
|
}
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
log.Errorf("RegisterService: %v\n", err)
|
listener, err := net.ListenTCP("tcp", laddr)
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
|
if err != nil {
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
|
log.Errorf("ListenTCP: %v\n", err)
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
|
goto fail1
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
|
}
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
|
log.Infof("JSONRPC server listening on %s", listener.Addr().String())
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
|
acceptConnections := func(listener net.Listener) {
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
|
for {
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
|
conn, err := listener.Accept()
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
|
if err != nil {
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
|
log.Errorf("Accept: %v\n", err)
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
|
break
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
|
}
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
|
log.Infof("Accepted: %v", conn.RemoteAddr())
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
|
s.sessionManager.addSession(conn)
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
|
}
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
|
}
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
|
go acceptConnections(netutil.LimitListener(listener, s.sessionManager.sessionsMax))
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
}
|
}
|
||||||
|
|
||||||
// Register other "blockchain.{block,address,scripthash}.*" handlers.
|
fail1:
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
blockchainSvc := &BlockchainService{s.DB, s.Chain}
|
// Set up the JSONRPC over HTTP server.
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
err = s1.RegisterService(blockchainSvc, "blockchain_block")
|
if s.Args.JSONRPCHTTPPort != 0 {
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
if err != nil {
|
s1 := gorilla_rpc.NewServer() // Create a new RPC server
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
log.Errorf("RegisterService: %v\n", err)
|
// Register the type of data requested as JSON, with custom codec.
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
}
|
s1.RegisterCodec(&gorillaRpcCodec{gorilla_json.NewCodec()}, "application/json")
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
err = s1.RegisterService(&BlockchainAddressService{*blockchainSvc}, "blockchain_address")
|
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
if err != nil {
|
// Register "blockchain.claimtrie.*"" handlers.
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
log.Errorf("RegisterService: %v\n", err)
|
claimtrieSvc := &ClaimtrieService{s.DB}
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
}
|
err := s1.RegisterTCPService(claimtrieSvc, "blockchain_claimtrie")
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
err = s1.RegisterService(&BlockchainScripthashService{*blockchainSvc}, "blockchain_scripthash")
|
if err != nil {
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
if err != nil {
|
log.Errorf("RegisterTCPService: %v\n", err)
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
log.Errorf("RegisterService: %v\n", err)
|
goto fail2
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
|
}
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
|
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
|
// Register other "blockchain.{block,address,scripthash}.*" handlers.
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
|
blockchainSvc := &BlockchainBlockService{s.DB, s.Chain}
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
|
err = s1.RegisterTCPService(blockchainSvc, "blockchain_block")
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
|
if err != nil {
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
|
log.Errorf("RegisterTCPService: %v\n", err)
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
|
goto fail2
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
|
}
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
|
err = s1.RegisterTCPService(&BlockchainHeadersService{s.DB, s.Chain, nil, nil}, "blockchain_headers")
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
|
if err != nil {
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
|
log.Errorf("RegisterTCPService: %v\n", err)
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
|
goto fail2
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
|
}
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
|
err = s1.RegisterTCPService(&BlockchainAddressService{s.DB, s.Chain, nil, nil}, "blockchain_address")
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
|
if err != nil {
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
|
log.Errorf("RegisterTCPService: %v\n", err)
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
|
goto fail2
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
|
}
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
|
err = s1.RegisterTCPService(&BlockchainScripthashService{s.DB, s.Chain, nil, nil}, "blockchain_scripthash")
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
|
if err != nil {
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
|
log.Errorf("RegisterTCPService: %v\n", err)
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
|
goto fail2
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
|
}
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
|
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
|
r := gorilla_mux.NewRouter()
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
|
r.Handle("/rpc", s1)
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
|
port := ":" + strconv.FormatUint(uint64(s.Args.JSONRPCHTTPPort), 10)
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
|
log.Infof("HTTP JSONRPC server listening on %s", port)
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
|
log.Fatal(http.ListenAndServe(port, r))
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
}
|
}
|
||||||
|
|
||||||
r := mux.NewRouter()
|
fail2:
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
r.Handle("/rpc", s1)
|
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
log.Fatal(http.ListenAndServe(port, r))
|
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
|
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|||||||
return nil
|
return nil
|
||||||
}
|
}
|
||||||
|
|
||||||
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward? This looks like an infinite for that only triggers if JSONRPCPort != 0, and then breaks unconditionally? Wouldn't an if statement do the same and be less awkward?
Same thing here, is this for needed? Same thing here, is this for needed?
I found that I found that `break` only works inside `for`. That's the reason. I wanted to bail out of the block of code setting up the pure JSON server if anything failed so that it would continue on and set up the alternate HTTP-based server.
|
|
@ -52,8 +52,13 @@ func (s *Server) DoNotify(heightHash *internal.HeightHash) error {
|
||||||
|
|
||||||
// RunNotifier Runs the notfying action forever
|
// RunNotifier Runs the notfying action forever
|
||||||
func (s *Server) RunNotifier() error {
|
func (s *Server) RunNotifier() error {
|
||||||
for heightHash := range s.NotifierChan {
|
for notification := range s.NotifierChan {
|
||||||
s.DoNotify(heightHash)
|
switch notification.(type) {
|
||||||
|
case internal.HeightHash:
|
||||||
|
heightHash, _ := notification.(internal.HeightHash)
|
||||||
|
s.DoNotify(&heightHash)
|
||||||
|
}
|
||||||
|
s.sessionManager.doNotify(notification)
|
||||||
}
|
}
|
||||||
return nil
|
return nil
|
||||||
}
|
}
|
||||||
|
|
|
@ -80,7 +80,7 @@ func TestNotifierServer(t *testing.T) {
|
||||||
|
|
||||||
hash, _ := hex.DecodeString("AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA")
|
hash, _ := hex.DecodeString("AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA")
|
||||||
logrus.Warn("sending hash")
|
logrus.Warn("sending hash")
|
||||||
hub.NotifierChan <- &internal.HeightHash{Height: 1, BlockHash: hash}
|
hub.NotifierChan <- internal.HeightHash{Height: 1, BlockHash: hash}
|
||||||
|
|
||||||
res := <-resCh
|
res := <-resCh
|
||||||
logrus.Info(string(res))
|
logrus.Info(string(res))
|
||||||
|
|
|
@ -18,7 +18,6 @@ import (
|
||||||
|
|
||||||
"github.com/ReneKroon/ttlcache/v2"
|
"github.com/ReneKroon/ttlcache/v2"
|
||||||
"github.com/lbryio/herald.go/db"
|
"github.com/lbryio/herald.go/db"
|
||||||
"github.com/lbryio/herald.go/internal"
|
|
||||||
"github.com/lbryio/herald.go/internal/metrics"
|
"github.com/lbryio/herald.go/internal/metrics"
|
||||||
"github.com/lbryio/herald.go/meta"
|
"github.com/lbryio/herald.go/meta"
|
||||||
pb "github.com/lbryio/herald.go/protobuf/go"
|
pb "github.com/lbryio/herald.go/protobuf/go"
|
||||||
|
@ -53,7 +52,8 @@ type Server struct {
|
||||||
ExternalIP net.IP
|
ExternalIP net.IP
|
||||||
HeightSubs map[net.Addr]net.Conn
|
HeightSubs map[net.Addr]net.Conn
|
||||||
HeightSubsMut sync.RWMutex
|
HeightSubsMut sync.RWMutex
|
||||||
NotifierChan chan *internal.HeightHash
|
NotifierChan chan interface{}
|
||||||
|
sessionManager *sessionManager
|
||||||
pb.UnimplementedHubServer
|
pb.UnimplementedHubServer
|
||||||
}
|
}
|
||||||
|
|
||||||
|
@ -332,7 +332,8 @@ func MakeHubServer(ctx context.Context, args *Args) *Server {
|
||||||
ExternalIP: net.IPv4(127, 0, 0, 1),
|
ExternalIP: net.IPv4(127, 0, 0, 1),
|
||||||
HeightSubs: make(map[net.Addr]net.Conn),
|
HeightSubs: make(map[net.Addr]net.Conn),
|
||||||
HeightSubsMut: sync.RWMutex{},
|
HeightSubsMut: sync.RWMutex{},
|
||||||
NotifierChan: make(chan *internal.HeightHash),
|
NotifierChan: make(chan interface{}),
|
||||||
|
sessionManager: newSessionManager(myDB, &chain, args.MaxSessions, args.SessionTimeout),
|
||||||
}
|
}
|
||||||
|
|
||||||
// Start up our background services
|
// Start up our background services
|
||||||
|
|
383
server/session.go
Normal file
|
@ -0,0 +1,383 @@
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
package server
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
import (
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
"encoding/hex"
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
"fmt"
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
"net"
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
"net/rpc"
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
"net/rpc/jsonrpc"
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
"strings"
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
"sync"
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
"time"
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
"unsafe"
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
"github.com/lbryio/herald.go/db"
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
"github.com/lbryio/herald.go/internal"
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
"github.com/lbryio/lbcd/chaincfg"
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
log "github.com/sirupsen/logrus"
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
)
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
type headerNotification struct {
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
internal.HeightHash
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
blockHeader [HEADER_SIZE]byte
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
blockHeaderElectrum *BlockHeaderElectrum
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
blockHeaderStr string
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
}
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
type hashXNotification struct {
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
hashX [HASHX_LEN]byte
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
status []byte
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
statusStr string
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
}
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
type session struct {
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
id uintptr
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
addr net.Addr
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
conn net.Conn
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
// hashXSubs maps hashX to the original subscription key (address or scripthash)
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
hashXSubs map[[HASHX_LEN]byte]string
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
// headersSub indicates header subscription
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
headersSub bool
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
// headersSubRaw indicates the header subscription mode
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
headersSubRaw bool
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
// client provides the ability to send notifications
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
client rpc.ClientCodec
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
clientSeq uint64
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
// lastRecv records time of last incoming data
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
lastRecv time.Time
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
// lastSend records time of last outgoing data
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
lastSend time.Time
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
}
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
func (s *session) doNotify(notification interface{}) {
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
var method string
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
var params interface{}
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
switch notification.(type) {
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
case headerNotification:
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
if !s.headersSub {
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
return
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
}
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
note, _ := notification.(headerNotification)
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
heightHash := note.HeightHash
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
method = "blockchain.headers.subscribe"
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
if s.headersSubRaw {
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
header := note.blockHeaderStr
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
if len(header) == 0 {
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
header = hex.EncodeToString(note.blockHeader[:])
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
}
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
params = &HeadersSubscribeRawResp{
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
Hex: header,
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
Height: uint32(heightHash.Height),
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
}
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
} else {
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
header := note.blockHeaderElectrum
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
if header == nil { // not initialized
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
header = newBlockHeaderElectrum(¬e.blockHeader, uint32(heightHash.Height))
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
}
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
params = header
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
}
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
case hashXNotification:
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
note, _ := notification.(hashXNotification)
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
orig, ok := s.hashXSubs[note.hashX]
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
if !ok {
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
return
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
}
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
if len(orig) == 64 {
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
method = "blockchain.scripthash.subscribe"
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
} else {
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
method = "blockchain.address.subscribe"
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
}
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
status := note.statusStr
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
if len(status) == 0 {
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
status = hex.EncodeToString(note.status)
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
}
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
params = []string{orig, status}
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
default:
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
log.Warnf("unknown notification type: %v", notification)
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
return
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
}
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
// Send the notification.
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
s.clientSeq += 1
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
req := &rpc.Request{
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
ServiceMethod: method,
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
Seq: s.clientSeq,
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
}
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
err := s.client.WriteRequest(req, params)
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
if err != nil {
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
log.Warnf("error: %v", err)
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
}
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
// Bump last send time.
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
s.lastSend = time.Now()
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
}
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
type sessionMap map[uintptr]*session
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
type sessionManager struct {
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
// sessionsMut protects sessions, headerSubs, hashXSubs state
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
sessionsMut sync.RWMutex
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
sessions sessionMap
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
sessionsWait sync.WaitGroup
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
sessionsMax int
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
sessionTimeout time.Duration
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
manageTicker *time.Ticker
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
db *db.ReadOnlyDBColumnFamily
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
chain *chaincfg.Params
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
// headerSubs are sessions subscribed via 'blockchain.headers.subscribe'
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
headerSubs sessionMap
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
// hashXSubs are sessions subscribed via 'blockchain.{address,scripthash}.subscribe'
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
hashXSubs map[[HASHX_LEN]byte]sessionMap
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
}
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
func newSessionManager(db *db.ReadOnlyDBColumnFamily, chain *chaincfg.Params, sessionsMax, sessionTimeout int) *sessionManager {
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
return &sessionManager{
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
sessions: make(sessionMap),
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
sessionsMax: sessionsMax,
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
sessionTimeout: time.Duration(sessionTimeout) * time.Second,
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
manageTicker: time.NewTicker(time.Duration(max(5, sessionTimeout/20)) * time.Second),
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
db: db,
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
chain: chain,
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
headerSubs: make(sessionMap),
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
hashXSubs: make(map[[HASHX_LEN]byte]sessionMap),
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
}
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
}
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
func (sm *sessionManager) start() {
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
go sm.manage()
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
}
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
func (sm *sessionManager) stop() {
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
sm.sessionsMut.Lock()
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
defer sm.sessionsMut.Unlock()
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
sm.headerSubs = make(sessionMap)
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
sm.hashXSubs = make(map[[HASHX_LEN]byte]sessionMap)
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
for _, sess := range sm.sessions {
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
sess.client.Close()
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
sess.conn.Close()
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
}
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
sm.sessions = make(sessionMap)
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
}
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
func (sm *sessionManager) manage() {
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
for {
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
sm.sessionsMut.Lock()
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
for _, sess := range sm.sessions {
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
if time.Since(sess.lastRecv) > sm.sessionTimeout {
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
sm.removeSessionLocked(sess)
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
log.Infof("session %v timed out", sess.addr.String())
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
}
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
}
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
sm.sessionsMut.Unlock()
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
// Wait for next management clock tick.
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
<-sm.manageTicker.C
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
}
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
}
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
func (sm *sessionManager) addSession(conn net.Conn) *session {
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
sm.sessionsMut.Lock()
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
sess := &session{
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
addr: conn.RemoteAddr(),
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
conn: conn,
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
hashXSubs: make(map[[11]byte]string),
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
client: jsonrpc.NewClientCodec(conn),
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
lastRecv: time.Now(),
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
}
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
sess.id = uintptr(unsafe.Pointer(sess))
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
sm.sessions[sess.id] = sess
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
sm.sessionsMut.Unlock()
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
// Create a new RPC server. These services are linked to the
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
// session, which allows RPC handlers to know the session for
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
// each request and update subscriptions.
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
s1 := rpc.NewServer()
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
// Register "blockchain.claimtrie.*"" handlers.
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
claimtrieSvc := &ClaimtrieService{sm.db}
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
err := s1.RegisterName("blockchain.claimtrie", claimtrieSvc)
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
if err != nil {
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
log.Errorf("RegisterService: %v\n", err)
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
}
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
// Register other "blockchain.{block,address,scripthash}.*" handlers.
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
blockchainSvc := &BlockchainBlockService{sm.db, sm.chain}
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
err = s1.RegisterName("blockchain.block", blockchainSvc)
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
if err != nil {
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
log.Errorf("RegisterName: %v\n", err)
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
goto fail
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
}
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
err = s1.RegisterName("blockchain.headers", &BlockchainHeadersService{sm.db, sm.chain, sm, sess})
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
if err != nil {
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
log.Errorf("RegisterName: %v\n", err)
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
goto fail
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
}
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
err = s1.RegisterName("blockchain.address", &BlockchainAddressService{sm.db, sm.chain, sm, sess})
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
if err != nil {
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
log.Errorf("RegisterName: %v\n", err)
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
goto fail
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
}
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
err = s1.RegisterName("blockchain.scripthash", &BlockchainScripthashService{sm.db, sm.chain, sm, sess})
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
if err != nil {
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
log.Errorf("RegisterName: %v\n", err)
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
goto fail
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
}
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
sm.sessionsWait.Add(1)
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
go func() {
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
s1.ServeCodec(&SessionServerCodec{jsonrpc.NewServerCodec(conn), sess})
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
log.Infof("session %v goroutine exit", sess.addr.String())
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
sm.sessionsWait.Done()
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
}()
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
return sess
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
fail:
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
sm.removeSession(sess)
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
return nil
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
}
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
func (sm *sessionManager) removeSession(sess *session) {
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
sm.sessionsMut.Lock()
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
defer sm.sessionsMut.Unlock()
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
sm.removeSessionLocked(sess)
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
}
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
func (sm *sessionManager) removeSessionLocked(sess *session) {
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
if sess.headersSub {
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
delete(sm.headerSubs, sess.id)
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
}
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
for hashX := range sess.hashXSubs {
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
subs, ok := sm.hashXSubs[hashX]
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
if !ok {
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
continue
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
}
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
delete(subs, sess.id)
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
}
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
delete(sm.sessions, sess.id)
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
sess.client.Close()
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
sess.conn.Close()
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
}
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
func (sm *sessionManager) headersSubscribe(sess *session, raw bool, subscribe bool) {
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
sm.sessionsMut.Lock()
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
defer sm.sessionsMut.Unlock()
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
if subscribe {
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
sm.headerSubs[sess.id] = sess
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
sess.headersSub = true
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
sess.headersSubRaw = raw
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
return
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
}
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
delete(sm.headerSubs, sess.id)
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
sess.headersSub = false
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
sess.headersSubRaw = false
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
}
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
func (sm *sessionManager) hashXSubscribe(sess *session, hashX []byte, original string, subscribe bool) {
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
sm.sessionsMut.Lock()
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
defer sm.sessionsMut.Unlock()
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
var key [HASHX_LEN]byte
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
copy(key[:], hashX)
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
subs, ok := sm.hashXSubs[key]
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
if subscribe {
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
if !ok {
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
subs = make(sessionMap)
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
sm.hashXSubs[key] = subs
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
}
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
subs[sess.id] = sess
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
sess.hashXSubs[key] = original
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
return
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
}
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
if ok {
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
delete(subs, sess.id)
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
if len(subs) == 0 {
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
delete(sm.hashXSubs, key)
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
}
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
}
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
delete(sess.hashXSubs, key)
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
}
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
func (sm *sessionManager) doNotify(notification interface{}) {
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
sm.sessionsMut.RLock()
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
var subsCopy sessionMap
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
switch notification.(type) {
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
case headerNotification:
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
note, _ := notification.(headerNotification)
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
subsCopy = sm.headerSubs
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
if len(subsCopy) > 0 {
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
note.blockHeaderElectrum = newBlockHeaderElectrum(¬e.blockHeader, uint32(note.Height))
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
note.blockHeaderStr = hex.EncodeToString(note.blockHeader[:])
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
}
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
case hashXNotification:
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
note, _ := notification.(hashXNotification)
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
hashXSubs, ok := sm.hashXSubs[note.hashX]
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
if ok {
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
subsCopy = hashXSubs
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
}
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
if len(subsCopy) > 0 {
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
note.statusStr = hex.EncodeToString(note.status)
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
}
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
default:
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
log.Warnf("unknown notification type: %v", notification)
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
}
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
sm.sessionsMut.RUnlock()
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
// Deliver notification to relevant sessions.
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
for _, sess := range subsCopy {
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
sess.doNotify(notification)
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
}
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
}
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
type SessionServerCodec struct {
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
rpc.ServerCodec
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
sess *session
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
}
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
// ReadRequestHeader provides ability to rewrite the incoming
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
// request "method" field. For example:
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
// blockchain.block.get_header -> blockchain.block.Get_header
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
// blockchain.address.listunspent -> blockchain.address.Listunspent
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
// This makes the "method" string compatible with rpc.Server
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
// requirements.
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
func (c *SessionServerCodec) ReadRequestHeader(req *rpc.Request) error {
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
log.Infof("receive header from %v", c.sess.addr.String())
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
err := c.ServerCodec.ReadRequestHeader(req)
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
if err != nil {
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
log.Warnf("error: %v", err)
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
return err
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
}
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
rawMethod := req.ServiceMethod
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
parts := strings.Split(rawMethod, ".")
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
if len(parts) < 2 {
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
return fmt.Errorf("blockchain rpc: service/method ill-formed: %q", rawMethod)
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
}
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
service := strings.Join(parts[0:len(parts)-1], ".")
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
method := parts[len(parts)-1]
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
if len(method) < 1 {
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
return fmt.Errorf("blockchain rpc: method ill-formed: %q", method)
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
}
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
method = strings.ToUpper(string(method[0])) + string(method[1:])
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
req.ServiceMethod = service + "." + method
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
return err
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
}
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
// ReadRequestBody wraps the regular implementation, but updates session stats too.
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
func (c *SessionServerCodec) ReadRequestBody(params any) error {
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
err := c.ServerCodec.ReadRequestBody(params)
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
if err != nil {
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
log.Warnf("error: %v", err)
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
return err
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
}
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
log.Infof("receive body from %v", c.sess.addr.String())
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
// Bump last receive time.
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
c.sess.lastRecv = time.Now()
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
return err
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
}
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
// WriteResponse wraps the regular implementation, but updates session stats too.
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
func (c *SessionServerCodec) WriteResponse(resp *rpc.Response, reply any) error {
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
log.Infof("respond to %v", c.sess.addr.String())
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
err := c.ServerCodec.WriteResponse(resp, reply)
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
if err != nil {
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
return err
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
}
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
// Bump last send time.
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
c.sess.lastSend = time.Now()
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
return err
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
|||||||
|
}
|
||||||
This is one of the biggest obstacles to limiting the number of go-routines. I have to call This is one of the biggest obstacles to limiting the number of go-routines. I have to call `ServeCodec()` in a new go-routine in order to allow more than one session at a time, and I don't know how to control/track this routine.
Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time? Interesting way to keep this running forever, I think it spawns a new goroutine every time, it might be better to just use this in an intfinite loop with a sleep, and maybe parametarize the polling time?
Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down. Using Ticker object now. The Ticker.Reset() method can be used in unit tests to adjust frequency up/down.
|
@jackrobison Can you confirm that the lookup should go to HashXMempoolStatus first, return if found, then go to HashXStatus?