Return-Path: X-Original-To: apmail-accumulo-user-archive@www.apache.org Delivered-To: apmail-accumulo-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 8CE3610764 for ; Fri, 13 Feb 2015 20:32:57 +0000 (UTC) Received: (qmail 30308 invoked by uid 500); 13 Feb 2015 20:32:57 -0000 Delivered-To: apmail-accumulo-user-archive@accumulo.apache.org Received: (qmail 30256 invoked by uid 500); 13 Feb 2015 20:32:57 -0000 Mailing-List: contact user-help@accumulo.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@accumulo.apache.org Delivered-To: mailing list user@accumulo.apache.org Received: (qmail 30246 invoked by uid 99); 13 Feb 2015 20:32:57 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 13 Feb 2015 20:32:57 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS,WEIRD_PORT X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of patterd@gmail.com designates 209.85.217.182 as permitted sender) Received: from [209.85.217.182] (HELO mail-lb0-f182.google.com) (209.85.217.182) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 13 Feb 2015 20:32:31 +0000 Received: by mail-lb0-f182.google.com with SMTP id f15so16845764lbj.13 for ; Fri, 13 Feb 2015 12:31:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=Mm/8A2iJfJVH8ppJvYWXEas4uxKm840wYG0f2qe4uCw=; b=v8hQJjYln0HEs8w+xzd3EFWY+hs1zF/IwCImesnUBPzq2IRzRqpBM625MBHaDu3FrO 6D2y8hqV8SWa8JP6MuaxgjbBaxpY27x0/aJ5rOVeIqHx5Upw9fJg6YBASaRMUtDZz9cf 8k30QsAXTeJ2kj5S4G2gaEk3/26ZkW2QM8T9mELcZsS0/BtbV8tMAcMMvl6PgFWBH6VO X8U6I0CRNXT6dnK+YTSK4qE7+Zf/p6Urus3WHvXhwOu6FfaTyKeZARHttWNhpiM6S2YK lKj7HfQz1xc9q9O9ufUeEWb0wLtnL6Qskg0apj1N9BPdcD+Omho+FSYBEplAmtmBVfEM qpDQ== MIME-Version: 1.0 X-Received: by 10.112.243.12 with SMTP id wu12mr9810090lbc.91.1423859504924; Fri, 13 Feb 2015 12:31:44 -0800 (PST) Received: by 10.112.142.195 with HTTP; Fri, 13 Feb 2015 12:31:44 -0800 (PST) In-Reply-To: References: Date: Fri, 13 Feb 2015 15:31:44 -0500 Message-ID: Subject: Re: Trying to cross a machine boundary From: David Patterson To: user@accumulo.apache.org, vines@apache.org Content-Type: multipart/alternative; boundary=001a1133ac52004b96050efe20fd X-Virus-Checked: Checked by ClamAV on apache.org --001a1133ac52004b96050efe20fd Content-Type: text/plain; charset=UTF-8 John, thanks for your answer. I decided to bite the bullet and now build a jar on my windows machine and ship it to the linux machine to execute. It works. Sorry I did not get back to you before now. Dave On Wed, Feb 4, 2015 at 10:04 AM, John Vines wrote: > In your cluster, define your machines by the public ip address or a name > that resolves to that address. Then restart. > > I'm willing to bet your slaves file and such says localhost which will > cause the machines to register as localhost instead of the public ip > address. > > Sent from my phone, please pardon the typos and brevity. > On Feb 4, 2015 9:41 AM, "David Patterson" wrote: > >> I have some java code that works fine when it is running on the same >> (cloud-Ubuntu) machine as a small testbed of data. >> >> If I run the exact same code on a Windows machine it hangs up after the >> following warning: >> >> INFO : Initiating client connection, connectString=10.14.6.104:2181 >> sessionTimeout=30000 >> watcher=org.apache.accumulo.fate.zookeeper.ZooSession$ZooWatcher@1bb75db9 >> INFO : Opening socket connection to server 10.14.6.104/10.14.6.104:2181. >> Will not attempt to authenticate using SASL (unknown error) >> INFO : Socket connection established to 10.14.6.104/10.14.6.104:2181, >> initiating session >> INFO : Session establishment complete on server >> 10.14.6.104/10.14.6.104:2181, sessionid = 0x14b284b3736008e, negotiated >> timeout = 30000 >> WARN : Failed to find an available server in the list of servers: >> [localhost:9997 (120000)] >> >> I'm guessing it has to do with some aspect of the security handshake not >> being implemented and having that matter a lot when trying to process a >> request from a "remote" source. >> >> I have been unsuccessful in finding what is needed and how to fix it. >> >> Any pointers will be appreciated. >> >> Dave P >> >> > --001a1133ac52004b96050efe20fd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
John, thanks for your answer. I decided to bite the bullet= and now build a jar on my windows machine and ship it to the linux machine= to execute. It works.

Sorry I did not get back to you before now.
Dave

On Wed, Feb 4, 2015 at 10:04 AM, John Vines <vines@apache.org> wrote:

In your clust= er, define your machines by the public ip address or a name that resolves t= o that address. Then restart.

I'm willing to bet your slaves file and such says localh= ost which will cause the machines to register as localhost instead of the p= ublic ip address.

Sent from my phone, please pardon the typos and brevity.

=
On Feb 4, 2015 9:41 AM, "David Patterson&qu= ot; <patterd@gmai= l.com> wrote:
I have some java code that works fine when it i= s running on the same (cloud-Ubuntu) machine as a small testbed of data.
If I run the exact same code on a Windows machine it hangs up after th= e following warning:

INFO : Initiating client connection, connectStr= ing=3D10.14.6.104:218= 1 sessionTimeout=3D30000 watcher=3Dorg.apache.accumulo.fate.zookeeper.Z= ooSession$ZooWatcher@1bb75db9
INFO : Opening socket connection to server= 10.14.6.= 104/10.14.6.104:2181. Will not attempt to authenticate using SASL (unkn= own error)
INFO : Socket connection established to 10.14.6.104/10.14.6.104:2181, initiating session
INFO : Session establishment complete on server <= a href=3D"http://10.14.6.104/10.14.6.104:2181" target=3D"_blank">10.14.6.10= 4/10.14.6.104:2181
, sessionid =3D 0x14b284b3736008e, negotiated timeout= =3D 30000
WARN : Failed to find an available server in the list of serv= ers: [localhost:9997 (120000)]

I'm guessing it has to do w= ith some aspect of the security handshake not being implemented and having = that matter a lot when trying to process a request from a "remote"= ; source.

I have been unsuccessful in finding what is needed a= nd how to fix it.

Any pointers will be appreciated.

Dave P
=C2=A0

--001a1133ac52004b96050efe20fd--