If crafting pipes are used, say, more than 1 per network, the request system eats up the entire server thread. It all falls down to OreDictionary.getOreId(), which takes up huge amounts of time.

Here's an image from my profiler that shows the method call trace:

Here's the rest of the trace (whoops):

On a related note, #398 could be of interest

Hmm, doesn't seem to be related to the problem here.

I will see about switching to cached ore IDs.

I wrote something to patch it; but I've been having trouble testing it due to the move to 1.7. If you want you can look at the changes I made in my patch-1 branch.

Hmmmmm, While working on this patch I discovered the true cause of the issue: lostHandleTick() in RoutedCraftingPipePart. It seems to never exit.

I'm so close to a fix on this; but every time I stick it on my server which first gave this report, it keeps happening.

This fix relies on me knowing how this line is supposed to work:

unbalanced = unbalanced.filterNot(c => c.setsRequested > 0 && c.finalizeInteraction())

Is unbalanced supposed to retain (1) things with setsReq > 0 or (2) things with sets == 0 and (1) true for finalize or (2) false.

basically, it is filtering (retaining) all the things "c" that do NOT pass the conditions.
So, after the line, unbalanced should not contain anything that has setsRequested > 0 and has finalized its operation.

Also, what's the purpose of redoing the getMissingCount call before the final check?

Never mind, I see it recalculates from the added promises.

I think there's a different issue that causes this, I'm closing this one in favor of the new one I'm opening.