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 >