[
https://jira.jboss.org/jira/browse/JBIDE-4925?page=com.atlassian.jira.plu...
]
Rob Stryker commented on JBIDE-4925:
------------------------------------
What I've read is this:
Interrupting an I/O operation
But what happens if the thread is blocked on an I/O operation? I/O can block a thread for
a considerable amount of time, particularly if network communication is involved. For
example, a server may be waiting for a request, or a network application may be waiting
for an answer from a remote host.
If you're using channels, available with the new I/O API introduced in Java 1.4, the
blocked thread will get a ClosedByInterruptException exception
----
Now unfortunately the code which is executing this stuff are in jboss-as classes, and
I'm not sure if they're using the 1.4 API, but I'd assume at this point they
are.
However if it turns out they are using the java 1.0 I/O apis, then interrupt() does
nothing. But in this case, I have no way to ensure the thread terminates properly. The
only connection *I* have access to is the MBeanServerConnection, and the mbean server
connection has no method on it which would allow me to terminate the connection. In fact,
the thread is frozen during the connection.invoke(etc) call, which goes into AS proxy
classes and all sorts of stuff.
As far as I can tell I have no way to truly 100% ensure that the underlying thread is
closed and completed. If the JBoss AS classes are in fact using 1.4 APIs for I/O, then the
connection should be closed by the ClosedByInterruptException and the thread should end
gracefully.
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