[jbosstools-issues] [JBoss JIRA] Resolved: (JBIDE-4925) JBossAS Publish, Modal dialog blocking UI (until timeout, not supporting job cancellation)

[Rob Stryker (JIRA)]

     [ https://jira.jboss.org/jira/browse/JBIDE-4925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rob Stryker resolved JBIDE-4925.
--------------------------------

    Resolution: Done


I've applied the patch after having some others review it and read through some API. If this issue in fact isn't fixed, please please re-open it. 

> JBossAS Publish, Modal dialog blocking UI (until timeout, not supporting job cancellation)
> ------------------------------------------------------------------------------------------
>
>                 Key: JBIDE-4925
>                 URL: https://jira.jboss.org/jira/browse/JBIDE-4925
>             Project: Tools (JBoss Tools)
>          Issue Type: Bug
>          Components: JBossAS
>    Affects Versions: 3.1.0.M2
>            Reporter: Darryl Miles
>            Assignee: Rob Stryker
>             Fix For: 3.1.0.M4
>
>         Attachments: JBIDE-4925_premature.patch
>
>
> The tooling can often attempt to publish to JBoss AS but it never completes.  Maybe JBoss AS product failed.
> The Eclipse runtime job manager displays the publishing job with a job cancellation button, JBoss Tooling fails to attempt or process this cancellation request so the UI can end up hung at a modal "public job in progress" dialog without any availity to background it.  The only way out is to kill the process ID on the system and restart eclipse.
> Here is a stack trace of the only active thread with org.jboss.* in it.  It appears to be waiting for something from a network socket and it appear to be using blocking network I/O to get it.  I'm don't fully understand the JMX stuff myself (but I guess its some kind of management network channel), in this situation and the situation of publishing stuff the command it is attempting to send should be given a maximum timeout before the command (and network connection) is aborted and Eclipse attempt to reconnect to the AS (at least 1 time).   If the JMX command is stateless or the first command that would begin a stateful interaction (then quickly realizing the JMX connection is no longer working and reopening the connection to retry the JMX command make sense.
> But the main issue here is the fact that the JMX network handling is not being done with a regard for the Eclipse job monitor, I think this can be effected easily by making the thread which handles the public register itself just before it begin any unit-of-work that may block for an unknown about of time.   Then the socket I/O is interrupted causing an exception be thrown (unblocking that thread).
> Here is a stack trace of the only active thread with org.jboss.* in it. 
> "Worker-39" prio=10 tid=0x08c5bc00 nid=0x227a runnable [0xf310b000]
>    java.lang.Thread.State: RUNNABLE
>         at java.net.SocketInputStream.socketRead0(Native Method)
>         at java.net.SocketInputStream.read(SocketInputStream.java:129)
>         at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
>         at java.io.BufferedInputStream.read(BufferedInputStream.java:237)
>         - locked <0x4b08b708> (a java.io.BufferedInputStream)
>         at java.io.DataInputStream.readByte(DataInputStream.java:248)
>         at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:195)
>         at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:142)
>         at org.jboss.invocation.jrmp.server.JRMPInvoker_Stub.invoke(Unknown Source)
>         at org.jboss.invocation.jrmp.interfaces.JRMPInvokerProxy.invoke(JRMPInvokerProxy.java:133)
>         at org.jboss.invocation.InvokerInterceptor.invokeInvoker(InvokerInterceptor.java:365)
>         at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:197)
>         at org.jboss.jmx.connector.invoker.client.InvokerAdaptorClientInterceptor.invoke(InvokerAdaptorClientInterceptor.java:66)
>         at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:68)
>         at org.jboss.proxy.ClientMethodInterceptor.invoke(ClientMethodInterceptor.java:74)
>         at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:101)
>         at $Proxy4.invoke(Unknown Source)
>         at org.jboss.ide.eclipse.as.core.server.internal.JBossServerBehavior.suspendDeployment(JBossServerBehavior.java:235)
>         at org.jboss.ide.eclipse.as.core.server.internal.JBossServerBehavior$3.run(JBossServerBehavior.java:194)
>         at org.jboss.ide.eclipse.as.core.extensions.jmx.JMXSafeRunner.run(JMXSafeRunner.java:71)
>         at org.jboss.ide.eclipse.as.core.extensions.jmx.JMXSafeRunner.run(JMXSafeRunner.java:52)
>         at org.jboss.ide.eclipse.as.core.extensions.jmx.JBossServerConnection.run(JBossServerConnection.java:92)
>         at org.jboss.ide.eclipse.as.core.extensions.jmx.JBossServerConnectionProvider.run(JBossServerConnectionProvider.java:51)
>         at org.jboss.ide.eclipse.as.core.server.internal.JBossServerBehavior.publishStart(JBossServerBehavior.java:198)
>         at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publish(ServerBehaviourDelegate.java:847)
>         at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publish(ServerBehaviourDelegate.java:708)
>         at org.eclipse.wst.server.core.internal.Server.publishImpl(Server.java:2690)
>         at org.eclipse.wst.server.core.internal.Server$PublishJob.run(Server.java:272)
>         at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira