Please pretty much disregard this; I inadvertently hit "Send".
While I think it's odd there's only one management-client-thread, that
doesn't necessarily mean the other one failed. In particular I don't
expect a thread to be blocking waiting for a response. It's all based on
callbacks when xnio/remoting gets data.
On 6/1/15 1:38 PM, Brian Stansberry wrote:
It looks like the issue is on the client side. The
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
> 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