[GLASSFISH-21196] Remote Deploy of Maven EAR issues java.util.concurrent.TimeoutException Created: 15/Sep/14  Updated: 30/Sep/14

Status: Open
Project: glassfish
Component/s: admin, concurrency, deployment
Affects Version/s: 4.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: gesker Assignee: Chris Kasso
Resolution: Unresolved Votes: 10
Labels: concurrency, deploy, jdk8, maven, netbeans, timeout
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Workstation: Win 8.1 Pro, jdk8_20, GlassFish_4.1, NetBeans_8.0.1
Server: Ubuntu Server 14.04, jdk8_20, GlassFish_4.1



 Description   

Maven Enterprise Project (of about 27 MB in size) cannot be deployed from NetBeans using DAS port.

This same EAR can successfully be deployed to GlassFish_4.1 on server using the Web – Admin console.

When attempting to deploy to the remote server from NetBeans on workstation the logs on the server record:

Exception while running a command
java.io.IOException: java.util.concurrent.TimeoutException
at org.glassfish.admin.payload.PayloadFilesManager.extractFile(PayloadFilesManager.java:584)
at org.glassfish.admin.payload.PayloadFilesManager.access$600(PayloadFilesManager.java:93)
at org.glassfish.admin.payload.PayloadFilesManager$DataRequestType$1.processPart(PayloadFilesManager.java:749)
at org.glassfish.admin.payload.PayloadFilesManager.processPartsExtended(PayloadFilesManager.java:618)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$UploadedFilesManager.extractFiles(CommandRunnerImpl.java:2074)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$UploadedFilesManager.<init>(CommandRunnerImpl.java:2046)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$UploadedFilesManager.<init>(CommandRunnerImpl.java:2025)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1155)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1300(CommandRunnerImpl.java:109)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1846)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1722)
at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:534)
at com.sun.enterprise.v3.admin.AdminAdapter.onMissingResource(AdminAdapter.java:224)
at org.glassfish.grizzly.http.server.StaticHttpHandlerBase.service(StaticHttpHandlerBase.java:189)
at com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:459)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:167)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:201)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:175)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:235)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:284)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:201)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:133)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.portunif.PUFilter.handleRead(PUFilter.java:231)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:284)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:201)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:133)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.portunif.PUFilter.handleRead(PUFilter.java:231)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:284)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:201)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:133)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:561)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:117)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:56)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:137)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:565)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:545)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.io.IOException: java.util.concurrent.TimeoutException
at org.glassfish.grizzly.nio.transport.TCPNIOTransportFilter.handleRead(TCPNIOTransportFilter.java:90)
at org.glassfish.grizzly.filterchain.TransportFilter.handleRead(TransportFilter.java:173)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:284)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:201)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.read(DefaultFilterChain.java:351)
at org.glassfish.grizzly.filterchain.FilterChainContext.read(FilterChainContext.java:695)
at org.glassfish.grizzly.portunif.BackChannelFilter.handleRead(BackChannelFilter.java:80)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:284)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:201)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.read(DefaultFilterChain.java:351)
at org.glassfish.grizzly.filterchain.FilterChainContext.read(FilterChainContext.java:695)
at org.glassfish.grizzly.portunif.BackChannelFilter.handleRead(BackChannelFilter.java:80)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:284)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:201)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.read(DefaultFilterChain.java:351)
at org.glassfish.grizzly.filterchain.FilterChainContext.read(FilterChainContext.java:695)
at org.glassfish.grizzly.http.io.InputBuffer.blockingRead(InputBuffer.java:1119)
at org.glassfish.grizzly.http.server.io.ServerInputBuffer.blockingRead(ServerInputBuffer.java:95)
at org.glassfish.grizzly.http.io.InputBuffer.fill(InputBuffer.java:1143)
at org.glassfish.grizzly.http.io.InputBuffer.read(InputBuffer.java:353)
at org.glassfish.grizzly.http.server.NIOInputStreamImpl.read(NIOInputStreamImpl.java:83)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:246)
at java.io.BufferedInputStream.read1(BufferedInputStream.java:286)
at java.io.BufferedInputStream.read(BufferedInputStream.java:345)
at java.io.FilterInputStream.read(FilterInputStream.java:133)
at java.io.PushbackInputStream.read(PushbackInputStream.java:186)
at java.util.zip.InflaterInputStream.fill(InflaterInputStream.java:238)
at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:158)
at java.util.zip.ZipInputStream.read(ZipInputStream.java:194)
at java.io.FilterInputStream.read(FilterInputStream.java:107)
at org.glassfish.admin.payload.ZipPayloadImpl$Inbound$ZipEntryInputStream.read(ZipPayloadImpl.java:220)
at org.glassfish.admin.payload.PayloadFilesManager.extractFile(PayloadFilesManager.java:549)
... 46 more
Caused by: java.util.concurrent.TimeoutException
at org.glassfish.grizzly.nio.tmpselectors.TemporarySelectorReader.read(TemporarySelectorReader.java:126)
at org.glassfish.grizzly.nio.tmpselectors.TemporarySelectorReader.read(TemporarySelectorReader.java:75)
at org.glassfish.grizzly.AbstractReader.read(AbstractReader.java:72)
at org.glassfish.grizzly.nio.transport.TCPNIOTransportFilter.handleRead(TCPNIOTransportFilter.java:77)
... 80 more
]]

