Re: Tunneling over SSH

Speaking of Proxy... there's a Thrift Proxy that would accommodate a single port connection to do all client operations if hosted on the subnet. Bonus: you can use any thrift-supported language. Without the proxy, however, the data model (inherent to the BigTable design) is that the client can re

Re: Tunneling over SSH

The easiest solution may be to set up a VPN, though. -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Thu, Sep 5, 2013 at 10:36 PM, Christopher wrote: > You're right that ZK is instructing the client to talk directly to > 192.168.182.22:9997 (tablet server). As Mike suggested, this cou

Re: Tunneling over SSH

You're right that ZK is instructing the client to talk directly to 192.168.182.22:9997 (tablet server). As Mike suggested, this could be resolved if we stored hostnames rather than IPs, and you had hostnames mapped to the external IP, and ports forwarded over SSH. A more robust solution would be t

Re: Tunneling over SSH

There is some development going on as part of ACCUMULO-1585[1] to allow tservers to store the hostname instead of the ip address. That seems like a good place to start, although I'm not sure if this is the same problem that you're seeing. [1]: h

Tunneling over SSH

I'm trying to tunnel via SSH to a single Hadoop,Zoo, Accumulo stand-alone installation. The internal IP of the machine is on a local subnet behind a SSH-only firewall - 192.168.182.22.. I use static host names in all of the config files (Accumulo, Zoo, Hadoop) that resolve to 192.168.182.22 for all

Re: Table state from the Accumulo Shell?

Not that I know of; please open a ticket to allow clients to get this information. On Wed, Sep 4, 2013 at 9:10 AM, Aaron wrote: > Is there a way to get Table state from the Shell? Offline? Cloning..? > etc? > > I see you can get the config properties for the table..but, i didn't see > any st

Re: [External] Re: locked fate threads

stop-all probably won't work. I'm suggesting a cluster-wide kill of all tablet servers: $ pssh -h conf/slaves pkill -f =tserve[r] # <--- requires parallel ssh to be installed On the master host: $ pkill -f =master Wait for the master lock to expire (typically 30 seconds), and kill all the fa

RE: [External] Re: locked fate threads

Thanks for the quick response. I issued the command to take those offline, however, they were locked up due to the other threads so it didn't take. How do I go about deleting those fate transactions? Fate delete and fate fail do not work from the shell. Are you suggesting a stop-all of accum

Re: locked fate threads

I can't believe I posted a note about using deletemany on the !METADATA table! That was pretty reckless of me. If you really deleted your table data doing this, and your table was online at the time, you need to restart your cluster. That alone might fix the problem. Otherwise, you are going to

locked fate threads

I recently tried to remove some tables, during which I was getting a shell thread stuck on IO error. A fate print plus some digging into the logs revealed they were stuck waiting on WAL resources. I found a thread in which Eric Newton explained how to manually remove the tables removing lines