java.util.concurrent.TimeoutException at java.util.concurrent.FutureTask$Sync.innerGet

[?]  | New  | Browse  | Search  | Reports  | Help  | Log In First Last Prev Next    This bug is not in your last search results. Bug 142996 -  [65cat]java.util.concurrent.TimeoutException at java.util.concurrent.FutureTask$Sync.innerGet Status: RESOLVED FIXED   Product: serverplugins Component: GlassFish Version: 6.x Hardware: PC Windows XP   Priority: P2 (vote) Target Milestone: 6.x Assigned To: Vince Kraemer QA Contact: issues@serverplugins   URL: http://statistics.netbeans.org/except... Whiteboard:   Keywords: RANDOM   Duplicates: 146390 151428 155285 (view as bug list) Depends on: Blocks:   Show dependency tree / graph   Reported: 2008-08-06 05:40 UTC by rajivderas Modified: 2009-04-17 19:57 UTC (History) CC List: 7 users (show)   See Also:   Issue Type: DEFECT Exception Report :   Attachments Add an attachment (proposed patch, testcase, etc.) Note You need to  log in before you can comment on or make changes to this bug.   Description rajivderas  2008-08-06 05:40:23 UTC java.util.concurrent.TimeoutException at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:228) at java.util.concurrent.FutureTask.get(FutureTask.java:91) at org.netbeans.modules.glassfish.javaee.db.Hk2DatasourceManager.registerResourceDir(Hk2DatasourceManager.java:152) at org.netbeans.modules.glassfish.javaee.db.Hk2DatasourceManager.deployDatasources(Hk2DatasourceManager.java:140) at org.netbeans.modules.j2ee.deployment.impl.ServerInstance.deployDatasources(ServerInstance.java:666) at org.netbeans.modules.j2ee.deployment.devmodules.spi.J2eeModuleProvider.deployDatasources(J2eeModuleProvider.java:251) at org.netbeans.modules.j2ee.deployment.devmodules.api.Deployment.deploy(Deployment.java:148) at org.netbeans.modules.j2ee.ant.Deploy.execute(Deploy.java:104) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288) at sun.reflect.GeneratedMethodAccessor63.invoke(GeneratedMethodAccessor63.java:0) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:105) at org.apache.tools.ant.Task.perform(Task.java:348) at org.apache.tools.ant.Target.execute(Target.java:357) at org.apache.tools.ant.Target.performTasks(Target.java:385) at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1329) at org.apache.tools.ant.Project.executeTarget(Project.java:1298) at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41) at org.apache.tools.ant.Project.executeTargets(Project.java:1181) at org.apache.tools.ant.module.bridge.impl.BridgeImpl.run(BridgeImpl.java:277) at org.apache.tools.ant.module.run.TargetExecutor.run(TargetExecutor.java:460) at org.netbeans.core.execution.RunClassThread.run(RunClassThread.java:151) Comment 1 _ pcw  2008-08-08 06:31:36 UTC Odd. Can you provide any more information about the circumstances in which you received this exception? Comment 2 _ pcw  2008-09-04 02:49:25 UTC To reproduce: Create a web project and add some entity classes from database (so that a sun-resources.xml file is created). Then make sure the server is STOPPED and "Run" the project. When checking to make sure everything is deployed and ready, the server is deploying the sun-resources.xml file when the server is still stopped (or something along those lines) and this exception occurs. Essentially auto deployment of sun-resources.xml is not correctly implemented. Workaround: Start the server. Once it's started, then choose "Run". Comment 3 rajivderas  2008-09-04 05:35:57 UTC pcw, cannot perform your process since am getting issues [1]#14611 when am trying to create a persistence unit in New Entity Class wizard in Dev Build 200809031401. [1] http://www.netbeans.org/issues/show_bug.cgi?id=146111 Comment 4 _ pcw  2008-09-04 05:43:25 UTC Well, Vince has already fixed 14611, but don't worry about reproducing it. I already did. I just wrote up the steps required for posterity. Comment 5 rajivderas  2008-09-04 05:46:26 UTC ok cool Comment 6 _ pcw  2008-09-06 04:19:12 UTC *** Issue 151428 has been marked as a duplicate of this issue. *** Comment 8 _ pcw  2008-10-27 20:00:21 UTC This issue as 50+ duplicates (see Issue 155285 has been marked as a duplicate of this issue. *** Comment 11 pgebauer  2009-01-14 09:47:08 UTC The issue hasn't passed the nomination process for 65patch2 by cut-off date. It has been moved to 65patch3. Comment 12 Marian Mirilovic  2009-02-19 11:19:42 UTC 75 duplicates so far ... Comment 13 Vince Kraemer  2009-02-19 20:21:38 UTC I have just been trying to reproduce this issue with a recent pull of main. I have not been able to reproduce the problem. Has anyone run into this with a recent nightly build? It is possible that one of the changes introduced since 6.5 shipped could have corrected this problem as a side-effect... but I don't know which... so including this as part of patch 3 may not be possible. Comment 14 Vince Kraemer  2009-02-21 17:06:37 UTC folks have not been able to reproduce with recent trunk builds. Closing as worksforme. If someone does reproduce it with the trunk... please reopen and provide details. I don't know which changes resolved this... Comment 15 _ pcw  2009-02-23 21:41:35 UTC This is a 6.5 patch 3 candidate. Whether it's reproducible on the trunk or not is irrelevant as long as it's reproducible in 6.5 patch 2 or earlier. Otherwise what you are saying is that we do not consider this a patch candidate and won't fix it in 6.5 which personally, I disagree with unless the fix is really risky (in this case, it might be but I don't know that we know that). Comment 16 Vince Kraemer  2009-02-25 20:46:10 UTC OK. I reset the 65fixes3-candidate flag... The issue appears to be resolved in the trunk... which is why it was closed as WFM. I do not know which code change resolved this issue (I am assuming that it has been resolved since multiple folks have attempted to reproduce it and failed). I guess you will need to find a build where this issue can be reproduced and then determine the code change that fixes it. After that happens, you will need to verify that the essence of the fix is not already in-place in the release65_fixes clone (and in the trunk). If the essence of the fix is in the release65_fixes clone, you should probably add a note to that effect here. If the essence of the fix is in the trunk, I am not sure what to do... I would guess apply any improvements of your patch over the changes that have resolved the issue in the trunk and then leave a pointer to both sets of changes (the essence and the clean-up)... I will leave that up to you. Note: if this issue appears to be an impediment to a 6.7 milestone, I will close it as WFM again.... but that won't be for a couple week... at least. Comment 17 Marian Mirilovic  2009-03-02 10:51:25 UTC looks like it's still not clear about the fix ... moving to next patch Comment 18 _ pcw  2009-03-16 21:02:17 UTC I was unable to reproduce this in 6.5 patch 2, though the steps mentioned below will work to reproduce this in the original FCS release of 6.5. It looks like the callflow in j2eeserver was altered in a subsequent patch and as a side effect, this issue was resolved. Vince, Nitya, and Rochelle have posted that they cannot reproduced this in 6.7 codeline (probably due to the same effect mentioned above, closing as WORKFORME. Comment 19 pgebauer  2009-04-08 14:00:42 UTC The status whiteboard "65fixes4-candidate" has been removed. At this time our proactive patches for the NetBeans 6.5.x IDE have concluded. If you own a Sun service plan contract for NetBeans, you may wish to contact Sun Service http://www.sun.com/contact/support.jsp to request a fix via the product defect escalation process. For more information on purchasing a Sun service plan contract for NetBeans, refer to the service plan item "Sun Software Service Plans (S3P) for Developers" in the Sun Service table found on our NetBeans Support Resources page http://www.netbeans.org/kb/support.html Comment 20 Vince Kraemer  2009-04-08 17:04:34 UTC I have seen new reports of this from the trunk build and 6.5.1... so it isn't fixed. Comment 21 Vince Kraemer  2009-04-14 23:16:47 UTC Multiple developers have tried to reproduce this and been unsuccessful. Users are still running into this with recent builds. Marking as random. doing more investigation. Comment 22 Vince Kraemer  2009-04-17 17:07:10 UTC http://hg.netbeans.org/web-main/rev/a5f251358ed6 Comment 23 Quality Engineering  2009-04-17 19:57:10 UTC Integrated into 'main-golden', will be available in build *200904171401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/a5f251358ed6 User: Vince Kraemer <vkraemer@netbeans.org> Log: #142996: bogus use of Level.WARNING when the timeout hits...   Format For Printing   - XML   - Clone This Bug   - Top of page First Last Prev Next    This bug is not in your last search results.