Some notes:

The ear is approx 27 MB.

Have run asadmin enable-secure-admin on the server. I am able to restart GlassFish_4.1 on the server and see its logs from Netbeans.

Had tried setting environment variable AS_ADMIN_READTIMEOUT="3600000" on the server within the init script but this did not help.

I wanted to rule out a configuration issue with my application as the issue so I did the following:

I creating some small projects in NetBeans_8.0.1:

Created a sample web application (no extras) from NetBeans template and it ran/deployed fine.
Created a sample web application (maven - no extras) from NetBeans template and it ran/deployed fine.
Created a sample EAR application (no extras) from NetBeans template and it ran/deployed fine.
Created a sample EAR application (maven - no extras) from NetBeans template and it ran/deployed fine.

So, added some dependencies to the sample maven EAR just to bulk up its size – again nothing fancy just eclipselink and primefaces stuff. The sample EAR now stood at about 26MB.

Tried to run (remote deploy) the sample again got the same java.io.IOException: java.util.concurrent.TimeoutException indicated above as I did for my actual application.



 Comments   
Comment by bhicks01 [ 17/Sep/14 ]

Another bug for the same issue is 21180: https://java.net/jira/browse/GLASSFISH-21180

Comment by dennis@gesker.com [ 30/Sep/14 ]

Maybe what is going on here has something to to with the interaction between Netbeans_8.0.1/Maven_3.2.3/GlassFish_4.1

I had a little bit of time yesterday so I tried to revisit the remote deploy issue.

I pointed my actual project via NetBeans at my remote Glassfish and again got the java.io.IOException: java.util.concurrent.TimeoutException – OK no change there.

However, I went to the Admin console and deployed – no errors where thrown but after clicking on my application none of the modules were visible. I tired deploying several times this same way and got the same results. EAR deployed but with no modules (as if the WAR and EJB/JAR were not present)

Just for the heck of it I dropped by EAR in the autodeploy directory and the application deployed completely correct. All modules were found and the context root was correct.

So, I took a step back and created a new/empty maven EAR project. Tried a remote deploy via Netbeans and threw no errors. However, in the address bar of the browser rather than the root context it displayed the full name of the WAR file "MyProject-web-1.0-SNAPSHOT" Going into the admin console and clicking on the application to launch that way the options did show the correct context root.

I tried to remote deploy the empty EAR a couple more times via Netbeans. Sometimes it was successful. Sometimes it failed with "java.io.IOException: java.util.concurrent.TimeoutException" and sometimes it failed with "java.io.EOFException"

I tired adding the following to the "maven-ear-plugin" section of my pom.xml of my EAR:

<modules>
<webModule>
<groupId>com.mycompany</groupId>
<artifactId>MyProject-web</artifactId>
<contextRoot>/MyProject-web</contextRoot>
</webModule>
<ejbModule>
<groupId>com.mycompany</groupId>
<artifactId>MyProject-ejb</artifactId>
</ejbModule>
</modules>

But the behavior remained the same. I'm new to Maven. So, the above is just my poking about but maybe it will give someone with a better understanding of the interrelationship of these three tools a hint that is useful.

I really would like to stick with maven as I like how it handles dependencies and keeps my repository clean but if it just gets in the way of seamless remote deploys I can drop back to standard project templates, too.

Any advice or more information I can collect?

Comment by bhicks01 [ 30/Sep/14 ]

