It's an odd way to deal with `ConcurrentModificationException` but the code that is throwing it is out of our hands so we can't really fix it at its source very well. As i look at this one this morning, I wonder IF this does happen to somehow create some form of infinite loop it's going to be really hard to debug why jobs are just hanging - no one is going to think of the logger.
Should we not timelimit the loop or something? The concurrent modification should not be going on for hours on end i would think so it could be really short? Maybe set a limit that slowly introduces a `Thread.sleep()` in the catch that incrementally increases and ultimately just gives up and returns the `toString()` as something like "yeah...this isn't happening". then at least the loop would break in the worst possible case that we're not thinking of (or in control of) right now. If that's too much for such an off chance thing happening maybe we should log some portion of the retries (every 100th try or something?) in the `catch` so that at least the logs would have some notice of them happening and we'd know why a job was hanging? thoughts? [ Full content available at: https://github.com/apache/tinkerpop/pull/1044 ] This message was relayed via gitbox.apache.org for [email protected]
