Hi Kedar,Nandini Ektare,
Thanks for your replies in detail very much!
By means of your replies, I have known a lot.
Either in the remote mode or in the local mode,
Creating a Node Agent must rendezvous with DAS
due to the following code in the CreateNodeAgentCommand.java:
"String rendezvous = (String)props.getProperty(AgentConfig.
NODEAGENT_ATTEMPT_RENDEZVOUS, "true");"
When appearing an IOException which caused by the unreachable DAS,
Creating the NodeAgent will rendezvous locally.
Just as Nandini said, the fact that "Creating the NodeAgent will rendezvous
locally" is for Installer Team.
In the meanwhile, My requirement is that in the setup-cluster.xml, I plan to bind a
nodeagent staticlly, and then, I want to adjust the executing order between the "create-node-agent "
and "start-domain"; That is to say, firstly, I execute the "create-node-agent ",then execute the "start-domain"
at the same machine. Apparently, the DAS is stopped. According to the handling logic of CreateNodeAgentCommand.java,
Rendezvous locally will not happen because the value of "localRendezvous" is false.So, after I modified the default value of
"localRendezvous" to true , Rendezvous locally happened.
I think that modifying the default value of "localRendezvous" is not a good idea for me. Maybe this is the duty of the
Installer Team.
Finally, I need to thank for your replies very much!
> 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>
>
>