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
|
||||
// to keep the db readonly view up to date and handle reorgs on the
|
||||
// blockchain.
|
||||
func (db *ReadOnlyDBColumnFamily) RunDetectChanges(notifCh chan *internal.HeightHash) {
|
||||
func (db *ReadOnlyDBColumnFamily) RunDetectChanges(notifCh chan<- interface{}) {
|
||||
go func() {
|
||||
lastPrint := time.Now()
|
||||
for {
|
||||
|
@ -674,7 +674,7 @@ func (db *ReadOnlyDBColumnFamily) RunDetectChanges(notifCh chan *internal.Height
|
|||
}
|
||||
|
||||
// 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()
|
||||
if err != nil {
|
||||
return err
|
||||
|
|
67
db/db_get.go
|
@ -3,6 +3,7 @@ package db
|
|||
// db_get.go contains the basic access functions to the database.
|
||||
|
||||
import (
|
||||
"crypto/sha256"
|
||||
"encoding/hex"
|
||||
"fmt"
|
||||
"log"
|
||||
|
@ -266,6 +267,72 @@ func (db *ReadOnlyDBColumnFamily) GetHistory(hashX []byte) ([]TxInfo, error) {
|
|||
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.
|
||||
func (db *ReadOnlyDBColumnFamily) GetStreamsAndChannelRepostedByChannelHashes(reposterChannelHashes [][]byte) (map[string][]byte, map[string][]byte, error) {
|
||||
handle, err := db.EnsureHandle(prefixes.ChannelToClaim)
|
||||
|
|
|
@ -3,6 +3,7 @@ package server
|
|||
import (
|
||||
"log"
|
||||
"os"
|
||||
"strconv"
|
||||
"strings"
|
||||
|
||||
"github.com/akamensky/argparse"
|
||||
|
@ -27,7 +28,10 @@ type Args struct {
|
|||
EsPort string
|
||||
PrometheusPort string
|
||||
NotifierPort string
|
||||
JSONRPCPort string
|
||||
JSONRPCPort int
|
||||
JSONRPCHTTPPort int
|
||||
MaxSessions int
|
||||
SessionTimeout int
|
||||
EsIndex string
|
||||
RefreshDelta int
|
||||
CacheTTL int
|
||||
|
@ -58,7 +62,9 @@ const (
|
|||
DefaultEsPort = "9200"
|
||||
DefaultPrometheusPort = "2112"
|
||||
DefaultNotifierPort = "18080"
|
||||
DefaultJSONRPCPort = "50001"
|
||||
DefaultJSONRPCPort = 50001
|
||||
DefaultMaxSessions = 10000
|
||||
DefaultSessionTimeout = 300
|
||||
DefaultRefreshDelta = 5
|
||||
DefaultCacheTTL = 5
|
||||
DefaultPeerFile = "peers.txt"
|
||||
|
@ -111,6 +117,11 @@ func ParseArgs(searchRequest *pb.SearchRequest) *Args {
|
|||
searchCmd := parser.NewCommand("search", "claim search")
|
||||
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})
|
||||
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})
|
||||
|
@ -120,7 +131,10 @@ func ParseArgs(searchRequest *pb.SearchRequest) *Args {
|
|||
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})
|
||||
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})
|
||||
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})
|
||||
|
@ -158,6 +172,11 @@ func ParseArgs(searchRequest *pb.SearchRequest) *Args {
|
|||
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{
|
||||
CmdType: SearchCmd,
|
||||
Host: *host,
|
||||
|
@ -169,6 +188,9 @@ func ParseArgs(searchRequest *pb.SearchRequest) *Args {
|
|||
PrometheusPort: *prometheusPort,
|
||||
NotifierPort: *notifierPort,
|
||||
JSONRPCPort: *jsonRPCPort,
|
||||
JSONRPCHTTPPort: *jsonRPCHTTPPort,
|
||||
MaxSessions: *maxSessions,
|
||||
SessionTimeout: *sessionTimeout,
|
||||
EsIndex: *esIndex,
|
||||
RefreshDelta: *refreshDelta,
|
||||
CacheTTL: *cacheTTL,
|
||||
|
|
|
@ -9,10 +9,7 @@ import (
|
|||
"encoding/hex"
|
||||
"errors"
|
||||
"fmt"
|
||||
"net/http"
|
||||
"strings"
|
||||
|
||||
"github.com/gorilla/rpc"
|
||||
"github.com/lbryio/herald.go/db"
|
||||
"github.com/lbryio/herald.go/internal"
|
||||
"github.com/lbryio/lbcd/chaincfg"
|
||||
|
@ -23,56 +20,37 @@ import (
|
|||
"golang.org/x/exp/constraints"
|
||||
)
|
||||
|
||||
type BlockchainCodec struct {
|
||||
rpc.Codec
|
||||
}
|
||||
|
||||
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 {
|
||||
// BlockchainBlockService methods handle "blockchain.block.*" RPCs
|
||||
type BlockchainBlockService struct {
|
||||
DB *db.ReadOnlyDBColumnFamily
|
||||
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
|
||||
type BlockchainAddressService struct {
|
||||
BlockchainService
|
||||
DB *db.ReadOnlyDBColumnFamily
|
||||
Chain *chaincfg.Params
|
||||
// needed for subscribe/unsubscribe
|
||||
sessionMgr *sessionManager
|
||||
session *session
|
||||
}
|
||||
|
||||
// BlockchainScripthashService methods handle "blockchain.scripthash.*" RPCs
|
||||
type BlockchainScripthashService struct {
|
||||
BlockchainService
|
||||
DB *db.ReadOnlyDBColumnFamily
|
||||
Chain *chaincfg.Params
|
||||
// needed for subscribe/unsubscribe
|
||||
sessionMgr *sessionManager
|
||||
session *session
|
||||
}
|
||||
|
||||
const CHUNK_SIZE = 96
|
||||
|
@ -87,10 +65,45 @@ func min[Ord constraints.Ordered](x, y Ord) Ord {
|
|||
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 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 {
|
||||
return fmt.Errorf("unknown height")
|
||||
}
|
||||
|
@ -103,7 +116,7 @@ type BlockGetChunkReq uint32
|
|||
type BlockGetChunkResp string
|
||||
|
||||
// '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)
|
||||
db_headers, err := s.DB.GetHeaders(index*CHUNK_SIZE, CHUNK_SIZE)
|
||||
if err != nil {
|
||||
|
@ -120,18 +133,11 @@ func (s *BlockchainService) Get_chunk(r *http.Request, req *BlockGetChunkReq, re
|
|||
|
||||
type BlockGetHeaderReq uint32
|
||||
type BlockGetHeaderResp 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"`
|
||||
BlockHeaderElectrum
|
||||
}
|
||||
|
||||
// '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)
|
||||
headers, err := s.DB.GetHeaders(height, 1)
|
||||
if err != nil {
|
||||
|
@ -140,23 +146,7 @@ func (s *BlockchainService) Get_header(r *http.Request, req *BlockGetHeaderReq,
|
|||
if len(headers) < 1 {
|
||||
return errors.New("not found")
|
||||
}
|
||||
decode := func(header *[HEADER_SIZE]byte, height uint32) *BlockGetHeaderResp {
|
||||
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)
|
||||
*resp = &BlockGetHeaderResp{*newBlockHeaderElectrum(&headers[0], height)}
|
||||
return err
|
||||
}
|
||||
|
||||
|
@ -177,7 +167,7 @@ type BlockHeadersResp struct {
|
|||
}
|
||||
|
||||
// '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)
|
||||
db_headers, err := s.DB.GetHeaders(req.StartHeight, count)
|
||||
if err != nil {
|
||||
|
@ -209,6 +199,47 @@ func (s *BlockchainService) Headers(r *http.Request, req *BlockHeadersReq, resp
|
|||
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) {
|
||||
sh, err := hex.DecodeString(scripthash)
|
||||
if err != nil {
|
||||
|
@ -249,7 +280,7 @@ type AddressGetBalanceResp struct {
|
|||
}
|
||||
|
||||
// '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)
|
||||
if err != nil {
|
||||
return err
|
||||
|
@ -276,7 +307,7 @@ type ScripthashGetBalanceResp struct {
|
|||
}
|
||||
|
||||
// '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)
|
||||
if err != nil {
|
||||
return err
|
||||
|
@ -307,7 +338,7 @@ type AddressGetHistoryResp struct {
|
|||
}
|
||||
|
||||
// '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)
|
||||
if err != nil {
|
||||
return err
|
||||
|
@ -346,7 +377,7 @@ type ScripthashGetHistoryResp struct {
|
|||
}
|
||||
|
||||
// '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)
|
||||
if err != nil {
|
||||
return err
|
||||
|
@ -378,7 +409,7 @@ type AddressGetMempoolReq struct {
|
|||
type AddressGetMempoolResp []TxInfoFee
|
||||
|
||||
// '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)
|
||||
if err != nil {
|
||||
return err
|
||||
|
@ -402,7 +433,7 @@ type ScripthashGetMempoolReq struct {
|
|||
type ScripthashGetMempoolResp []TxInfoFee
|
||||
|
||||
// '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)
|
||||
if err != nil {
|
||||
return err
|
||||
|
@ -428,7 +459,7 @@ type TXOInfo struct {
|
|||
type AddressListUnspentResp []TXOInfo
|
||||
|
||||
// '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)
|
||||
if err != nil {
|
||||
return err
|
||||
|
@ -460,7 +491,7 @@ type ScripthashListUnspentReq struct {
|
|||
type ScripthashListUnspentResp []TXOInfo
|
||||
|
||||
// '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)
|
||||
if err != nil {
|
||||
return err
|
||||
|
@ -481,3 +512,94 @@ func (s *BlockchainScripthashService) Listunspent(r *http.Request, req *Scriptha
|
|||
*resp = &result
|
||||
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
|
||||
|
||||
import (
|
||||
"encoding/hex"
|
||||
"encoding/json"
|
||||
"net"
|
||||
"strconv"
|
||||
"sync"
|
||||
"testing"
|
||||
|
||||
"github.com/lbryio/herald.go/db"
|
||||
"github.com/lbryio/herald.go/internal"
|
||||
"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)
|
||||
|
@ -58,14 +64,14 @@ func TestServerGetHeight(t *testing.T) {
|
|||
return
|
||||
}
|
||||
|
||||
s := &BlockchainService{
|
||||
s := &BlockchainBlockService{
|
||||
DB: db,
|
||||
Chain: &chaincfg.RegressionNetParams,
|
||||
}
|
||||
|
||||
req := BlockGetServerHeightReq{}
|
||||
var resp *BlockGetServerHeightResp
|
||||
err = s.Get_server_height(nil, &req, &resp)
|
||||
err = s.Get_server_height(&req, &resp)
|
||||
if err != nil {
|
||||
t.Errorf("handler err: %v", err)
|
||||
}
|
||||
|
@ -88,7 +94,7 @@ func TestGetChunk(t *testing.T) {
|
|||
return
|
||||
}
|
||||
|
||||
s := &BlockchainService{
|
||||
s := &BlockchainBlockService{
|
||||
DB: db,
|
||||
Chain: &chaincfg.RegressionNetParams,
|
||||
}
|
||||
|
@ -96,7 +102,7 @@ func TestGetChunk(t *testing.T) {
|
|||
for index := 0; index < 10; index++ {
|
||||
req := BlockGetChunkReq(index)
|
||||
var resp *BlockGetChunkResp
|
||||
err := s.Get_chunk(nil, &req, &resp)
|
||||
err := s.Get_chunk(&req, &resp)
|
||||
if err != nil {
|
||||
t.Errorf("index: %v handler err: %v", index, err)
|
||||
}
|
||||
|
@ -131,7 +137,7 @@ func TestGetHeader(t *testing.T) {
|
|||
return
|
||||
}
|
||||
|
||||
s := &BlockchainService{
|
||||
s := &BlockchainBlockService{
|
||||
DB: db,
|
||||
Chain: &chaincfg.RegressionNetParams,
|
||||
}
|
||||
|
@ -139,7 +145,7 @@ func TestGetHeader(t *testing.T) {
|
|||
for height := 0; height < 700; height += 100 {
|
||||
req := BlockGetHeaderReq(height)
|
||||
var resp *BlockGetHeaderResp
|
||||
err := s.Get_header(nil, &req, &resp)
|
||||
err := s.Get_header(&req, &resp)
|
||||
if err != nil && height <= 500 {
|
||||
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) {
|
||||
secondaryPath := "asdf"
|
||||
db, toDefer, err := db.GetProdDB(regTestDBPath, secondaryPath)
|
||||
|
@ -161,16 +289,14 @@ func TestGetBalance(t *testing.T) {
|
|||
}
|
||||
|
||||
s := &BlockchainAddressService{
|
||||
BlockchainService{
|
||||
DB: db,
|
||||
Chain: &chaincfg.RegressionNetParams,
|
||||
},
|
||||
}
|
||||
|
||||
for _, addr := range regTestAddrs {
|
||||
req := AddressGetBalanceReq{addr}
|
||||
var resp *AddressGetBalanceResp
|
||||
err := s.Get_balance(nil, &req, &resp)
|
||||
err := s.Get_balance(&req, &resp)
|
||||
if err != nil {
|
||||
t.Errorf("address: %v handler err: %v", addr, err)
|
||||
}
|
||||
|
@ -192,16 +318,14 @@ func TestGetHistory(t *testing.T) {
|
|||
}
|
||||
|
||||
s := &BlockchainAddressService{
|
||||
BlockchainService{
|
||||
DB: db,
|
||||
Chain: &chaincfg.RegressionNetParams,
|
||||
},
|
||||
}
|
||||
|
||||
for _, addr := range regTestAddrs {
|
||||
req := AddressGetHistoryReq{addr}
|
||||
var resp *AddressGetHistoryResp
|
||||
err := s.Get_history(nil, &req, &resp)
|
||||
err := s.Get_history(&req, &resp)
|
||||
if err != nil {
|
||||
t.Errorf("address: %v handler err: %v", addr, err)
|
||||
}
|
||||
|
@ -223,16 +347,14 @@ func TestListUnspent(t *testing.T) {
|
|||
}
|
||||
|
||||
s := &BlockchainAddressService{
|
||||
BlockchainService{
|
||||
DB: db,
|
||||
Chain: &chaincfg.RegressionNetParams,
|
||||
},
|
||||
}
|
||||
|
||||
for _, addr := range regTestAddrs {
|
||||
req := AddressListUnspentReq{addr}
|
||||
var resp *AddressListUnspentResp
|
||||
err := s.Listunspent(nil, &req, &resp)
|
||||
err := s.Listunspent(&req, &resp)
|
||||
if err != nil {
|
||||
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))
|
||||
}
|
||||
}
|
||||
|
||||
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
|
||||
|
||||
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"
|
||||
"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"
|
||||
This looks like an 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"
|
||||
This looks like an 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"
|
||||
This looks like an 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.
|
||||
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.
|
||||
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.
|
||||
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.
|
||||
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 {
|
||||
This looks like an 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
|
||||
This looks like an 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 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.
|
||||
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.
|
||||
}
|
||||
|
||||
type ResolveData 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.
|
||||
Data []string `json:"data"`
|
||||
This looks like an 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 (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.
|
||||
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.
|
||||
}
|
||||
|
||||
type Result 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.
|
||||
Data string `json:"data"`
|
||||
This looks like an 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.
|
||||
// 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.
|
||||
// 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.
|
||||
// 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'.
|
||||
This looks like an 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 {
|
||||
This looks like an 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")
|
||||
This looks like an 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)
|
||||
This looks like an 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.
|
||||
return 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.
|
||||
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.
|
||||
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.
|
||||
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.
|
||||
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.
|
||||
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.
|
||||
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.
|
||||
func (s *Server) StartJsonRPC() error {
|
||||
port := ":" + s.Args.JSONRPCPort
|
||||
This looks like an 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.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.
|
||||
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
|
||||
This looks like an 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.
|
||||
// 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.
|
||||
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.
|
||||
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.
|
||||
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.
|
||||
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("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.
|
||||
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.
|
||||
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.
|
||||
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.
|
||||
}
|
||||
This looks like an 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.
|
||||
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.
|
||||
// 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.
|
||||
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.
|
||||
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.
|
||||
// Register the type of data requested as JSON, with custom codec.
|
||||
s1.RegisterCodec(&BlockchainCodec{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.
|
||||
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.
|
||||
|
||||
// Register "blockchain.claimtrie.*"" handlers.
|
||||
claimtrieSvc := &ClaimtrieService{s.DB}
|
||||
err := s1.RegisterService(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.
|
||||
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.
|
||||
if err != nil {
|
||||
log.Errorf("RegisterService: %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.
|
||||
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.
|
||||
}
|
||||
|
||||
// Register other "blockchain.{block,address,scripthash}.*" handlers.
|
||||
blockchainSvc := &BlockchainService{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.RegisterService(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.
|
||||
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 {
|
||||
log.Errorf("RegisterService: %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.
|
||||
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.
|
||||
}
|
||||
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.
|
||||
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 {
|
||||
log.Errorf("RegisterService: %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.
|
||||
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.
|
||||
}
|
||||
err = s1.RegisterService(&BlockchainScripthashService{*blockchainSvc}, "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.
|
||||
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 {
|
||||
log.Errorf("RegisterService: %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.
|
||||
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.
|
||||
}
|
||||
|
||||
r := 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 := 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)
|
||||
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.
|
||||
|
||||
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.
|
||||
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
|
||||
func (s *Server) RunNotifier() error {
|
||||
for heightHash := range s.NotifierChan {
|
||||
s.DoNotify(heightHash)
|
||||
for notification := range s.NotifierChan {
|
||||
switch notification.(type) {
|
||||
case internal.HeightHash:
|
||||
heightHash, _ := notification.(internal.HeightHash)
|
||||
s.DoNotify(&heightHash)
|
||||
}
|
||||
s.sessionManager.doNotify(notification)
|
||||
}
|
||||
return nil
|
||||
}
|
||||
|
|
|
@ -80,7 +80,7 @@ func TestNotifierServer(t *testing.T) {
|
|||
|
||||
hash, _ := hex.DecodeString("AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA")
|
||||
logrus.Warn("sending hash")
|
||||
hub.NotifierChan <- &internal.HeightHash{Height: 1, BlockHash: hash}
|
||||
hub.NotifierChan <- internal.HeightHash{Height: 1, BlockHash: hash}
|
||||
|
||||
res := <-resCh
|
||||
logrus.Info(string(res))
|
||||
|
|
|
@ -18,7 +18,6 @@ import (
|
|||
|
||||
"github.com/ReneKroon/ttlcache/v2"
|
||||
"github.com/lbryio/herald.go/db"
|
||||
"github.com/lbryio/herald.go/internal"
|
||||
"github.com/lbryio/herald.go/internal/metrics"
|
||||
"github.com/lbryio/herald.go/meta"
|
||||
pb "github.com/lbryio/herald.go/protobuf/go"
|
||||
|
@ -53,7 +52,8 @@ type Server struct {
|
|||
ExternalIP net.IP
|
||||
HeightSubs map[net.Addr]net.Conn
|
||||
HeightSubsMut sync.RWMutex
|
||||
NotifierChan chan *internal.HeightHash
|
||||
NotifierChan chan interface{}
|
||||
sessionManager *sessionManager
|
||||
pb.UnimplementedHubServer
|
||||
}
|
||||
|
||||
|
@ -332,7 +332,8 @@ func MakeHubServer(ctx context.Context, args *Args) *Server {
|
|||
ExternalIP: net.IPv4(127, 0, 0, 1),
|
||||
HeightSubs: make(map[net.Addr]net.Conn),
|
||||
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
|
||||
|
|
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?