Archieve 노드 운영중 아카이브 노드 전용 caverjs 를 쓸대 Invalid JSON RPC response : "" 가 현상

클레이튼 아카이브 노드를 직접 aws서버에서 운영중입니다.

그런데 서비스 로직을 돌면서 caver.rpc.klay.getBlock( 블록번호 , true ) 의 response가
Invalid JSON RPC response : “” 로 에러 익셉션이 떨어집니다.

그렇다고 getBlock(블록번호) 만 할경우 transaction의 오브젝트를 제외한 txid리스트는 잘나오는데요

잘돌다가 특정블록오면 꼭 저지랄 하더라고요 확인좀 부탁드립니다

kend를 항상 최신화 구성을 해야하나요?

1개의 좋아요

흠 현재 kend (geth ) 에 붙어서 직접 getBlock(블록번호, true)를 해보니까 데이터는 있네요

transaction object가 잘나오네요 이러면 response를 제시간에 못받아서 timeout exception 이 났다고 봐야하나요?

1개의 좋아요

안녕하세요
혹시 노드 버전, caver 버전을 어떻게 구성하여 테스트하셨는지 확인할 수 있을까요?
해당 문제가 발생한 블록넘버도 알려주시면 분석이 용이할 것 같습니다

2개의 좋아요

caverjs - 1.8.1
node - 16.13.1
ken - 1.8.2+7584e71de6

const caver = new Caver(" domain ");

while ( true ) {
try{
let blockInfo = await caver.rpc.klay.getBlolck( 93646409 , true )
}
catch(e){
}
}
@Jay
구조로 로직이 설정되어있습니다. ( 입금을 확인 하기 위해서 매블록을 모두 조회하고있습니다 )

문제는 해당 블록과 같이 특정 한개의 블록데이터가 제대로 response를 못주는 경우가 있습니다.

문제점 : 스케줄러가아닌 무한반복문으로 돌아가기에 req요청이 자체적으로 구축한 en노드에 req요청이 많아서 그런걸까 싶었는데 ken attach 로 같은 메소드 조회해보니 transaction object 데이터가 존재합니다. 그래서 따로 해당블록만 단건 조회를 해봤는데도 같은 에러를 뱉어버리네요

라이브러리 버전의 문제일까요?

1개의 좋아요

안녕하세요

혹시 문제가 되는 블록이 93646409 번호 하나일까요?
그리고 네트워크는 어디인가요?

단건으로도 에러를 뱉는다고 하셔서 테스트를 해 보았는데, 문제없이 응답을 받고 있는 것을 확인했습니다.
아래 테스트에 사용된 코드 첨부하겠습니다 참고 부탁드립니다.
타임아웃 옵션 설정 없이 디폴트 설정으로 요청을 날려도 정상적인 응답을 받아오는 것을 확인했습니다.

라이브러리의 경우 1.8.1과 최신 코드에 caver.rpc.klay.getBlock 관련 변경사항은 없어서 문제되지 않을 것이라 예상되는데요, 혹시나 최신 버전으로 업데이트 하고 재현되는지 확인 부탁드립니다.

getBlock()
async function getBlock() {
    const baobab = new Caver('http://x.x.x.x:8551')
    const cypress = new Caver('http://x.x.x.x:8551')
    // const baobab = new Caver(new Caver.providers.HttpProvider('http://x.x.x.x:8551', { timeout: 100000 }))
    // const cypress = new Caver(new Caver.providers.HttpProvider('http://x.x.x.x:8551', { timeout: 100000 }))

    const blockNumber = 93646409

    const baobabBlockResult = await baobab.rpc.klay.getBlock(blockNumber, true)
    const cypressBlockResult = await cypress.rpc.klay.getBlock(blockNumber, true)
    console.log(`Baobab block result: ${JSON.stringify(baobabBlockResult)}`)
    console.log(`Cypress block result: ${JSON.stringify(cypressBlockResult)}`)
}
4개의 좋아요

메인넷(cypress) 네트워크 인데요, 퍼블릭에서는 데이터가 잘 옵니다. 소스 로직상에 문제라기 보기는 어려운듯 싶습니다. ken 버전이 낮아서 그런걸까요? 오랫동안 유지해온 블록데이터와 ken 버전을 계속 갱신해왔던걸로 아는데, 아얘 최신버전으로 셋팅하는게 좋을까요?

추가적으로 해당 블록번호만 건너띄고 로직을 돌리니 잘돌아갑니다. 의문점이 생기는게 현재 제가 ken console 로 attach해서 klay.getBlock(93646409 , true) 를 같이 조회 해본결과론 적인 느낌으로 해당블록데이터 길이가 생각보다 데이터 길이가 많은 것 같습니다. return 뱉는속도가 상대적으로 느리네요.

이런 경우 인스턴스 스펙의 단순문제 때문일까요? aws 스펙상 권장사양( 2xlarge ) 은 지키고있습니다.

1개의 좋아요

@Victor

  • 퍼블릭에서는 데이터가 잘 온다는 건 어떤 퍼블릭을 말씀하시는 걸까요? 정확한 엔드포인트 url 을 알려주시면 좋을 거 같습니다.
  • ken 버전 최신으로 올려주시면 좋을 거 같습니다.
  • 느낌으로 해당 블록데이터가 길다고 해주시는 것보다는 실제 데이터를 비교하시고 팩트를 공유해주시면 좋을 거 같아요.
  • AWS 에서는 다양한 2xlarge 스펙이 존재해요. r6g.2xlarge, r6gd.2xlarge 등 다양하게 존재하는데 정확히 어떤 스펙을 사용하고 계시다는 말씀이신가요?
