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.

Bug 142996 - [65cat]java.util.concurrent.TimeoutException at java.util.concurrent.FutureTask$Sync.innerGet
Summary: [65cat]java.util.concurrent.TimeoutException at java.util.concurrent.FutureTa...
Status: RESOLVED FIXED
Alias: None
Product: serverplugins
Classification: Unclassified
Component: GlassFish (show other bugs)
Version: 6.x
Hardware: PC Windows XP
: P2 blocker (vote)
Assignee: Vince Kraemer
URL: http://statistics.netbeans.org/except...
Keywords: RANDOM
: 146390 151428 155285 (view as bug list)
Depends on:
Blocks:
 
Reported: 2008-08-06 05:40 UTC by rajivderas
Modified: 2009-04-17 19:57 UTC (History)
7 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter: 59826


Attachments

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 146390 has been marked as a duplicate of this issue. ***
Comment 7 _ pcw 2008-10-27 19:54:45 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 151428 which unfortunately was filed quite late).

It's not that easy to fix, but is fairly straight forward.  If we can fix this in time for patch 1, I feel it should be
part of that patch release, otherwise, it should be part of patch 2.
Comment 9 pgebauer 2008-11-24 09:29:16 UTC
The issue didn't pass the nomination process by nomination cut-off date. It has been marked as 65fixes2-candidate.
Comment 10 _ pcw 2008-12-12 02:11:48 UTC
*** 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...