Hi Tom, Many thanks for the reply. For DAS Failover, I was going off the
3.1 High Availability Administration Guide:
http://download.oracle.com/docs/cd/E18930_01/html/821-2426/gbcot.html#gcmkp
"Put the domain installation and configuration on a shared and robust file
system (NFS for example). If the primary DAS host fails, a second host is
brought up with the same IP address and will take over with manual
intervention or user supplied automation." That pretty well sums up what
I've been doing. I've got the DAS domain and config on NFS, and I'm
preforming user-supplied automation. You're right, there aren't any
concrete steps on how to implement this, but I felt OK about it since it was
mentioned in the docs. Good to know about the asadmin command. That
pretty well confirms what I've read and experimented with. I am still
assuming that das.properties is referenced by the instances when doing an
asadmin deployment targeting a cluster. I was testing a scenario in which I
set das.properties to localhost on all the instances. Then, I used asadmin
to deploy clusterjsp: asadmin deploy --availabilityenabled=true
--target mycluster clusterjsp.ear With das.properties set to localhost on
all the instances, the asadmin deploy command succeeds in that it does not
report any errors. It fails in that it doesn't create any of the expected
directories for the application under the remote instances. Almost exactly
the same behavior as this
post:
http://www.java.net/forum/topic/glassfish/glassfish/deployment-problem-glassfish-31-remote-instances
and related JIRA issue. Note, this comment about setting das.properties to
localhost on all instances was just a test case. I'm no longer doing
this…
--
[Message sent by forum member 'sspyrison']
View Post: http://forums.java.net/node/801774