1개의 좋아요
  • 퍼블릭에서는 데이터가 잘 온다는 건 어떤 퍼블릭을 말씀하시는 걸까요? 정확한 엔드포인트 url 을 알려주시면 좋을 거 같습니다.
    https://public-node-api.klaytnapi.com/v1/cypress

  • ken 버전 최신으로 올려주시면 좋을 거 같습니다.
    → 신규로 4xlarge 스펙으로 snapshot 데이터 다운중입니다. 동기화 후 비교해보겠습니다

  • 느낌으로 해당 블록데이터가 길다고 해주시는 것보다는 실제 데이터를 비교하시고 팩트를 공유해주시면 좋을 거 같아요.
    → 93646409 , 팩트 체크해드리자면 말씀드린 블록의 트렌젝션수는 361개 입니다. 빠르게 생성되는 클레이튼 블록대비 많은 수의 tx가 한블록에 컨펌되어있고 조회하면 아시다 싶이 바이트 크기가 93646409 블록에서는 215,718 bytes 를 차지하고있습니다. 평균 1블록에 10~30개 tx를 들고 있으며 3~4만 bytes를 사용하는 블록데이터 대비 상대적으로 조금 많은 양이긴 합니다.
    klaytnfinder 가서 비교해보시면 더 확실하게 보이실 겁니다.

  • AWS 에서는 다양한 2xlarge 스펙이 존재해요. r6g.2xlarge, r6gd.2xlarge 등 다양하게 존재하는데 정확히 어떤 스펙을 사용하고 계시다는 말씀이신가요?
    → 메모리 최적화 r5.2xlarge 쓰고있습니다. 아카이브 노드를 운영하면 cpu 보다 메모리가 부족할때가 간간히 있더군요. 그래서 메모리최적화 위주의 인스턴스를 사용중에 있습니다.

@Denver , 거래소 입장에서 입출금 로직을 생각해보신다면, 반복적으로 블록을 조회할 수 밖에없는 것은 아실겁니다. 근데 제가 경험한 내용은 가끔(?) 이번 경우와 같이 한 블록에 많은 트렌젝션이 담긴경우 getBlock( “블록번호”, true) 의 return 값을 못뱉어낼때가 있습니다. 이게 몇 개의 특정 블록(tx가 많은) 일때마다 이러니까 제입장에서 처리를 어떻게 해야 최선일지 찾고 있습니다. exception 에 걸려서 따로 처리를 해야해서요 ^^

1개의 좋아요

안녕하세요 근데 해당코드 동작하나요? 혹시 종종 에러가 발생하시는 코드 전체를 올려주시면 좋을거같아요

1개의 좋아요

@Victor

Exception 으로 처리하시는 게 최선이지 않을까 싶습니다.

제가 해당 로직을 구현 한다면,

  • 블록들을 파싱해서 따로 디비화 (기획에 따라 다르겠지만 기본적으로 입금 여부를 확인한다고 하셨으니 KLAY의 흐름을 파악하기 용이한 구조로 스키마를 짜야겠죠)
  • 어떤 블록까지 파싱을 완료했는지 디비에 기록
  • 디비에 기록된 블록번호에서 +1 한 번호에 해당하는 블록부터 실행 당시 노드의 최신 블록번호까지 노드로부터 수신해서 파싱해서 디비화하는 스크립트를 만들고 해당 스크립트를 Cron job 으로 실행.

와 같이 구현할 거 같습니다.

P.S
@Victor 님이 첨부해주신 while loop은 하나의 프로세스로 계속 루프를 돌며 블록을 받아와서 파싱하는 구조인 거 같은데, 이렇게 단일 프로세스로 계속 그 작업을 하게 돌리는 게 효율적인지는 모르겠어요.
에러 처리도 번거로울 거 같구요. 디비에 어떤 블록까지 처리했는지를 기록해두고 그 기록 바탕으로 동작하는 스크립트를 만들고 Cronjob 으로 스케쥴링하는 게 더 낫지 않나 싶습니다.

1개의 좋아요

@Denver , @Jamie

신규 4xlarge 인스턴스를 생성한뒤 최신버전의 ken 을 동기화하여 돌려보니 잘되네요. Invaild JSON RPC ""의 문제는 아마 낮은 버전의 ken 버전에 따른 블록데이터가 caverjs 와 안맞아서 블록 데이터 길이가 길 경우 간혹 return 을 잘못던져주는구나 싶습니다. 노드 최신화 관리에 신경써야겠네요. 프라이빗 구성만아니면 현재 이슈있는 상태의 노드를 공유해드리고 싶은데 아쉽게도 불가능하네요. 많이 신경써주셔서 감사합니다.

4개의 좋아요

여기서 저는 해결했는데요,
truffle config 에서 타임아웃 값 변경해주니까 됐습니다.

gas: '10000000',
        gasPrice: null,
        networkCheckTimeout: 1000000,
        timeoutBlocks: 200
    },
1개의 좋아요

여기서 저는 해결했는데요,
truffle config 에서 타임아웃 값 변경해주니까 됐습니다.

gas: '10000000',
        gasPrice: null,
        networkCheckTimeout: 1000000,
        timeoutBlocks: 200
    },