Dies Koper wrote:
>>>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?
The directory will be created automatically. But if you want to have transaction
logs to be shared by several instances, you need to follow rules described in
"Distributed Transaction Recovery" section of the docs (e.g.
http://docs.sun.com/app/docs/doc/819-3672/gaxim?a=view)
Regards,
-marina
>
>
> 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?
>