glassfish
  1. glassfish
  2. GLASSFISH-18381

JPA OSGi WAB redployment hangs Glassfish and unable to shutdown

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Critical Critical
    • Resolution: Cannot Reproduce
    • Affects Version/s: 4.0_b82_EE7MS7
    • Fix Version/s: 4.0_b82_EE7MS7
    • Component/s: OSGi-JavaEE
    • Labels:
      None
    • Environment:

      Windows 7 64-bit

      java version "1.6.0_29"
      Java(TM) SE Runtime Environment (build 1.6.0_29-b11)
      Oracle JRockit(R) (build R28.2.0-79-146777-1.6.0_29-20111005-1808-windows-x86_64, compiled mode)

      Description

      Re-deploying a JPA enabled WAB bundle causes Glassfish to hang. I noticed this interesting message in the logs:

      [#|2012-02-20T09:37:21.989-0600|INFO|glassfish3.1.2|org.glassfish.osgijpa|_ThreadID=17;_ThreadName=Thread-4;|Deferring refresh to framework restart, so enhanced bytes won't come into effect until then for bundle 292 if there are existing wires to this bundle.|#]

      This is completely reproducible every time:
      1) Start glassfish
      2) Deploy WAB (works fine)
      3) Edit source file (e.g. add println/logging)
      4) Re-deploy
      5) Hangs with logging similar to the below
      6) Unable to stop glassfish outside of killing Java process

      From what I can tell it looks like it is stuck on the following thread:

      Stack Trace
      admin-thread-pool-4848(1) [131] (WAITING)
      java.lang.Object.wait line: 485
      org.apache.felix.framework.Felix.acquireGlobalLock line: 4943
      org.apache.felix.framework.StatefulResolver.resolve line: 219
      org.apache.felix.framework.BundleWiringImpl.searchDynamicImports line: 1539
      org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation line: 1439
      org.apache.felix.framework.BundleWiringImpl.access$400 line: 72
      org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass line: 1843
      java.lang.ClassLoader.loadClass line: 247
      com.sun.enterprise.container.common.GenericAdminAuthenticator.loginAsAdmin line: 0
      com.sun.enterprise.v3.admin.AdminAdapter.authenticate line: 268
      com.sun.enterprise.v3.admin.AdminAdapter.authenticate line: 310
      com.sun.enterprise.v3.admin.AdminAdapter.service line: 210
      com.sun.grizzly.tcp.http11.GrizzlyAdapter.service line: 179
      com.sun.enterprise.v3.server.HK2Dispatcher.dispath line: 117
      com.sun.enterprise.v3.services.impl.ContainerMapper$Hk2DispatcherCallable.call line: 354
      com.sun.enterprise.v3.services.impl.ContainerMapper.service line: 195
      com.sun.grizzly.http.ProcessorTask.invokeAdapter line: 849
      com.sun.grizzly.http.ProcessorTask.doProcess line: 746
      com.sun.grizzly.http.ProcessorTask.process line: 1045
      com.sun.grizzly.http.DefaultProtocolFilter.execute line: 228
      com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter line: 137
      com.sun.grizzly.DefaultProtocolChain.execute line: 104
      com.sun.grizzly.DefaultProtocolChain.execute line: 90
      com.sun.grizzly.http.HttpProtocolChain.execute line: 79
      com.sun.grizzly.ProtocolChainContextTask.doCall line: 54
      com.sun.grizzly.SelectionKeyContextTask.call line: 59
      com.sun.grizzly.ContextTask.run line: 71
      com.sun.grizzly.util.AbstractThreadPool$Worker.doWork line: 532
      com.sun.grizzly.util.AbstractThreadPool$Worker.run line: 513
      java.lang.Thread.run line: 662

      [#|2012-02-20T09:37:16.167-0600|INFO|glassfish3.1.2|org.glassfish.osgiejb|_ThreadID=17;_ThreadName=Thread-4;|removedService: Found 1 no. of EJBs|#]

      [#|2012-02-20T09:37:18.462-0600|INFO|glassfish3.1.2|org.glassfish.osgijavaeebase|_ThreadID=17;_ThreadName=Thread-4;|Deleted C:\Users\KIRK~1.RAS\AppData\Local\Temp\osgiapp3320546087592904764|#]

      [#|2012-02-20T09:37:18.464-0600|INFO|glassfish3.1.2|org.glassfish.osgijavaeebase|_ThreadID=17;_ThreadName=Thread-4;|Undeployed bundle com.textura.cpms.web [292]|#]

      [#|2012-02-20T09:37:21.233-0600|INFO|glassfish3.1.2|org.glassfish.osgijpa|_ThreadID=17;_ThreadName=Thread-4;|Bundle having id 292 is a JPA bundle|#]

      [#|2012-02-20T09:37:21.350-0600|INFO|glassfish3.1.2|org.glassfish.osgijpa|_ThreadID=17;_ThreadName=Thread-4;|Exploded bundle com.textura.cpms.web [292] at C:\Users\KIRK~1.RAS\AppData\Local\Temp\osgiapp5360629438350331033 |#]

      [#|2012-02-20T09:37:21.551-0600|INFO|glassfish3.1.2|org.glassfish.osgijpa|_ThreadID=17;_ThreadName=Thread-4;|Source = C:\Users\KIRK~1.RAS\AppData\Local\Temp\osgiapp5360629438350331033\WEB-INF\classes, Target = C:\Users\KIRK~1.RAS\AppData\Local\Temp\enhanced-osgiapp8372524464557779997\WEB-INF\classes|#]

      [#|2012-02-20T09:37:21.912-0600|WARNING|glassfish3.1.2|org.glassfish.osgijpa|_ThreadID=17;_ThreadName=Thread-4;|Unable to delete C:\Users\KIRK~1.RAS\AppData\Local\Temp\osgiapp5360629438350331033|#]

      [#|2012-02-20T09:37:21.977-0600|INFO|glassfish3.1.2|org.glassfish.osgijpa|_ThreadID=25;_ThreadName=Thread-4;|Deleted C:\Users\KIRK~1.RAS\AppData\Local\Temp\enhanced-osgiapp8372524464557779997 |#]

      [#|2012-02-20T09:37:21.989-0600|INFO|glassfish3.1.2|org.glassfish.osgijpa|_ThreadID=17;_ThreadName=Thread-4;|Deferring refresh to framework restart, so enhanced bytes won't come into effect until then for bundle 292 if there are existing wires to this bundle.|#]

      [#|2012-02-20T09:37:21.989-0600|INFO|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=17;_ThreadName=Thread-4;|Updated C:\dev\java\tools\glassfish-3.1.2-b23\glassfish3\glassfish\domains\domain1\autodeploy\bundles\cpms-web.war|#]

      [#|2012-02-20T09:37:21.993-0600|INFO|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=17;_ThreadName=Thread-4;|Started bundle: file:/C:/dev/java/tools/glassfish-3.1.2-b23/glassfish3/glassfish/domains/domain1/autodeploy/bundles/cpms-web.war|#]

      [#|2012-02-20T09:37:40.346-0600|INFO|glassfish3.1.2|org.glassfish.osgijavaeebase|_ThreadID=19;_ThreadName=Thread-4;|Expanded at file:/C:/Users/KIRK~1.RAS/AppData/Local/Temp/osgiapp1648809821027798109/|#]

      Nothing happens for a long time until...

      [#|2012-02-20T10:43:40.474-0600|WARNING|glassfish3.1.2|com.sun.grizzly.config.GrizzlyServiceListener|_ThreadID=15;_ThreadName=Thread-4;|GRIZZLY0023: Interrupting idle Thread: http-thread-pool-8080(2).|#]

      [#|2012-02-20T10:43:41.477-0600|WARNING|glassfish3.1.2|com.sun.grizzly.config.GrizzlyServiceListener|_ThreadID=15;_ThreadName=Thread-4;|GRIZZLY0023: Interrupting idle Thread: http-thread-pool-8080(4).|#]

      [#|2012-02-20T10:43:43.479-0600|WARNING|glassfish3.1.2|com.sun.grizzly.config.GrizzlyServiceListener|_ThreadID=15;_ThreadName=Thread-4;|GRIZZLY0023: Interrupting idle Thread: http-thread-pool-8080(1).|#]

      [#|2012-02-20T10:44:32.144-0600|WARNING|glassfish3.1.2|com.sun.grizzly.config.GrizzlyServiceListener|_ThreadID=14;_ThreadName=Thread-4;|GRIZZLY0023: Interrupting idle Thread: admin-thread-pool-4848(1).|#]

      [#|2012-02-20T10:44:33.144-0600|WARNING|glassfish3.1.2|com.sun.grizzly.config.GrizzlyServiceListener|_ThreadID=14;_ThreadName=Thread-4;|GRIZZLY0023: Interrupting idle Thread: admin-thread-pool-4848(1).|#]

      [#|2012-02-20T10:44:34.144-0600|WARNING|glassfish3.1.2|com.sun.grizzly.config.GrizzlyServiceListener|_ThreadID=14;_ThreadName=Thread-4;|GRIZZLY0023: Interrupting idle Thread: admin-thread-pool-4848(1).|#]

      [#|2012-02-20T10:44:35.144-0600|WARNING|glassfish3.1.2|com.sun.grizzly.config.GrizzlyServiceListener|_ThreadID=14;_ThreadName=Thread-4;|GRIZZLY0023: Interrupting idle Thread: admin-thread-pool-4848(1).|#]

      [#|2012-02-20T10:44:35.587-0600|SEVERE|glassfish3.1.2|com.sun.grizzly.config.GrizzlyServiceListener|_ThreadID=26;_ThreadName=Thread-4;|service exception
      java.lang.RuntimeException: ClientAbortException: java.io.IOException: Connection aborted by peer
      at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:246)
      at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:179)
      at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:117)
      at com.sun.enterprise.v3.services.impl.ContainerMapper$Hk2DispatcherCallable.call(ContainerMapper.java:355)
      at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:195)
      at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:849)
      at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:747)
      at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1046)
      at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:228)
      at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
      at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:105)
      at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:91)
      at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
      at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:56)
      at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
      at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
      at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
      at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
      at java.lang.Thread.run(Thread.java:662)
      Caused by: ClientAbortException: java.io.IOException: Connection aborted by peer
      at com.sun.grizzly.tcp.http11.GrizzlyOutputBuffer.doFlush(GrizzlyOutputBuffer.java:439)
      at com.sun.grizzly.tcp.http11.GrizzlyOutputBuffer.flush(GrizzlyOutputBuffer.java:405)
      at com.sun.grizzly.tcp.http11.GrizzlyOutputStream.flush(GrizzlyOutputStream.java:140)
      at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:243)
      ... 18 more
      Caused by: java.io.IOException: Connection aborted by peer
      at sun.nio.ch.SocketDispatcher.write1(Native Method)
      at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:58)
      at sun.nio.ch.IOUtil.write(IOUtil.java:199)
      at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:334)
      at com.sun.grizzly.util.OutputWriter.flushChannel(OutputWriter.java:108)
      at com.sun.grizzly.util.OutputWriter.flushChannel(OutputWriter.java:76)
      at com.sun.grizzly.http.SocketChannelOutputBuffer.flushChannel(SocketChannelOutputBuffer.java:417)
      at com.sun.grizzly.http.SocketChannelOutputBuffer.flushBuffer(SocketChannelOutputBuffer.java:489)
      at com.sun.grizzly.http.SocketChannelOutputBuffer.flush(SocketChannelOutputBuffer.java:467)
      at com.sun.grizzly.http.ProcessorTask.action(ProcessorTask.java:1276)
      at com.sun.grizzly.tcp.Response.action(Response.java:268)
      at com.sun.grizzly.tcp.http11.GrizzlyOutputBuffer.doFlush(GrizzlyOutputBuffer.java:434)
      at com.sun.grizzly.tcp.http11.GrizzlyOutputBuffer.flush(GrizzlyOutputBuffer.java:405)
      at com.sun.grizzly.tcp.http11.GrizzlyOutputStream.flush(GrizzlyOutputStream.java:140)
      at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:243)
      at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:179)
      at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:117)
      at com.sun.enterprise.v3.services.impl.ContainerMapper$Hk2DispatcherCallable.call(ContainerMapper.java:354)
      at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:195)
      at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:849)
      at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:746)
      at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1045)
      at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:228)
      at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
      at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
      at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
      at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
      at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
      ... 5 more

      I have attached the source along with the bundles.

      1) Host bundle for application (uses Vaadin 6.7.5)
      2) Static resources as Bundle Fragment

        Activity

        Hide
        TangYong added a comment -

        For the issue, I have confirmed it in depth today using v4 SNAPSHOT as following:

        1. About re-producing steps in description

        Firstly, re-producing steps in description are not very enough. And by investigations many times, right steps are as following:

        [Precondition]: the means of "re-deploy" should be directly putting bundles related the issue into "glassfish4\glassfish\domains\domain1\autodeploy\bundles" . (Here, I assumed that the user used domain1 only not clustering scene or used multi-domains scene)

        [Steps]
        1) asadmin start-domain domain1
        2) asadmin start-database
        3) putting the following bundles into autodeploy\bundles

        • slf4j-jcl-1.6.4.jar
        • slf4j-api-1.6.4.jar
        • com.springsource.org.apache.commons.logging-1.1.1.jar
        • groovy-all-1.8.6.jar
        • vaadin-6.7.5.jar
        • cpms-web-static.jar[1]
        • cpms-web.war
          [1]: you can also firstly put cpms-web.war, then put cpms-web-static.jar, and executing "asadmin osgi update <WAB's bundle id>". I adopted this way.

        Noting: please do not put jcl-over-slf4j-1.6.4.jar into autodeploy\bundles, because this will produce a conflict with slf4j-jcl-1.6.4.jar and cause a StackOverflowError while you accessed the vaadin application client.

        BTW: In reality, these dependent bundles needed not to be deployed as OSGi bundle alone, and right doing is to make them as inner class path or embed them into the war's inner class path.

        In addition, the demo itself is very interesting and uses fragment(cpms-web-static.jar) skill to attach vaadin's themes including widgetsets into host bundle(cpms-web.war) in order to reach dynamic themes switching(I guess) in the future.

        4) accessing "http://localhost:8080/app/address-book/" and should be fine

        5) modifying cpms-web.war's source(eg. I changed the war's servlet mapping name from address-book into address-book1), then, executing "mvn clean install"

        6) replacing the cpms-web.war in autodeploy\bundles with new built cpms-web.war based 5)

        2 About the "Hangs with logging similar to the below"
        After executing 6), I have not seen any "Hangs with logging similar to the below", however, in server.log, there are the following exceptions:

        [2013-03-25T16:35:23.156+0900] [glassfish 4.0] [WARNING] [] [org.glassfish.osgijavaeebase] [tid: _ThreadID=96 _ThreadName=pool-19-thread-1] [timeMillis: 1364196923156] [levelValue: 900] [[
        Failed to deploy bundle com.textura.cpms.web [301]
        org.glassfish.osgijavaeebase.DeploymentException: Deployment of com.textura.cpms.web [301] failed because of following reason: Failed while deploying bundle com.textura.cpms.web [301] : java.nio.channels.ClosedByInterruptException
        at org.glassfish.osgijavaeebase.AbstractOSGiDeployer.deploy(AbstractOSGiDeployer.java:127)
        at org.glassfish.osgijavaeebase.OSGiContainer.deploy(OSGiContainer.java:154)
        at org.glassfish.osgijavaeebase.JavaEEExtender.deploy(JavaEEExtender.java:109)
        at org.glassfish.osgijavaeebase.JavaEEExtender.access$200(JavaEEExtender.java:61)
        at org.glassfish.osgijavaeebase.JavaEEExtender$HybridBundleTrackerCustomizer$1.call(JavaEEExtender.java:153)
        at org.glassfish.osgijavaeebase.JavaEEExtender$HybridBundleTrackerCustomizer$1.call(JavaEEExtender.java:150)
        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
        at java.util.concurrent.FutureTask.run(FutureTask.java:166)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
        at java.lang.Thread.run(Thread.java:722)
        Caused by: java.nio.channels.ClosedByInterruptException
        at java.nio.channels.spi.AbstractInterruptibleChannel.end(AbstractInterruptibleChannel.java:202)
        at java.nio.channels.Channels$ReadableByteChannelImpl.read(Channels.java:387)
        at com.sun.enterprise.util.io.FileUtils.copy(FileUtils.java:952)
        at org.glassfish.internal.deployment.GenericHandler.expand(GenericHandler.java:100)
        at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.expandIfNeeded(OSGiDeploymentRequest.java:259)
        at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.prepare(OSGiDeploymentRequest.java:154)
        at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.execute(OSGiDeploymentRequest.java:117)
        at org.glassfish.osgijavaeebase.AbstractOSGiDeployer.deploy(AbstractOSGiDeployer.java:123)
        ... 10 more
        ]]

        At the same time, after I executed "asadmin stop-domain", I can stop glassfish normally and need not to kill the java process from outside.

        So, My suggestion is that
        1. please blackbeltdev sees the above my confirmation and tried current v4 as possible
        2. if not happening on v4, please sahoo closed the issue.
        3. about the exception I mentioned, whether needing to re-open an issue?

        Thanks
        --Tang

        Show
        TangYong added a comment - For the issue, I have confirmed it in depth today using v4 SNAPSHOT as following: 1. About re-producing steps in description Firstly, re-producing steps in description are not very enough. And by investigations many times, right steps are as following: [Precondition] : the means of "re-deploy" should be directly putting bundles related the issue into "glassfish4\glassfish\domains\domain1\autodeploy\bundles" . (Here, I assumed that the user used domain1 only not clustering scene or used multi-domains scene) [Steps] 1) asadmin start-domain domain1 2) asadmin start-database 3) putting the following bundles into autodeploy\bundles slf4j-jcl-1.6.4.jar slf4j-api-1.6.4.jar com.springsource.org.apache.commons.logging-1.1.1.jar groovy-all-1.8.6.jar vaadin-6.7.5.jar cpms-web-static.jar [1] cpms-web.war [1] : you can also firstly put cpms-web.war, then put cpms-web-static.jar, and executing "asadmin osgi update <WAB's bundle id>". I adopted this way. Noting: please do not put jcl-over-slf4j-1.6.4.jar into autodeploy\bundles, because this will produce a conflict with slf4j-jcl-1.6.4.jar and cause a StackOverflowError while you accessed the vaadin application client. BTW: In reality, these dependent bundles needed not to be deployed as OSGi bundle alone, and right doing is to make them as inner class path or embed them into the war's inner class path. In addition, the demo itself is very interesting and uses fragment(cpms-web-static.jar) skill to attach vaadin's themes including widgetsets into host bundle(cpms-web.war) in order to reach dynamic themes switching(I guess) in the future. 4) accessing "http://localhost:8080/app/address-book/" and should be fine 5) modifying cpms-web.war's source(eg. I changed the war's servlet mapping name from address-book into address-book1), then, executing "mvn clean install" 6) replacing the cpms-web.war in autodeploy\bundles with new built cpms-web.war based 5) 2 About the "Hangs with logging similar to the below" After executing 6), I have not seen any "Hangs with logging similar to the below", however, in server.log, there are the following exceptions: [2013-03-25T16:35:23.156+0900] [glassfish 4.0] [WARNING] [] [org.glassfish.osgijavaeebase] [tid: _ThreadID=96 _ThreadName=pool-19-thread-1] [timeMillis: 1364196923156] [levelValue: 900] [[ Failed to deploy bundle com.textura.cpms.web [301] org.glassfish.osgijavaeebase.DeploymentException: Deployment of com.textura.cpms.web [301] failed because of following reason: Failed while deploying bundle com.textura.cpms.web [301] : java.nio.channels.ClosedByInterruptException at org.glassfish.osgijavaeebase.AbstractOSGiDeployer.deploy(AbstractOSGiDeployer.java:127) at org.glassfish.osgijavaeebase.OSGiContainer.deploy(OSGiContainer.java:154) at org.glassfish.osgijavaeebase.JavaEEExtender.deploy(JavaEEExtender.java:109) at org.glassfish.osgijavaeebase.JavaEEExtender.access$200(JavaEEExtender.java:61) at org.glassfish.osgijavaeebase.JavaEEExtender$HybridBundleTrackerCustomizer$1.call(JavaEEExtender.java:153) at org.glassfish.osgijavaeebase.JavaEEExtender$HybridBundleTrackerCustomizer$1.call(JavaEEExtender.java:150) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:722) Caused by: java.nio.channels.ClosedByInterruptException at java.nio.channels.spi.AbstractInterruptibleChannel.end(AbstractInterruptibleChannel.java:202) at java.nio.channels.Channels$ReadableByteChannelImpl.read(Channels.java:387) at com.sun.enterprise.util.io.FileUtils.copy(FileUtils.java:952) at org.glassfish.internal.deployment.GenericHandler.expand(GenericHandler.java:100) at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.expandIfNeeded(OSGiDeploymentRequest.java:259) at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.prepare(OSGiDeploymentRequest.java:154) at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.execute(OSGiDeploymentRequest.java:117) at org.glassfish.osgijavaeebase.AbstractOSGiDeployer.deploy(AbstractOSGiDeployer.java:123) ... 10 more ]] At the same time, after I executed "asadmin stop-domain", I can stop glassfish normally and need not to kill the java process from outside. So, My suggestion is that 1. please blackbeltdev sees the above my confirmation and tried current v4 as possible 2. if not happening on v4, please sahoo closed the issue. 3. about the exception I mentioned, whether needing to re-open an issue? Thanks --Tang
        Hide
        Sanjeeb Sahoo added a comment - - edited

        Tang,

        The fix made in GLASSFISH-18159 means we won't deadlock, but we introduced a timeout functionality. The interrupted exception suggests some other thread interrupted the deployment process because of timeout. See the log file closely to see if there is any message to this effect. The default value for timeout is 10 seconds. See GLASSFISH-20023 to see how you can change it.

        Sahoo

        Show
        Sanjeeb Sahoo added a comment - - edited Tang, The fix made in GLASSFISH-18159 means we won't deadlock, but we introduced a timeout functionality. The interrupted exception suggests some other thread interrupted the deployment process because of timeout. See the log file closely to see if there is any message to this effect. The default value for timeout is 10 seconds. See GLASSFISH-20023 to see how you can change it. Sahoo
        Hide
        TangYong added a comment -

        Sahoo,

        I am sorry for forgetting to say a point:

        The exception can not be re-produced after I applied GLASSFISH-19688, and I felt a litter curious.

        So, whether can close the issue?

        In addition,

        > See GLASSFISH-20023 to see how you can change it.
        Your means is whether an user can set the value of "org.glassfish.osgijavaeebase.deployment.timeout" except in osgi.proerties file?

        If such being the case, we should create a new feature to resolve it.

        Thanks
        --Tang

        Show
        TangYong added a comment - Sahoo, I am sorry for forgetting to say a point: The exception can not be re-produced after I applied GLASSFISH-19688 , and I felt a litter curious. So, whether can close the issue? In addition, > See GLASSFISH-20023 to see how you can change it. Your means is whether an user can set the value of "org.glassfish.osgijavaeebase.deployment.timeout" except in osgi.proerties file? If such being the case, we should create a new feature to resolve it. Thanks --Tang
        Hide
        Sanjeeb Sahoo added a comment -

        If you can't reproduce, then close the issue.

        Show
        Sanjeeb Sahoo added a comment - If you can't reproduce, then close the issue.
        Hide
        TangYong added a comment -

        The issue can not be re-produced after fixing GLASSFISH-19688 which will be fixed in 4.0_b82_EE7MS7.

        If seeing the issue again in the future, I will re-open the issue.

        Show
        TangYong added a comment - The issue can not be re-produced after fixing GLASSFISH-19688 which will be fixed in 4.0_b82_EE7MS7. If seeing the issue again in the future, I will re-open the issue.

          People

          • Assignee:
            Sanjeeb Sahoo
            Reporter:
            blackbeltdev
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: