ZK communication is little different from framework communication. In the former case, the ZK client library inside master opens up a connection to the ZK server ensemble. In the latter case, the scheduler driver inside the framework scheduler opens up a connection to the mesos master. But it is strange that marathon from a different remote host works fine but kafka-mesos from a different remote host has issues.
On Mon, Jun 6, 2016 at 3:12 PM, Justin Ryan <[email protected]> wrote: > inline > > On 6/6/16, 8:40 AM, "Vinod Kone" <[email protected]> wrote: > > >Have you tried running a different framework than the kafka one (maybe > marathon? or chronos?) to rule out framework related issues? I'm surprised > that it works when the scheduler and master are on the same host but not > when they are different. > > Looks like the request packets are getting dropped somewhere between the > master NIC and the application. > > > > Marathon is working just fine, I have flume running via Marathon and kafka > running via kafka-mesos. > > Yah, it does seem like the request packets are getting dropped, but that > makes no sense – how can the mesos-masters and zookeepers communicate with > each other, but an arbitrary other process can’t communicate with the > active mesos-master from another host which is a mesos-master? I’ve done a > lot of packet inspection and can do more, but overwhelmingly this seems to > anchor the notion that there is no firewall in play. > > ________________________________ > > P Please consider the environment before printing this e-mail > > The information in this electronic mail message is the sender's > confidential business and may be legally privileged. It is intended solely > for the addressee(s). Access to this internet electronic mail message by > anyone else is unauthorized. If you are not the intended recipient, any > disclosure, copying, distribution or any action taken or omitted to be > taken in reliance on it is prohibited and may be unlawful. The sender > believes that this E-mail and any attachments were free of any virus, worm, > Trojan horse, and/or malicious code when sent. This message and its > attachments could have been infected during transmission. By reading the > message and opening any attachments, the recipient accepts full > responsibility for taking protective and remedial action about viruses and > other defects. The sender's employer is not liable for any loss or damage > arising in any way. >
