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

Memory usage limited for outgoing eth responses #1057

Merged
merged 7 commits into from
Apr 25, 2018

Conversation

zilm13
Copy link
Collaborator

@zilm13 zilm13 commented Apr 22, 2018

@mkalinin please, take a look

@coveralls
Copy link

coveralls commented Apr 22, 2018

Coverage Status

Coverage increased (+0.1%) to 56.296% when pulling a3535b0 on fix/limit-outgoing-msg into f761be5 on develop.

@zilm13
Copy link
Collaborator Author

zilm13 commented Apr 24, 2018

@mkalinin ready for review and merge

@zilm13
Copy link
Collaborator Author

zilm13 commented Apr 24, 2018

a3535b0#diff-c66ab184b22490e4ae62cc3f62b9b234R44 is a bit non-effective with memory, but we could enhance it later. Usually I see not a big number of pending txs on Mainnet, so slicing is not really used.

@@ -423,4 +425,23 @@ public boolean equals(Object o) {
public int hashCode() {
return Arrays.hashCode(getHash());
}

public static final MemSizeEstimator<BlockHeader> MemEstimator = bh ->
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems unused. Let's remove it


Iterator<byte[]> bodiesIterator = blockchain.getIteratorOfBodiesByHashes(msg.getBlockHashes());
List<byte[]> bodies = new ArrayList<>();
int sizeSum = 80; // ArrayList skeleton
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i) it's a magic number ii) does 80 bytes matter much with regard to 32Kb limit?

msg.getBlockIdentifier(),
msg.getSkipBlocks(),
min(msg.getMaxHeaders(), MAX_HASHES_TO_SEND),
msg.isReverse()
);

BlockHeadersMessage response = new BlockHeadersMessage(headers);
BlockHeadersMessage response = new BlockHeadersMessage(headersIterator);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we need to change BlockHeadersMessage?


/**
* Sames as {@link #sendTransactions(List)} but input list is randomly sliced to
* contain not more than {@link MAX_SAFE_TXS} if needed
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

{@link MAX_SAFE_TXS} -> {@link #MAX_SAFE_TXS}

* contain not more than {@link MAX_SAFE_TXS} if needed
* @param txs List of txs to send
*/
public void sendTransactionsSafely(List<Transaction> txs) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Safely sounds too abstract for me and confusing on the other hand (is regular sendTransactions unsafe??)


return rlpEncoded;
}

public synchronized void purgeEncoded() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it's not used anywhere except tests. I'd remove it therefore

@zilm13
Copy link
Collaborator Author

zilm13 commented Apr 25, 2018

@mkalinin done!

for (byte[] blockHash : msg.getBlockHashes()) {
Block block = blockchain.getBlockByHash(blockHash);
if (block == null) continue;

List<TransactionReceipt> blockReceipts = new ArrayList<>();
sizeSum += 0;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

😀

@mkalinin mkalinin merged commit 78e9bfe into develop Apr 25, 2018
@zilm13 zilm13 deleted the fix/limit-outgoing-msg branch June 4, 2018 15:54
Copy link
Contributor

@ESchouten ESchouten left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Race condition mainly encountered with the StandaloneBlockchain

@mkalinin @zilm13

byte[] plainMsg = this.getEncoded();
return HashUtil.sha3(plainMsg);
getEncoded();
return hash;
Copy link
Contributor

@ESchouten ESchouten Mar 26, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change causes an empty array to be returned when (hash == null && parsed == true && rlpEncoded != null). Happens all the time with the StandaloneBlockchain.

derekzuk pushed a commit to derekzuk/ethereumj that referenced this pull request Apr 3, 2019
derekzuk pushed a commit to derekzuk/ethereumj that referenced this pull request Apr 3, 2019
…true && rlpEncoded != null). See pull request ethereum#1057"

This reverts commit 6bce3d0.
derekzuk pushed a commit to derekzuk/ethereumj that referenced this pull request Apr 3, 2019
derekzuk pushed a commit to derekzuk/ethereumj that referenced this pull request Apr 3, 2019
…true && rlpEncoded != null). See pull request ethereum#1057"

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

Successfully merging this pull request may close these issues.

4 participants