12:03 p.m.
On 12/22/10 11:10 AM, Alan Santos wrote:
The console definitely needs to support standalone as well as domain,
and I agree that historic data collection is outside the scope of an
unmanaged instance.
I'm curious about the question of hosting the mgmt console as I assumed
it would live in the domain controller. I don't have my notes from
Antwerp available to double check, but isn't the domain controller just
another AS instance? If so why wouldn't it always live in that process?
No, a domain controller is not an EE-capable app server.* It's a
specialized java process that only supports required functionality. From
an external client POV, the functionality it needs to expose are:
1) A socket backed by a service that understands the proprietary Java
protocol we'll use for the detyped management API.
2) An mbean server and a JMX connector.
3) A socket backed by a service that understands HTTP/HTTPS and can
support our REST interface. Note that this does not require Servlet spec
support. Our thinking at this time is to base this on the lightweight
HTTP server in JDK 6.
* To be precise, a DomainController is a HostController whose host.xml
config tells it to load the domain controller module rather than making
a connection to a remote HostController.
And now that I've asked that question I'm curious - Are
there
expectations with regard to continuity for deployed applications when
transitioning a server from a single instance to a domain?
The deployed application depends on the runtime services provided by the
AS instance's subsystems. There is no reason an AS instance running as
part of a domain can't be configured to provide the same runtime
services as a standalone server. If they can't be configured to provide
the same runtime environment, it's a bug. Most of the configuration
comes from the "profile" element, the contents of which can be identical
between domain.xml and standalone.xml.
The only exceptions I see to this are:
1) Domain mode does not support automatic deployment based on scanning
the filesystem. But that's not something the application itself uses.
2) The management API exposed by an AS instance is different in domain
mode vs standalone. Basically, a standalone AS instance allows a client
to the management API to update the instance's persistent configuration.
In domain mode, any updates to the persistent configuration need to be
done via the DomainController or HostController. But I doubt many
applications will want to alter the AS instance's persistent
configuration. If they do they'll need to be written to understand
domain mode vs. standalone.
-alan
On 12/22/10 11:25 AM, Brian Stansberry wrote:
> On 12/22/10 8:19 AM, Heiko W.Rupp wrote:
>> Hi,
>>
>> we were talking about admin console before, but I am not sure if we reached any
conclusion about
>> - console for standalone (=non-domain) server mode
> IMO we need the console to properly support standalone mode.
>
>> - will we have a "dedicated" server within a domain to host the console
or could
>> theoretically every server host the console?
> Theoretically any server could host the console. The console is a client
> to the admin interface exposed by the DomainController, the
> HostController(s) and any ServerController(s).
>
> I expect a typical scenario is users will want a separate server to host
> the console; i.e. separate from the regular servers that handle user
> requests. Since servers all belong to a server group, that implies a
> separate server group running a profile sufficient to support the
> console webapp. The configuration utilities we provide to help users set
> up their configs need to make it easy to create such a configuration.
>
>> - do users expect to see metrics for the last hour from the moment they first
>> access the console or already for some time before?
>>
> There is no committed requirement to support maintaining a 1 hour
> history of metrics. IMO if we want to support this, it should be a JON
> feature, with JON responsible for storing the history. (I realize that
> begs the question "What about if JON wasn't running..." to which the
> response is "there is no committed requirement...")
>
>> Heiko
>>
>
_______________________________________________
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