It looks like the issue is on the client side. The ModelControllerClient
uses an internal executor service with threads named
"management-client-thread XXX". The stack traces only show 1 such
thread, sitting idle. The core pool size on the executor is 2, so there
should be a 2nd thread, and presumably that's the one that should be
doing the work (i.e. waiting for the server response.
That sounds like something has happened that propagated all the way back
to the pool and killed the thread.
I don't know what though, or why it would fail for you but not with the
CLI. The request has reached the server and at that point the code
should be executing the same basic code path as the CLI.
On 5/29/15 2:25 AM, Rob Stryker wrote:
Hey All:
I've been trying to dig into this for a while but really haven't gotten
very far. Glance at
https://issues.jboss.org/browse/JBIDE-19641
It seems our client (jbosstools) appears to have frozen while sending a
large war over mgmt api for deployment. Unfortunately, looking at the
stacks doesn't show anything strange. In fact, it seems the transfer is
still in effect. However, our user indicates that disk activity (ie
transfer) has ceased, and yet the client jar classes have not indicated
the transfer was done or aborted.
The class we use to perform the mgmt publish is
https://github.com/jbosstools/jbosstools-server/blob/master/as/plugins/or...
It's pretty simple, but QE is indicating it freezes and after a short
while, nothing happens.
I was wondering if anyone here might have any insight? QE indicates
the transfer works fine over jboss-cli, but not in jbt.
Thanks in advance.
- Rob Stryker
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat