Absolutely.
If all you need is a Java system property that is unique for instances
in a cluster, you can do the following:
- In the cluster, define a Java system property (we call it JVM option
for some weird reason) named defaultClientId (e.g.) using command
like: asadmin create-jvm-options -- "-DdefaultClientId=${UNIQUE_NAME}"
As a result, the cluster's java-config element would have something
like: <jvm-options>-DdefaultClientId=${UNIQUE_NAME} </jvm-options>
- Define a GlassFish system property (weird name, but that's what it
is!) that overrides the value of UNIQUE_NAME per instance:
asadmin create-system-properties --target instance1
UNIQUE_NAME=cluster1:instance1
asadmin create-system-properties --target instance1
UNIQUE_NAME=cluster1:instance2
assuming name of the cluster is "cluster1" and instances are named
"instance1" and "instance2".
- Restart the cluster.
The instance1 will start with -DdefaultClientId=cluster1:instance1 and
instance2 will start with -DdefaultClientId=cluster1:instance2,
which is what you want.
I hope this can be easily tied with Roller's properties file.
Regards,
Kedar
Dick Davies wrote:
> Hi, we're running a 2 node GFv2 cluster, and we've got the Roller
> weblogger running
> on both nodes.
>
> I've been debugging some weird issues the past day or two and think I
> found the problem;
> the webapp needs a property
>
> # client identifier. should be unique for each instance in a cluster.
> tasks.clientId=defaultClientId
>
> (in a bundled properties file) to uniquely identify each
> instance (to handle concurrent access to parts of the database).
>
> Since both glassfish instances are running the same WAR file, they
> both have the same clientid.
>
> I really don't want to have to write 2 different WARfiles, so I'm
> wondering if there's a way to set
> a system property at glassfish instance startup (-Dclientid=$HOSTNAME),
> that I could somehow inject into that properties file?
>
>