>> Also, a directory with the name of the instance will be created in the
>> log directory to store the transaction logs. (Which are not
>> human-readable, they contain data on on-going transactions, to be able
>> to clean them up if the instance suddenly dies in the middle of a global
>> transaction). These shouldn't be sync'ed either.
>
> Yes, the log directory shouldn't be sync'ed.
>
> Which log directory are the transaction logs stored in?
> Hopefully the <instance>/logs directory. Why would it
In <instance>/logs/<instance>/tx:
D:\glassfish-v2.1.1-b22b\glassfish\nodeagents\FASTN9061\cl1-1\logs\cl1-1
D:\glassfish-v2.1.1-b22b\glassfish\nodeagents\FASTN9061\cl1-1\logs\jvm.log
D:\glassfish-v2.1.1-b22b\glassfish\nodeagents\FASTN9061\cl1-1\logs\server.log
D:\glassfish-v2.1.1-b22b\glassfish\nodeagents\FASTN9061\cl1-1\logs\cl1-1\tx
D:\glassfish-v2.1.1-b22b\glassfish\nodeagents\FASTN9061\cl1-1\logs\cl1-1\tx\control
D:\glassfish-v2.1.1-b22b\glassfish\nodeagents\FASTN9061\cl1-1\logs\cl1-1\tx\cushion
D:\glassfish-v2.1.1-b22b\glassfish\nodeagents\FASTN9061\cl1-1\logs\cl1-1\tx\extent.001
D:\glassfish-v2.1.1-b22b\glassfish\nodeagents\FASTN9061\cl1-1\logs\cl1-1\tx\recoveryfile
My cluster instance name is 'cl1-1'.
> need to create an <instance>/logs/<instance> directory
> for the transaction logs?
Good question. Maybe Marina (CC'ed) knows?
But that won't affect the design for this as we're not sync'ing it anyway.
>>> If the instances do their own synchronization, it seems that we can't
>>> support having a single config directory per node, shared by all the
>>> instances. The config data will have to be moved under the
>>> <instance>/config directory. Anyone see any problems with that?
>>
>> As it is in V2, right?
>
> No, as I understand it (and I'm not an expert in this, I'm going on
> what others have told me), the config data is in the node agent's
> config directory, not the instance's config directory. I'm proposing
> a change to that.
Not sure what you mean by "the config data".
Both have a config directory with about 20 files.
But not all the same files.
agent/config has das.properties, nodeagent.properties, admch and about
ten files to store timestamps (.domain.xml.timestamp,
keystore.jks.timestamp, etc.)
<instance>/config has the following files that agent/config doesn't have:
default-domain.xml.templatetransformed0
default-web.xml
derby.log
domain-registry
keyfile
secure.seed
sun-acc.xml
wss-server-config-1.0.xml
wss-server-config-2.0.xml
<instance>/config also has a .shoal/<instance> folder with jxta stuff
(for GMS I suppose).
So there are about eight files left that they have in common.
>> As we discussed yesterday, there is only one node agent per domain per
>> machine. So I thought, why not make the name exactly the same as the
>> domain name?
>
> Because the domain name is not unique. Multiple domains can have a
> domain named "domain1".
It took me a while to understand this, but you are referring to the
following situation, right?
- On machine 1 I have a domain called 'domain1'.
- On machine 2 I have a (totally unrelated) domain called 'domain1'.
- On machine 3 I want to join instances as part of clusters managed by
the DAS's in machines 1 and 2, which both have the domain name 'domain1'
>> The create-node-agent command (with the fake option) could be run as
>> part of 'ant -f setup-cluster.xml' or whatever mechanism we'll have in
>> GFv3.1 to enable cluster mode.
>
> We shouldn't need any such command. It should always be prepared for
> you to create a cluster.
So you're saying that as part of the create-cluster command we should
create the directory structure, and your suggestion was to internally
call the create-node-agent command with an additional (hidden) option?