Just some general points on synchronization.
If the node agent is configured to automatically start the instances it
controls when it itself is started, then those instances don't sync with
the DAS and their local repository caches remain unchanged.
The instances should only sync with the DAS - more accurately the Node
Agent fires off a separate process prior to starting the instance that
is going to need sync'ing prior to starting the instance - and its that
process that talks to the DAS.
Differences in system clocks on the DAS and NA machines can cause odd
sync behaviour (there are hidden timestamp files in the areas that get
sync'd (.com_sun_appserv_timestamp) that record the time of the last
sync - these are sent to the DAS so it can figure out what's new in its
master repository which is why having clocks in sync is important).
Stopping/Starting the instances explicitly, e.g. asadmin
stop-instance/start-instance or asadmin stop-cluster/start-cluster (as
the last time I looked it just did stop/start to each instance) will
make them sync.
You can also change the behaviour of the node agent with the
--syncinstances flag, so asadmin start-node-agent --syncinstances=true.
Finding, and deleting all the .com_sun_appserv_timestamp files from an
instance and then stopping and restarting the instance will force it to
resync everything with the DAS.
Might be worth creating a standalone instance on the NA on the DAS box
(if there is still one) using the same config as the other instances and
see when its started whether its configuration matches expectations.
The domain.xml files should be identifical. Making local changes to the
instances always runs the risk of them being overwritten sometime in the
future when a sync does occur.
Regards,
Steve
Brian Repko wrote:
> We've tried stop/starting the NA (in order to get it to sync) and we still get
> the same issue.
>
> Does it matter if the Node Agent domain.xml is in sync or not?
>
> We are not sure what to do at this point - clearly rebooting doesn't work for
> us. We cannot get a JMS connection factory out of this adapter anymore because
> GF is not managing this pool properly.
>
> Brian
>
>
> ----- Original message -----
> From: "Brian Repko" <brianrepko_at_fastmail.us>
> To: users_at_glassfish.dev.java.net
> Date: Thu, 15 Jan 2009 15:31:19 -0600
> Subject: Re: NPEs during PoolManagerImpl.getResourceFromPool with Connector Connection Pools
>
>
> ZIP of the domain.xmls (DAS, one NA and one SI) and the logs from SI1 and SI2 are attached.
>
> What we noticed is that our NA domain.xml is drastically out of sync with the SI and DAS
>
>
> We are concerned that the instances are syncing or using the NA as a proxy for the DAS
> (das is rebooting) and that causes them to go delete the pools.
>
> At this point restarting things isn't working so if there is a way to shutdown and startup
> that you think we should try, I'd LOVE to hear it.
>
> Thanks,
> Brian
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
>