Nandini Ektare wrote:
> Hi Tang,
>
> Tang Yong wrote:
>> Hello KM,
>> Hello GF)Dev Teams,
>>
>> I have a problem related "rendezvousWithDAS" of NodeAgent.
>>
>> According to the content of "rendezvousWithDAS" method in
>> CreateNodeAgentCommand.java,
>> I found that If the created NodeAgent is at the same machine as the
>> DAS, the NodeAgenet will not
>> rendezvous with the local DAS until the nodeagent has been starting
>> up.However, if the NodeAgent
>> is at the remote machine and will be controlled by the central DAS,
>> the remote NodeAgent will rendezvous
>> with the central DAS when the remote NodeAgent is created.
>>
> I think you are referring to the code that has a specialized path for
> installer (localRendezvous for installer-created DAS and NA. Installer
> team would know better why they chose create a parallel for available
> api. The javadoc above the method does acknowledge the risk of this
> specific path.)
Are you sure this is the case? I hope installer logic does not affect
the user experience.
My belief is that create-node-agent "has to" rendezvous with DAS as long
as DAS is up when create-node-agent is run.
Thus, following two cases should be identical, no matter what:
case 1:
- DAS is installed on box A. It's started.
- Node-agent is "created" on box A. It's just created.
case 2:
- DAS is installed on box A. It's started.
- Node-agent is "created" on box B. It's just created.
In both the cases the node-agent's rendezvous-occurred property must
be "true".
Tang, if this is not the case, I'd be surprised.
>
> Other than that there is no segregation of response to local/remote DAS.
>> So, I am eager to want to know that why the remote NodeAgent needs
>> to rendezvous with the central DAS
>> when the remote NodeAgent is created? Why did not the process of
>> "rendezvous with the central DAS" put in the remote NodeAgent startup?
>>
>> In addition,I have some considerations about the problem:
>> 1 If when the remote NodeAgent is created, the remote NodeAgent will
>> not rendezvous with the central DAS,
>> then,the remote NodeAgent can still finish the action of rendezvous
>> during the nodeagent's startup.After all,the
>> central DAS's MBeanServer's ConnectionInfo can be aquried during the
>> nodeagent's startup.
One missing piece of information is that it is not necessary that DAS
is up when node-agent is created. This means the "rendezvous" and subsequent
"first sync" has to be done during the startup of the node-agent. There
is no other way. This is case of collapsed "rendezvous" and "first sync".
Note that several things can go wrong during this phase. There may be
a window of time where DAS does not recognize the node-agent you created.
But these are rare cases.
>>
>> 2 Whether or not the design is based on the performance of nodeagent
>> startup?
>>
>> 3 What differences (or advantage) are the two modes(rendezvous with
>> the central DAS in "creating phase " vs "starting phase")?
There is no advantage or disadvantage. It's just to take care of the
situation that DAS might not be running while node-agent is being
created!
If we were guaranteeing that DAS was always up when node-agent was
being created, the rendezvous would have ALWAYS occurred during the
create-node-agent phase. There was no need to defer it from create-node-agent
to start-node-agent.
What's more critical though is DAS is up when node-agent is started
"at least" for the first time. If that's not the case, node-agent will
fail to start up.
Regards,
Kedar Mhaswade
km_at_dev.java.net
>>
> Rendezvous is the process of handshake. Earlier the handshake, earlier
> the binding between nodeagent and DAS.
> So an attempt is made during nodeagent creation to check if DAS is
> running at the co-ords specified during create-node-agent and if so a
> handshake is attempted.
> It is ok if nodeagent cannot rendezvous at this point.
>
> Starting phase rendezvous is a must. Before starting (for the first
> time) NA has to know which DAS to sync from (it does not have its config
> without that)
> So this rendezvous is mandatory (if it has not happened before).
> Rendezvous does not happen twice. Sync happens n times.
>
> I wouldn't hint at performance improvement by pushing rendezvous during
> create (it's not a heavy operation unlike sync). It's an attempt to know
> bindings at the earliest chance (especially when there is no t much
> performance hit in doing so)
>
> Nandini
>> Could you please to help me solve the above problems?
>>
>> thanks very much!
>>
>> Best Regard!
>>
>>
>> ----------Mike.Tang
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>