There are many threads receiving responses from the teacher, but all of them in the end call the method above. Since the method is synchronized, all threads get stuck waiting to acquire the monitor.
The primary reason this method is synchronized is because it iterates over unsynchronized collections like responses or anticipatedPaths. This is needed to re-order teacher responses, so they are processed in the same order as they were originally sent by the learner. The order is not critical for internal nodes, but when it comes to leaves, they must be processed in ascending path order, this is the current restriction of virtual hasher.
A solution could be to change the method above to be not synchronized, and move leaf path ordering code to dirty leaf iterator. This is the iterator that supplies leaves to virtual hasher.
This is a part of https://github.com/hashgraph/hedera-services/issues/12108 and a follow-up for https://github.com/hashgraph/hedera-services/issues/13898.
After #13898 is implemented, the next bottleneck is on the learner side, this method in
LearnerPullVirtualTreeView:There are many threads receiving responses from the teacher, but all of them in the end call the method above. Since the method is synchronized, all threads get stuck waiting to acquire the monitor.
The primary reason this method is synchronized is because it iterates over unsynchronized collections like
responsesoranticipatedPaths. This is needed to re-order teacher responses, so they are processed in the same order as they were originally sent by the learner. The order is not critical for internal nodes, but when it comes to leaves, they must be processed in ascending path order, this is the current restriction of virtual hasher.A solution could be to change the method above to be not synchronized, and move leaf path ordering code to dirty leaf iterator. This is the iterator that supplies leaves to virtual hasher.