[jboss-as7-dev] A domain controller msg bus

[Scott Stark]

On 2/2/11 11:07 AM, Brian Stansberry wrote:
> On 2/1/11 7:55 PM, Scott Stark wrote:
>> I'm starting to look into the current domain controller for a prototype
>> integration of byteman I want to investigate for use in cloud based as7
>> usage. The idea is to have an byteman rules extension to the domain with
>> aggregated reporting of the pieces back to a "centralized" location for
>> processing. A similar usecase exists for log msgs of certain severity or
>> context (security for example).
>>
> The use cases seem to fall into the "management" category, so having the
> domain controller involved seems ok. It's not required to have the DC
> running in order to let the servers handle ordinary requests; it's only
> required to perform "management". So we don't want to add any tasks to
> the domain infrastructure that aren't "management".
>
It does likely fall into some form of monitoring, for example, 
collecting exceptions of certain types, call path timings, ...
>> I'm guessing we don't want this to be on the domain controller
>> operations msg bus to avoid its stability and performance being
>> impacted. I can certainly build this at another layer using service(s)
>> in domain servers, but would it be beneficial to look into a domain msg
>> bus(es) notion at this point?
>>
> What's the expected direction for these messages? Pulled from the
> servers by the DC? Or pushed to the DC from the servers a la notification?
>
> This seems like a particular example of a general problem we have to
> solve; how to ensure that high priority traffic isn't starved for
> resources behind lower priority stuff.
>
I expect the msgs to be pushed to a central service for 
aggregation/processing. Yes, the concern is either multiplexing on the 
management channel or having a separate msg bus/channel. It most likely 
should be its own monitoring subsystem.

>> The RHEV layer is heading towards a msg bus as its main mechanism for
>> configuring/controlling instances it seems. I would expect that at some
>> point the open jdk vm will better integrate with the kvm and expose this
>> bus.
>>
> So you're seeing this as an alternative to traditional network I/O?
Yes, much like OSes that have a native msg piece (mach was one I used 
this feature) I can see that we will need to listen to events, and push 
information back to it.