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

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)

Odd.  Can you provide any more information about the circumstances in which you received this exception?

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".

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

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.

ok cool

*** Issue 151428 has been marked as a duplicate of this issue. ***

This issue as 50+ duplicates (see Issue 155285 has been marked as a duplicate of this issue. ***

The issue hasn't passed the nomination process for 65patch2 by cut-off date. It has been moved to 65patch3.

75 duplicates so far ...

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.

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...

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).

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.

looks like it's still not clear about the fix ... moving to next patch

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.

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

I have seen new reports of this from the trunk build and 6.5.1... so it isn't fixed.

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.

http://hg.netbeans.org/web-main/rev/a5f251358ed6

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...