Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Failed to process FETCH_INV_DATA message #5439

Closed
xxo1shine opened this issue Aug 22, 2023 · 4 comments · Fixed by #5460
Closed

Failed to process FETCH_INV_DATA message #5439

xxo1shine opened this issue Aug 22, 2023 · 4 comments · Fixed by #5460
Assignees
Labels

Comments

@xxo1shine
Copy link
Contributor

System information

Java-tron version: v4.7.2
OS & Version: Linux & macOS

Expected behavior

The FETCH_INV_DATA message from the peer should be successfully processed.

Actual behavior

When processing the FETCH_INV_DATA message, it was found that the transaction hash requested by the Peer was not in the broadcast list cache of the Peer, so a not spread inv exception was reported.

The log is as follows:

==============
服务器IP: 3.0.79.203 
log-time: 2023-07-05T02:22:30.343Z
-------------------------------------
02:22:29.770 ERROR [nioEventLoopGroup-6-4] [net](P2pEventHandlerImpl.java:253) Message from /170.187.189.31:53284 process failed, type: FETCH_INV_DATA
invType: TRX, size: 3, First hash: 1ec914af1d51a99ddb628a7e154dd0bf603ce8c6c9d81b68c1773b67130f85be, End hash: 5df9ac23f764232779628eb993d7cd515cf3d1ca3b2edd471cee7e3a1aa6bfdf
 type: (4, bad message)
org.tron.core.exception.P2pException: not spread inv: 1ec914af1d51a99ddb628a7e154dd0bf603ce8c6c9d81b68c1773b67130f85be
    at org.tron.core.net.messagehandler.FetchInvDataMsgHandler.check(FetchInvDataMsgHandler.java:136)
    at org.tron.core.net.messagehandler.FetchInvDataMsgHandler.processMessage(FetchInvDataMsgHandler.java:58)
    at org.tron.core.net.P2pEventHandlerImpl.processMessage(P2pEventHandlerImpl.java:193)
    at org.tron.core.net.P2pEventHandlerImpl.onMessage(P2pEventHandlerImpl.java:139)
    at org.tron.p2p.connection.ChannelManager.handMessage(ChannelManager.java:216)
    at org.tron.p2p.connection.ChannelManager.processMessage(ChannelManager.java:173)
    at org.tron.p2p.connection.socket.MessageHandler.decode(MessageHandler.java:49)
    at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:489)
    at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:428)

Is Peer a normal node?

The node interaction process was normal. It took 449s from establishment to disconnection. The log is as follows.

image

Is the transaction normal?

The transaction 1ec914af1d51a99ddb628a7e154dd0bf603ce8c6c9d81b68c1773b67130f85be requested by Peer was a normal transaction, the transaction had been packaged in the block at 10:20:12, and the time requested by Peer was 10:22:29, which was delayed by 2 minutes and 15 seconds.

@jwrct
Copy link
Contributor

jwrct commented Aug 23, 2023

@wubin01 Do you have identified the cause of the problem? If so, could you please explain it in detail?

@xxo1shine
Copy link
Contributor Author

@chengtx01 A broadcast list timeout threshold can be set. If the peer broadcast list exceeds a certain threshold, no more transactions will be obtained from it.

@lvs007
Copy link
Collaborator

lvs007 commented Aug 25, 2023

Do you have a detailed solution? If so, can you add it in the body of the text?

@xxo1shine
Copy link
Contributor Author

@lvs007 If the list broadcast by the peer exceeds 15s, no longer get it.
The original logic is as follows:

private void consumerInvToFetch() {
    ……
        peers.stream().filter(peer -> peer.getAdvInvReceive().getIfPresent(item) != null
                && invSender.getSize(peer) < MAX_TRX_FETCH_PER_PEER)
                .sorted(Comparator.comparingInt(peer -> invSender.getSize(peer)))
                .findFirst().ifPresent(peer -> {
                  if (peer.checkAndPutAdvInvRequest(item, now)) {
                    invSender.add(item, peer);
                  }
                  invToFetch.remove(item);
                });
      });
    }

The logic after repair is as follows:

Long TIMEOUT = MSG_CACHE_DURATION_IN_BLOCKS * BLOCK_PRODUCED_INTERVAL;
private void consumerInvToFetch() {
    ……
        peers.stream().filter(peer -> peer.getAdvInvReceive().getIfPresent(item) != null
                && now - peer.getAdvInvReceive().getIfPresent(item) < TIMEOUT
                && invSender.getSize(peer) < MAX_TRX_FETCH_PER_PEER)
                .sorted(Comparator.comparingInt(peer -> invSender.getSize(peer)))
                .findFirst().ifPresent(peer -> {
                  if (peer.checkAndPutAdvInvRequest(item, now)) {
                    invSender.add(item, peer);
                  }
                  invToFetch.remove(item);
                });
      });
    }

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants
@lvs007 @xxo1shine @jwrct and others