I'm not using netbeans or maven for deployment. I am using a custom ant build system to run the asadmin remote deployment, and it is failing. In fact, we had our deploy command defaulted to "--upload=true", which would fail every time for some projects (this was done even for localhost deployment).

We've worked around this by scp'ing the jar/ear/war to the destination host, then running the asadmin command via an "ssh -q <asadmin deploy cmd>".





[GLASSFISH-21128] Incorrect context in ManagedThreadFactory Created: 10/Jul/14  Updated: 10/Jul/14

Status: Open
Project: glassfish
Component/s: concurrency
Affects Version/s: 4.0
Fix Version/s: None

Type: Bug Priority: Major
Reporter: anthony.lai Assignee: anthony.lai
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

At page 3-27 of JSR236 spec, it is specified that the runnable that is executed will run with the context of the application component instance that created the ManagedThreadFactory instance.
But in the implementation of glassfish4, tasks will run with the context of the application component that called the newThread() method.






[GLASSFISH-20960] Batch job won't start when glassfish application versioning is used. Created: 19/Jan/14  Updated: 19/Sep/14

Status: Open
Project: glassfish
Component/s: concurrency
Affects Version/s: 4.0
Fix Version/s: 4.1

Type: Bug Priority: Major
Reporter: jiggster Assignee: anthony.lai
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Ubuntu 12.04, Mac OS X 10.9, Windows 7


Tags: 4_0_1-approved, 4_0_1-evangelists, application-versioning, batch

 Description   

To reproduce the issue take the webserverlog batch application sample from the java ee 7 tutorial, add the glassfish-web.xml file and make sure it contains the version-identifier element with the value, say, 1.0. Build and deploy the applicaiton, go to http://localhost:8080/webserverlog/ (assuming your instance listens on 8080) and start the batch job. The status of the job will change to STARTING, but the job itself won't start executing.

I can upload the source code of the modified version of the webserverlog sample application, but I don't know how to add the attachments.



 Comments   
Comment by jiggster [ 21/Jan/14 ]

Is there any chance that this issue will be evaluated any time soon?

Regards,
Jigg

Comment by Mahesh Kannan [ 16/Apr/14 ]

Mark for 4.0.1

Comment by Mahesh Kannan [ 16/Jul/14 ]

Assigning to Anthony

Comment by Mahesh Kannan [ 16/Jul/14 ]

The root cause is that setupContext in ManagedFuture (incorrectly) finds that the application is NOT enabled. The issue is
in ContextSetupProviderImpl.isApplicationEnabled(). This method probably needs to look into the application version field
before deciding if the app is disabled or not.

For example, after deploying an app with a different version, as you could see from the below output,
only app1:v3 is enabled. So, maybe ContextSetupProviderImpl.isApplicationEnabled() (or some
other utility method) should look into the versioning field of the app to decide correctly, if it is
enabled or not.

asadmin list-applications --long
NAME TYPE STATUS
app1 <ejb, web> disabled
app1:v1 <ejb, web> disabled
app1:v2 <ejb, web> disabled
app1v3 <ejb, web> enabled
Command list-applications executed successfully.

Here is the call stack when a batch job is submitted from a versioned app.

ManagedFutureTask::setupContext
ContextSetupProviderImpl::setup(ContextHandle contextHandleForSetup)
appName = handle.getInvocation().getAppName();
isApplicationEnabled(appName)

Unfortunately, isapplicationEnabled(appName) returns false thus causing
contextSetupException to IllegalStateException.

This causes ManagedfutureTask.run() method to be aborted. Hence the Batch job
is never executed.





[GLASSFISH-20624] man pages missing from concurrent-impl.jar Created: 11/Jun/13  Updated: 09/Jul/13

Status: Open
Project: glassfish
Component/s: concurrency
Affects Version/s: 4.0_b89_RC5
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Mike Fitch Assignee: Hong Zhang
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The man pages for the concurrency CLI commands do not display when you use the --help option. The reason is that they're not in the concurrent-impl.jar file. When concurrent/admin was refactored into concurrent/concurrent-impl, the dependency on the man pages was dropped from the pom.xml file, and so they stopped getting pulled in.



 Comments   
Comment by Hong Zhang [ 09/Jul/13 ]

Mike has a local fix for this, will review the fix and get the fix in.





Generated at Wed Sep 02 02:27:28 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.