You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@mesos.apache.org by Sam Taha <ta...@gmail.com> on 2013/10/09 19:28:26 UTC
Check status of Framework connection
>From java Framework, is their a way to to just ping the master to see if my
Scheduler/Driver is properly connected to mesos? None of the methods in the
SchedulerDriver look appropriate for just a simple round trip check if the
Framework is connected.
I need to do this in cases where I have declined ALL offers for a period of
time, so I am not getting anything back from mesos during this time, but I
still need to give the user feedback if the Framework is actually connected
or not.
Relying on Scheduler.registered() does not give current connection status,
since I may have connected hours ago and I may have declined offers, but I
still need to check if my Framework is connected.
Thanks,
Sam Taha
http://www.grandlogic.com
Re: Check status of Framework connection
Posted by Vinod Kone <vi...@gmail.com>.
Once the zk and master are back up, the scheduler driver automatically
discovers and re-registers with the master. The framework then would
automatically start receiving offers. Framework writers don't have to worry
about it!
On Fri, Oct 18, 2013 at 2:54 PM, Sam Taha <ta...@gmail.com> wrote:
> Thanks Vinod, that explains what I am seeing. On a related question. Let's
> say the master/zookeeper is down for a period of time and then restarted
> and my Framework is running during that time (and previously connected to
> mesos). Will the master try to reconnect with my Framework again on its own
> and I will start receiving offers? Or will I have to reconnect from my end
> by periodically checking if the master/zookeeper is back up again?
>
> Thanks,
> Sam Taha
>
> http://www.grandlogic.com
>
>
> On Fri, Oct 18, 2013 at 5:38 PM, Vinod Kone <vi...@gmail.com> wrote:
>
>> You are right. disconnected() callback is not called when you use a stand
>> alone master *without* zookeeper. This is an artifact of how the scheduler
>> driver works without zookeeper in the mix.
>>
>> That said, if you do use zookeeper the disconnected() callback should be
>> always called, even when the whole zk cluster is down or the master is down.
>>
>>
>> On Fri, Oct 18, 2013 at 2:22 PM, Sam Taha <ta...@gmail.com> wrote:
>>
>>> Note, I am not using Zookeeper in my test environment. I am just
>>> connecting to a single master node. Obviously with zookeeper there would be
>>> master failover if the primary went down, but there could be situations
>>> when the entire master/zookeeper cluster are down, so the scenario still
>>> applies I think. But I would think either way I should get a callback
>>> disconnect if the single master or master/zookeeper cluster are shutdown
>>> either manually or crash?
>>>
>>> Thanks,
>>> Sam Taha
>>>
>>> http://www.grandlogic.com
>>>
>>>
>>> On Fri, Oct 18, 2013 at 4:42 PM, Sam Taha <ta...@gmail.com> wrote:
>>>
>>>> When my Framework has connected to the master, I do not seem to get the
>>>> Scheduler.disconnected() callback when I kill the Master. Is this expected
>>>> behavior or should my Framework get a disconnected() callback if I kill the
>>>> master?
>>>>
>>>> Thanks,
>>>> Sam Taha
>>>>
>>>> http://www.grandlogic.com
>>>>
>>>>
>>>> On Wed, Oct 9, 2013 at 1:38 PM, Vinod Kone <vi...@gmail.com> wrote:
>>>>
>>>>> You should get a disconnected() callback when the master is
>>>>> disconnected.
>>>>>
>>>>>
>>>>> On Wed, Oct 9, 2013 at 10:28 AM, Sam Taha <ta...@gmail.com> wrote:
>>>>>
>>>>>> From java Framework, is their a way to to just ping the master to see
>>>>>> if my Scheduler/Driver is properly connected to mesos? None of the methods
>>>>>> in the SchedulerDriver look appropriate for just a simple round trip check
>>>>>> if the Framework is connected.
>>>>>>
>>>>>> I need to do this in cases where I have declined ALL offers for a
>>>>>> period of time, so I am not getting anything back from mesos during this
>>>>>> time, but I still need to give the user feedback if the Framework is
>>>>>> actually connected or not.
>>>>>>
>>>>>> Relying on Scheduler.registered() does not give current connection
>>>>>> status, since I may have connected hours ago and I may have declined
>>>>>> offers, but I still need to check if my Framework is connected.
>>>>>>
>>>>>> Thanks,
>>>>>> Sam Taha
>>>>>>
>>>>>> http://www.grandlogic.com
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: Check status of Framework connection
Posted by Sam Taha <ta...@gmail.com>.
Thanks Vinod, that explains what I am seeing. On a related question. Let's
say the master/zookeeper is down for a period of time and then restarted
and my Framework is running during that time (and previously connected to
mesos). Will the master try to reconnect with my Framework again on its own
and I will start receiving offers? Or will I have to reconnect from my end
by periodically checking if the master/zookeeper is back up again?
Thanks,
Sam Taha
http://www.grandlogic.com
On Fri, Oct 18, 2013 at 5:38 PM, Vinod Kone <vi...@gmail.com> wrote:
> You are right. disconnected() callback is not called when you use a stand
> alone master *without* zookeeper. This is an artifact of how the scheduler
> driver works without zookeeper in the mix.
>
> That said, if you do use zookeeper the disconnected() callback should be
> always called, even when the whole zk cluster is down or the master is down.
>
>
> On Fri, Oct 18, 2013 at 2:22 PM, Sam Taha <ta...@gmail.com> wrote:
>
>> Note, I am not using Zookeeper in my test environment. I am just
>> connecting to a single master node. Obviously with zookeeper there would be
>> master failover if the primary went down, but there could be situations
>> when the entire master/zookeeper cluster are down, so the scenario still
>> applies I think. But I would think either way I should get a callback
>> disconnect if the single master or master/zookeeper cluster are shutdown
>> either manually or crash?
>>
>> Thanks,
>> Sam Taha
>>
>> http://www.grandlogic.com
>>
>>
>> On Fri, Oct 18, 2013 at 4:42 PM, Sam Taha <ta...@gmail.com> wrote:
>>
>>> When my Framework has connected to the master, I do not seem to get the
>>> Scheduler.disconnected() callback when I kill the Master. Is this expected
>>> behavior or should my Framework get a disconnected() callback if I kill the
>>> master?
>>>
>>> Thanks,
>>> Sam Taha
>>>
>>> http://www.grandlogic.com
>>>
>>>
>>> On Wed, Oct 9, 2013 at 1:38 PM, Vinod Kone <vi...@gmail.com> wrote:
>>>
>>>> You should get a disconnected() callback when the master is
>>>> disconnected.
>>>>
>>>>
>>>> On Wed, Oct 9, 2013 at 10:28 AM, Sam Taha <ta...@gmail.com> wrote:
>>>>
>>>>> From java Framework, is their a way to to just ping the master to see
>>>>> if my Scheduler/Driver is properly connected to mesos? None of the methods
>>>>> in the SchedulerDriver look appropriate for just a simple round trip check
>>>>> if the Framework is connected.
>>>>>
>>>>> I need to do this in cases where I have declined ALL offers for a
>>>>> period of time, so I am not getting anything back from mesos during this
>>>>> time, but I still need to give the user feedback if the Framework is
>>>>> actually connected or not.
>>>>>
>>>>> Relying on Scheduler.registered() does not give current connection
>>>>> status, since I may have connected hours ago and I may have declined
>>>>> offers, but I still need to check if my Framework is connected.
>>>>>
>>>>> Thanks,
>>>>> Sam Taha
>>>>>
>>>>> http://www.grandlogic.com
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
Re: Check status of Framework connection
Posted by Vinod Kone <vi...@gmail.com>.
You are right. disconnected() callback is not called when you use a stand
alone master *without* zookeeper. This is an artifact of how the scheduler
driver works without zookeeper in the mix.
That said, if you do use zookeeper the disconnected() callback should be
always called, even when the whole zk cluster is down or the master is down.
On Fri, Oct 18, 2013 at 2:22 PM, Sam Taha <ta...@gmail.com> wrote:
> Note, I am not using Zookeeper in my test environment. I am just
> connecting to a single master node. Obviously with zookeeper there would be
> master failover if the primary went down, but there could be situations
> when the entire master/zookeeper cluster are down, so the scenario still
> applies I think. But I would think either way I should get a callback
> disconnect if the single master or master/zookeeper cluster are shutdown
> either manually or crash?
>
> Thanks,
> Sam Taha
>
> http://www.grandlogic.com
>
>
> On Fri, Oct 18, 2013 at 4:42 PM, Sam Taha <ta...@gmail.com> wrote:
>
>> When my Framework has connected to the master, I do not seem to get the
>> Scheduler.disconnected() callback when I kill the Master. Is this expected
>> behavior or should my Framework get a disconnected() callback if I kill the
>> master?
>>
>> Thanks,
>> Sam Taha
>>
>> http://www.grandlogic.com
>>
>>
>> On Wed, Oct 9, 2013 at 1:38 PM, Vinod Kone <vi...@gmail.com> wrote:
>>
>>> You should get a disconnected() callback when the master is disconnected.
>>>
>>>
>>> On Wed, Oct 9, 2013 at 10:28 AM, Sam Taha <ta...@gmail.com> wrote:
>>>
>>>> From java Framework, is their a way to to just ping the master to see
>>>> if my Scheduler/Driver is properly connected to mesos? None of the methods
>>>> in the SchedulerDriver look appropriate for just a simple round trip check
>>>> if the Framework is connected.
>>>>
>>>> I need to do this in cases where I have declined ALL offers for a
>>>> period of time, so I am not getting anything back from mesos during this
>>>> time, but I still need to give the user feedback if the Framework is
>>>> actually connected or not.
>>>>
>>>> Relying on Scheduler.registered() does not give current connection
>>>> status, since I may have connected hours ago and I may have declined
>>>> offers, but I still need to check if my Framework is connected.
>>>>
>>>> Thanks,
>>>> Sam Taha
>>>>
>>>> http://www.grandlogic.com
>>>>
>>>>
>>>>
>>>
>>
>
Re: Check status of Framework connection
Posted by Sam Taha <ta...@gmail.com>.
Note, I am not using Zookeeper in my test environment. I am just connecting
to a single master node. Obviously with zookeeper there would be master
failover if the primary went down, but there could be situations when the
entire master/zookeeper cluster are down, so the scenario still applies I
think. But I would think either way I should get a callback disconnect if
the single master or master/zookeeper cluster are shutdown either manually
or crash?
Thanks,
Sam Taha
http://www.grandlogic.com
On Fri, Oct 18, 2013 at 4:42 PM, Sam Taha <ta...@gmail.com> wrote:
> When my Framework has connected to the master, I do not seem to get the
> Scheduler.disconnected() callback when I kill the Master. Is this expected
> behavior or should my Framework get a disconnected() callback if I kill the
> master?
>
> Thanks,
> Sam Taha
>
> http://www.grandlogic.com
>
>
> On Wed, Oct 9, 2013 at 1:38 PM, Vinod Kone <vi...@gmail.com> wrote:
>
>> You should get a disconnected() callback when the master is disconnected.
>>
>>
>> On Wed, Oct 9, 2013 at 10:28 AM, Sam Taha <ta...@gmail.com> wrote:
>>
>>> From java Framework, is their a way to to just ping the master to see if
>>> my Scheduler/Driver is properly connected to mesos? None of the methods in
>>> the SchedulerDriver look appropriate for just a simple round trip check if
>>> the Framework is connected.
>>>
>>> I need to do this in cases where I have declined ALL offers for a period
>>> of time, so I am not getting anything back from mesos during this time, but
>>> I still need to give the user feedback if the Framework is actually
>>> connected or not.
>>>
>>> Relying on Scheduler.registered() does not give current connection
>>> status, since I may have connected hours ago and I may have declined
>>> offers, but I still need to check if my Framework is connected.
>>>
>>> Thanks,
>>> Sam Taha
>>>
>>> http://www.grandlogic.com
>>>
>>>
>>>
>>
>
Re: Check status of Framework connection
Posted by Sam Taha <ta...@gmail.com>.
When my Framework has connected to the master, I do not seem to get the
Scheduler.disconnected() callback when I kill the Master. Is this expected
behavior or should my Framework get a disconnected() callback if I kill the
master?
Thanks,
Sam Taha
http://www.grandlogic.com
On Wed, Oct 9, 2013 at 1:38 PM, Vinod Kone <vi...@gmail.com> wrote:
> You should get a disconnected() callback when the master is disconnected.
>
>
> On Wed, Oct 9, 2013 at 10:28 AM, Sam Taha <ta...@gmail.com> wrote:
>
>> From java Framework, is their a way to to just ping the master to see if
>> my Scheduler/Driver is properly connected to mesos? None of the methods in
>> the SchedulerDriver look appropriate for just a simple round trip check if
>> the Framework is connected.
>>
>> I need to do this in cases where I have declined ALL offers for a period
>> of time, so I am not getting anything back from mesos during this time, but
>> I still need to give the user feedback if the Framework is actually
>> connected or not.
>>
>> Relying on Scheduler.registered() does not give current connection
>> status, since I may have connected hours ago and I may have declined
>> offers, but I still need to check if my Framework is connected.
>>
>> Thanks,
>> Sam Taha
>>
>> http://www.grandlogic.com
>>
>>
>>
>
Re: Check status of Framework connection
Posted by Vinod Kone <vi...@gmail.com>.
You should get a disconnected() callback when the master is disconnected.
On Wed, Oct 9, 2013 at 10:28 AM, Sam Taha <ta...@gmail.com> wrote:
> From java Framework, is their a way to to just ping the master to see if
> my Scheduler/Driver is properly connected to mesos? None of the methods in
> the SchedulerDriver look appropriate for just a simple round trip check if
> the Framework is connected.
>
> I need to do this in cases where I have declined ALL offers for a period
> of time, so I am not getting anything back from mesos during this time, but
> I still need to give the user feedback if the Framework is actually
> connected or not.
>
> Relying on Scheduler.registered() does not give current connection status,
> since I may have connected hours ago and I may have declined offers, but I
> still need to check if my Framework is connected.
>
> Thanks,
> Sam Taha
>
> http://www.grandlogic.com
>
>
>