Setup:
I have 2 machines. Machine "W" is running DAS. Machine "U" is going
to run the instance.
I go to machine "U", setup the directories correctly.
das.properties has the host pointing at "W".
Machine "U" has no DAS running it. (normal scenario).
=============
I run _synchronize-instance
and it immediately fails. It is trying to get help info from
localhost:4848.
It makes no sense for me to call it like so: "asadmin --host "das-ip"
_synchronize-instance" because it is a local command.
You also can't call the local instance for the help info because it
doesn't exist yet
Solution (?)
use the properties from the das.properties to make the -Xhelp call.
==================================================================
~/gf/v3/cluster/cli>asadmin _synchronize-instance
CLASSPATH=
/export/home/bnlocal/glassfishv3/glassfish/bin/../modules/admin-cli.jar
Commands: [_synchronize-instance]
asadmin extension directory:
/export/home/bnlocal/glassfishv3/glassfish/lib/asadmin
Prepare
Process program options
Parsing program options
Parse command options
params: {}
operands: []
Prevalidate command options
Inject command options
Validate command options
nodeAgentDir:
/export/home/bnlocal/glassfishv3/glassfish/nodeagents/improvident.sfbay
instanceDir:
/export/home/bnlocal/glassfishv3/glassfish/nodeagents/improvident.sfbay/i1
dasProperties:
/export/home/bnlocal/glassfishv3/glassfish/nodeagents/improvident.sfbay/agent/config/das.properties
asadmin --host localhost --port 4848 --interactive=true --echo=false
--terse=false _synchronize-instance
Execute command
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<synchronize-files>
<instance>i1</instance>
<directory>config</directory>
</synchronize-files>
Sync directory:
/export/home/bnlocal/glassfishv3/glassfish/nodeagents/improvident.sfbay/i1/config
Prepare
Parsing program options
Getting user name from ~/.asadminpass: admin
Setting user to: admin
Getting password from ~/.asadminpass
Setting password to: <null>
URI: /__asadmin/_synchronize-files?Xhelp=true
URL: com.sun.enterprise.admin.util.HttpConnectorAddress@349471
URL:
http://localhost:4848/__asadmin/_synchronize-files?Xhelp=true
Using auth info: User: admin, Password: <null>
doHttpCommand: connect exception java.net.ConnectException: Connection
refused
RemoteCommand.prepare throws org.glassfish.api.admin.CommandException:
ConnectException
sync.failed
Command _synchronize-instance failed.
\
On 5/17/2010 12:29 PM, Bill Shannon wrote:
As I'm
sure you remember, "synchronization" happens in two different ways:
- startup synchronization, that synchronizes the instance with the DAS
when the instance is started
- command replication, that synchronizes the running instance with the
DAS by executing the same command on the instance that was executed
on
the DAS
I've got a first cut at startup synchronization ready for more people
to try.
For now, it's a separate command. Once I'm sure that it seems to be
working
for people, I'll integrate it with the start-local-instance command.
To use startup synchronization, you need some minimal configuration
information
on the client. You can either use the create-local-instance command
if/when
it's working, or you can create the configuration information yourself
manually.
At a minimum, you need this information if you're creating it manually:
mkdir -p nodeagents/na1/agent/config
echo agent.das.host={das-host} >
nodeagents/na1/agent/config/das.properties
mkdir -p nodeagents/na1/in1
"na1" and "in1" are the node agent name and instance name.
They can be anything. {das-host} is the hostname of the
machine that will run the DAS (if not localhost).
The nodeagents directory can be anywhere. Normally it will be in the
top
level GlassFish directory next to the domains directory. If it's
somewhere else, you can use the --agentdir option to specify it.
With this in place, you can do the startup synchronization using:
asadmin _synchronize-instance
The optional operand is the instance name (if there's more than one).
Of course, you can get more details of what it's doing during the sync
by using AS_DEBUG=true.
Right now it synchronizes only the applications deployed to the
instance.
Since Hong just got --target working for the deploy command, that
should
do what's expected. For testing, you can tell it to synchronize all
applications to the instance, even if they're not needed, by using the
--syncallapps option.
Also, application synchronization uses the expanded application
directory
from the DAS. For performance testing there's a --syncarchive option
that
will cause it to use the original archive instead. The resulting
application
*might* work for a web app, but I definitely do not expect it to work
for
a Java EE app (ear file).
Please try it out and let me know what does and doesn't work for you.
I'm updating my wiki page to reflect the current implementation. You
can find details of the synchronization criteria here:
http://wiki.glassfish.java.net/Wiki.jsp?page=V3.1Clustering#section-V3.1Clustering-SynchronizationCriteria
As always, feedback is appreciated.
---------------------------------------------------------------------
To unsubscribe, e-mail: admin-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: admin-help@glassfish.dev.java.net
--
Byron Nevins - Oracle Corporation
Home: 650-359-1290
Cell: 650-784-4123
Sierra: 209-295-2188