7:55 p.m.
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).
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?
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.
1:07 p.m.
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".
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.
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?
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
7:08 p.m.
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.
5088
days inactive
5089
days old
2 comments
2 participants
participants (2)
-
Brian Stansberry -
Scott Stark