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

[Darryl Miles (JIRA)]

    [ https://jira.jboss.org/jira/browse/JBIDE-4925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12489428#action_12489428 ] 

Darryl Miles commented on JBIDE-4925:
-------------------------------------

Just got around to look at patch.  Again this is a 10000 foot view of it.

The patch looks like it will deal with the "hung UI" part of the issue.  However.... the thread that is pushing the JMX command over the network socket will continue to be running ?  is t.interrupt() enough to ensure it finishes?  it may just retry the network IO method and block again right away.


So the next comment is... can you invalidate the "connection" so that it effectively closes the socket from underneath the thread trying to push the command, a "force close of socket", this should make the JMX thread wakeup and return/cleanup since there is no network socket to retry IO on and the error of a closed socket is terminal.  Can I also ask if the "connection" object is then invalidated from future use by the publishing tools ?  i.e. if a future publish operation requires a JMX connection (in a future publish operation) it needs to go and create a new one (i.e. reconnect).


Another issue, you've now added upto an additional 1 second delay to processing, (the time left on the remaining Thread.sleep(1000)) this really SHOULD wake up immediately if either the monitor changes or the thread terminates.  If anything upon Thread terminating SHOULD be immediately but the cancellation request CAN have some seconds delay.  This design decision is on the basis of the most frequently used code path, choices impacting developer productivity and that the cancellation feature is hardly used by an important feature.

The way out of this is to setup a basic Object lock/wait before thread creation, at exit of sub-thread signal a wakeup object.interrupt() and use the standard object.sleep() mechanism instead of Thread.sleep() all with appropriate synchronized locking.



Re the 4 seconds.. maybe this is a bit short... yes most of the time it should happen really fast but.... it can early take over 4 seconds to page in eclipse + jboss, it can take eclipse longer than that for the UI to wake up after going for lunch (due to paging on a 6Gb, dual cpu 64bit system).  Also you have now fixed the ability to cancel the publish so if the wait it too long the user can now cancel and start over.  Now people never use the cancel feature you just added since they never press it before 4 seconds are up, maybe 10 or 15 is better IMHO.


final Object waitObject = new Object();

// Create thread

// Inside sub-thread code
//.....
} catch (Exception ex) {
  exception = ex;  // Do this to local storage (not directly to a shared variable)
}
synchronized(waitObject) {
 e[0] = exception;  // Only assign the shared variable while we hold the lock
 waitObject.notifyAll();
}
// end of sub-thread-code
// ...

// start thread.....
// for wait loop
while(t.isAlive() && !monitor.isCanceled() && count <= 4000) {
  count+= 1000;
  synchronized(waitObject) {
    try {
      waitObject.sleep(1000);
    } catch(InterruptedException eat) {
    }
  }
}
if( t.isAlive()) {
  connection.forceSocketClosureThreadSafeImplementation();
  connection.invalidateFromFutureUse();  // this removes this instance of 'connection' from the server tools (and forces the next operation to acquire a new one)
  // Do existing logging error stuff
}


> 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