[wildfly-dev] Gathering diagnostic data

[Brian Stansberry]

On 3/4/14, 6:49 PM, James Livingston wrote:
> On Wed, 2014-02-26 at 06:41 -0600, Brian Stansberry wrote:
>> You either need to provide 2 ops, or the details with no fallback, or
>> just the unstructured text. It can't be a single op that provides well
>> structured data except if something goes wrong in which case it provides
>> unstructured text. The metadata for an op describes the structure of the
>> return data, and that description can't be ambiguous.
>>
>> I think starting with a just-text op is best and then let your users
>> help drive your roadmap.
>
> Thanks, I'll do that and see what everyone wants to use it for.
>
>
> To me, the obvious place for these kind of server-specific ops in domain
> mode would be under /host=*/server=*/ probably under sub-model

Doing this in a sub-resource would be very difficult as it significantly 
complicates the issues I'll discuss below.

> since
> there could be a non-trivial number of useful operations. Operations
> there get routed to the server to execute, but I need code run on the HC
> instead.
>

Yes, this is a general problem; the /host=*/server=* resource actually 
resides on the server process; on the host process at that address all 
there is is some proxy code that proxies the request to the server.

If you look at DomainModelControllerService.registerRunningServer() you 
can see where it adds some extra ops to the resource registration for 
the server address:

// Register local operation overrides
         final ManagementResourceRegistration serverRegistration = 
hostRegistration.getSubModel(PathAddress.EMPTY_ADDRESS.append(pe));
 
ServerConfigResourceDefinition.registerServerLifecycleOperations(serverRegistration, 
serverInventory);

That's ok for that single case, but we need to find a slicker mechanism 
for doing this kind of thing. I don't want DomainModelControllerService 
to end up full of this kind of logic.

If you want to add in another call like that 
ServerConfigResourceDefinition.registerServerLifecycleOperations call 
for now to keep progressing though, that's fine. We'll just need to come 
up with something better before we're done.

> I've seen the HOST_CONTROLLER_ONLY flag which sounds like what I want,
> but that doesn't affect /host/server ops. Am I mis-understanding the
> flag and that's not what it's for, or should it work?
>

That's not what it's for. :) It's for preventing 2-step behavior when it 
would otherwise occur, but in this case 2-step behavior isn't desired.

> PrepareStepHandler uses isServerOperation() to direct operations under a
> server to the instance without regard for HOST_CONTROLLER_ONLY, and
> OperationRouting.determineRouting() only checks the flag if it's not in
> that location.
>

The routing is correct -- the call should execute direct and not go into 
the 2 phase logic used for stuff that applies locally and then gets 
rolled out to servers. This needs to be solved via some more 
sophisticated behavior in the HC process at the /host=*/server=* address.


-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat