This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Similar to issue #164397.
Added randomly failing LazyNodeTest.testFindChild in cdev #e74619f77207.
Integrated into 'main-golden', will be available in build *200905151401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/e74619f77207 User: Jesse Glick <jglick@netbeans.org> Log: #165223 demonstration that NodeOp.factory -> NodeOp.findPath unreliable.
Created attachment 82305 [details] Log from one failure
Created attachment 82309 [details] Log files from good and bad runs
I go not think there is anything wrong in LazyNode. Rather there is some interaction between GC, FilterNode and ChildFactory. I've added more logging: ergonomics#ae6d1b86bd19 and generated two logs (attached in the ZIP http://www.netbeans.org/nonav/issues/showattachment.cgi/82309/testFindChild.zip). The successful run seems to execute a lot of operations in Mutex mode 1, while the unsuccessful runs in mode 2. Also the "addNotify successfully called for org.openide.nodes.FilterNode$Children" happens at the end of the run in the successful turn, while quite early in the failed one. Anyway I do not think the failure is LazyNode related and I'd like Tomáš to investigate it.
The problem seems to me in the fact that LazyNode switches original node while operation is running on the original (createKeys() is invoked from blocking call of findChild()). FilterNode (LazyNode) assumes findChild() successfully finished on original node (blocking call in case of AsynchChildren), but it did not on new switched original. changeOriginal() causes refresh of filter nodes keys, but only via original.getChildren().getNodes() which does not block and therefore new original (which also has AsynchChildren) may return just wait node. It is possible to check original in FilterNode (after original.getChildren().findChild()) and call findChild() again if original was changed, but it is not very clean fix. I think it would be better to rewrite LazyNode.
Created attachment 82396 [details] possible FilterNode patch
Thanks for finding what is wrong. core-main#e5cbc4b239c3
Works. Clicking a broken build notification now correctly expands Hudson Builders, as well as some appropriate descendants, to select the build node.
Integrated into 'main-golden', will be available in build *200905200201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/e5cbc4b239c3 User: Jaroslav Tulach <jtulach@netbeans.org> Log: #165223: Capture the request to switchToOriginal when FilterNode's children are being expanded, not when the underlaying ones are