10:31 a.m.
Hi,
I know I am late to this game.
I am puzzled by the fact that in domain mode I get the list of jdbc drivers by
[standalone@localhost:9999 server=server-one] pwd
/host=local/server=server-one
[standalone@localhost:9999 server=server-one]
./subsystem=datasources:installed-drivers-list
actually with picking a random host within a server group after previously having
uploaded
and deployed the driver jar to the server group.
This makes obviously sense if we allow individual drivers per managed AS instance in a
SG,
but then installing a datasource that uses such a driver on /profile=X/subsystem=DS level
sounds like a big source of confusion if one of the managed servers happens to have
a different version of the driver and this only managed AS starts to behave in strange
ways
Wouldn't it make more sense to put :installed-drivers-list on server-group level?
Heiko
3:44 p.m.
On 6/7/11 10:31 AM, Heiko W.Rupp wrote:
Hi,
I know I am late to this game.
I am puzzled by the fact that in domain mode I get the list of jdbc drivers by
[standalone@localhost:9999 server=server-one] pwd
/host=local/server=server-one
[standalone@localhost:9999 server=server-one]
./subsystem=datasources:installed-drivers-list
actually with picking a random host within a server group after previously having
uploaded
and deployed the driver jar to the server group.
This makes obviously sense if we allow individual drivers per managed AS instance in a
SG,
but then installing a datasource that uses such a driver on /profile=X/subsystem=DS
level
sounds like a big source of confusion if one of the managed servers happens to have
a different version of the driver and this only managed AS starts to behave in strange
ways
Wouldn't it make more sense to put :installed-drivers-list on server-group level?
The server group resource knows nothing about the details of the
profile, i.e. what operations its subsystems expose on the servers, it
just knows that the servers are running a profile named "x".
I could see a generic operation on the server-group resource that
amounts to "execute operation X on all servers in the group and provide
an aggregate response."
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
3:23 a.m.
Brian,
> actually with picking a random host within a server group after
previously having uploaded
> and deployed the driver jar to the server group.
[..]
> Wouldn't it make more sense to put :installed-drivers-list on
server-group level?
>
The server group resource knows nothing about the details of the
profile, i.e. what operations its subsystems expose on the servers, it
just knows that the servers are running a profile named "x".
Shouldn't that be sort of the same things? I mean if I can :add a jdbc driver to
a server-group, which in turn installs it on all the managed servers, shouldn't
then there be a :list as its counterpart?
I could see a generic operation on the server-group resource that
amounts to "execute operation X on all servers in the group and provide
an aggregate response."
Hm. That would for sure be helpful.
The other thing that I am concerned with is consistency. My understanding is so far
that a server group consists of (almost) identical managed servers. Of course IP,
port mapping and perhaps jvm characteristics are the same.
This means to me, that when I deploy something to a server group, this thing
ends up in every managed AS and the other way around: everything that is deployed
to a managed AS can be found on all managed AS of the respective server group.
This also implies that for deployments, the server-group is the point of interaction and
not a single host.
Heiko
--
Reg. Adresse: Red Hat GmbH, Technopark II, Haus C,
Werner-von-Siemens-Ring 14, D-85630 Grasbrunn
Handelsregister: Amtsgericht München HRB 153243
Geschaeftsführer: Brendan Lane, Charlie Peters, Michael Cunningham, Charles Cachera
3:31 a.m.
On Jun 8, 2011, at 10:23 AM, Heiko W.Rupp wrote:
This means to me, that when I deploy something to a server group,
this thing
ends up in every managed AS and the other way around: everything that is deployed
to a managed AS can be found on all managed AS of the respective server group.
This also implies that for deployments, the server-group is the point of interaction and
not a single host.
IIRC the problem is that only runtime component on each host (JCA in this case)
knows how to identify the deployment. For any other component it's merely a blob.
This means that only after a successful deployment to a host, the blob is identified as a
JDBC driver
and hence operation requests need to be executed on this level.
Ike
11:19 a.m.
On 6/8/11 3:31 AM, Heiko Braun wrote:
On Jun 8, 2011, at 10:23 AM, Heiko W.Rupp wrote:
> This means to me, that when I deploy something to a server group, this thing
> ends up in every managed AS and the other way around: everything that is deployed
> to a managed AS can be found on all managed AS of the respective server group.
>
> This also implies that for deployments, the server-group is the point of interaction
and
> not a single host.
IIRC the problem is that only runtime component on each host (JCA in this case)
knows how to identify the deployment. For any other component it's merely a blob.
This means that only after a successful deployment to a host, the blob is identified as a
JDBC driver
and hence operation requests need to be executed on this level.
Yes, that's why finding out what the installed drivers are requires a
call to the servers.
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
11:29 a.m.
On 6/8/11 3:23 AM, Heiko W.Rupp wrote:
Brian,
>> actually with picking a random host within a server group after previously having
uploaded
>> and deployed the driver jar to the server group.
[..]
>> Wouldn't it make more sense to put :installed-drivers-list on server-group
level?
>>
>
> The server group resource knows nothing about the details of the
> profile, i.e. what operations its subsystems expose on the servers, it
> just knows that the servers are running a profile named "x".
Shouldn't that be sort of the same things? I mean if I can :add a jdbc driver to
a server-group, which in turn installs it on all the managed servers, shouldn't
then there be a :list as its counterpart?
> I could see a generic operation on the server-group resource that
> amounts to "execute operation X on all servers in the group and provide
> an aggregate response."
Hm. That would for sure be helpful.
Another variant could be to "execute operation X on any random running
server in the group". This is for the case where the result is expected
to be the same from all servers.
The other thing that I am concerned with is consistency. My
understanding is so far
that a server group consists of (almost) identical managed servers. Of course IP,
port mapping and perhaps jvm characteristics are the same.
This means to me, that when I deploy something to a server group, this thing
ends up in every managed AS and the other way around: everything that is deployed
to a managed AS can be found on all managed AS of the respective server group.
This also implies that for deployments, the server-group is the point of interaction and
not a single host.
Depends on the interaction. A lot of things will be consistent across
all servers; other things may not be, e.g. metrics. The DC isn't going
to have in memory details about the deployment that are ony discovered
when the deployment passes through the deployment processor chain, as
that only happens on the servers. So even for the stuff that's
consistent across servers, the DC is going to have to go to a server to
find out the information.
This is why I'm thinking in terms of generic operations that can be
offered at the server group level but which handle for the end user the
task of calling to the servers.
Heiko
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
5003
days inactive
5004
days old
5 comments
3 participants
participants (3)
-
Brian Stansberry -
Heiko Braun -
Heiko W.Rupp