Re: Connecting to standalone HBase from a remote client
Hello, I am new to HBase and have a background in C. Please help as I am facing this problem from last one day. I have installed HBase on Linux Machine(192.168.113.27). I have created the users table on HBase. Then I have wriiten the code in Eclipse IDE on my Local Machine to communicate with HBase to store some data in HBase. Code witten is Configuration conf = HBaseConfiguration.create(); conf.set(hbase.zookeeper.quorum, 192.168.113.27); conf.set(hbase.zookeeper.property.clientPort,2181); HTableInterface usersTable = new HTable(conf, users); As per my recent knowledge which I have gained till now for last 4 days is the sample Application communicates with Zookeeper. The connection will be perfectly fine with zookeeper but after that I have getting org.apache.hadoop.hbase.client.NoServerForRegionException: Unable to find region for users,,99 after 10 tries. after that. I have also removed the localhost from the regionservers file and put 192.168.113.27 in that file. Logs are shown below: . 13/02/06 14:37:39 INFO zookeeper.ZooKeeper: Client environment:zookeeper.version=3.4.5-1392090, built on 09/30/2012 17:52 GMT 13/02/06 14:37:39 INFO zookeeper.ZooKeeper: Client environment:host.name=DWUS1B045.hsc.com 13/02/06 14:37:39 INFO zookeeper.ZooKeeper: Client environment:java.version=1.6.0_39 13/02/06 14:37:39 INFO zookeeper.ZooKeeper: Client environment:java.vendor=Sun Microsystems Inc. 13/02/06 14:37:39 INFO zookeeper.ZooKeeper: Client environment:java.home=C:\Program Files\Java\jre6 13/02/06 14:37:39 INFO zookeeper.ZooKeeper: Client environment:java.class.path=C:\Documents and Settings\ggne0509\workspace1\Hbase\bin;C:\HBase\hbase-0.94.4\lib\asm-3.1.jar;C:\HBase\hbase-0.94.4\lib\avro-1.5.3.jar;C:\HBase\hbase-0.94.4\lib\avro-ipc-1.5.3.jar;C:\HBase\hbase-0.94.4\lib\commons-beanutils-1.7.0.jar;C:\HBase\hbase-0.94.4\lib\commons-beanutils-core-1.8.0.jar;C:\HBase\hbase-0.94.4\lib\commons-cli-1.2.jar;C:\HBase\hbase-0.94.4\lib\commons-codec-1.4.jar;C:\HBase\hbase-0.94.4\lib\commons-collections-3.2.1.jar;C:\HBase\hbase-0.94.4\lib\commons-configuration-1.6.jar;C:\HBase\hbase-0.94.4\lib\commons-digester-1.8.jar;C:\HBase\hbase-0.94.4\lib\commons-el-1.0.jar;C:\HBase\hbase-0.94.4\lib\commons-httpclient-3.1.jar;C:\HBase\hbase-0.94.4\lib\commons-io-2.1.jar;C:\HBase\hbase-0.94.4\lib\commons-lang-2.5.jar;C:\HBase\hbase-0.94.4\lib\commons-logging-1.1.1.jar;C:\HBase\hbase-0.94.4\lib\commons-math-2.1.jar;C:\HBase\hbase-0.94.4\lib\commons-net-1.4.1.jar;C:\HBase\hbase-0.94.4\lib\core-3.1.1.jar;C:\HBase\hbase-0.94.4\lib\guava-11.0.2.jar;C:\HBase\hbase-0.94.4\lib\hadoop-core-1.0.4.jar;C:\HBase\hbase-0.94.4\lib\high-scale-lib-1.1.1.jar;C:\HBase\hbase-0.94.4\lib\httpclient-4.1.2.jar;C:\HBase\hbase-0.94.4\lib\httpcore-4.1.3.jar;C:\HBase\hbase-0.94.4\lib\jackson-core-asl-1.8.8.jar;C:\HBase\hbase-0.94.4\lib\jackson-jaxrs-1.8.8.jar;C:\HBase\hbase-0.94.4\lib\jackson-mapper-asl-1.8.8.jar;C:\HBase\hbase-0.94.4\lib\jackson-xc-1.8.8.jar;C:\HBase\hbase-0.94.4\lib\jamon-runtime-2.3.1.jar;C:\HBase\hbase-0.94.4\lib\jasper-compiler-5.5.23.jar;C:\HBase\hbase-0.94.4\lib\jasper-runtime-5.5.23.jar;C:\HBase\hbase-0.94.4\lib\jaxb-api-2.1.jar;C:\HBase\hbase-0.94.4\lib\jaxb-impl-2.2.3-1.jar;C:\HBase\hbase-0.94.4\lib\jersey-core-1.8.jar;C:\HBase\hbase-0.94.4\lib\jersey-json-1.8.jar;C:\HBase\hbase-0.94.4\lib\jersey-server-1.8.jar;C:\HBase\hbase-0.94.4\lib\jettison-1.1.jar;C:\HBase\hbase-0.94.4\lib\jetty-6.1.26.jar;C:\HBase\hbase-0.94.4\lib\jetty-util-6.1.26.jar;C:\HBase\hbase-0.94.4\lib\jruby-complete-1.6.5.jar;C:\HBase\hbase-0.94.4\lib\jsp-2.1-6.1.14.jar;C:\HBase\hbase-0.94.4\lib\jsp-api-2.1-6.1.14.jar;C:\HBase\hbase-0.94.4\lib\jsr305-1.3.9.jar;C:\HBase\hbase-0.94.4\lib\junit-4.10-HBASE-1.jar;C:\HBase\hbase-0.94.4\lib\libthrift-0.8.0.jar;C:\HBase\hbase-0.94.4\lib\log4j-1.2.16.jar;C:\HBase\hbase-0.94.4\lib\metrics-core-2.1.2.jar;C:\HBase\hbase-0.94.4\lib\netty-3.2.4.Final.jar;C:\HBase\hbase-0.94.4\lib\protobuf-java-2.4.0a.jar;C:\HBase\hbase-0.94.4\lib\servlet-api-2.5-6.1.14.jar;C:\HBase\hbase-0.94.4\lib\slf4j-api-1.4.3.jar;C:\HBase\hbase-0.94.4\lib\slf4j-log4j12-1.4.3.jar;C:\HBase\hbase-0.94.4\lib\snappy-java-1.0.3.2.jar;C:\HBase\hbase-0.94.4\lib\stax-api-1.0.1.jar;C:\HBase\hbase-0.94.4\lib\velocity-1.7.jar;C:\HBase\hbase-0.94.4\lib\xmlenc-0.52.jar;C:\HBase\hbase-0.94.4\lib\zookeeper-3.4.5.jar;C:\Documents and Settings\ggne0509\workspace1\Hbase\lib\hbase-0.94.4.jar 13/02/06 14:37:39 INFO zookeeper.ZooKeeper: Client environment:java.library.path=C:\Program Files\Java\jre6\bin;C:\WINDOWS\Sun\Java\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\Program Files\Java\jre6\bin\client;C:\Program Files\Java\jre6\bin;C:\TimesTen\TT1121~1\bin;C:\TimesTen\TT1121~1\ttoracle_home\instantclient_11_1;C:\XEClient\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Program Files\TortoiseSVN\bin;C:\jacorb-2.3.1\bin;C:\Program Files\Rational\common;C:\Program Files\Rational\ClearCase\bin;C:\Program
Re: Connecting to standalone HBase from a remote client
Hi, Do you have 127.0.0.1 localhost in our host file? If not, can you add it and retry? You also need to have your IP documented pointing to you host name. 2013/2/6, rajivtyagi711 rajivtyagi...@gmail.com: Hello, I am new to HBase and have a background in C. Please help as I am facing this problem from last one day. I have installed HBase on Linux Machine(192.168.113.27). I have created the users table on HBase. Then I have wriiten the code in Eclipse IDE on my Local Machine to communicate with HBase to store some data in HBase. Code witten is Configuration conf = HBaseConfiguration.create(); conf.set(hbase.zookeeper.quorum, 192.168.113.27); conf.set(hbase.zookeeper.property.clientPort,2181); HTableInterface usersTable = new HTable(conf, users); As per my recent knowledge which I have gained till now for last 4 days is the sample Application communicates with Zookeeper. The connection will be perfectly fine with zookeeper but after that I have getting org.apache.hadoop.hbase.client.NoServerForRegionException: Unable to find region for users,,99 after 10 tries. after that. I have also removed the localhost from the regionservers file and put 192.168.113.27 in that file. Logs are shown below: . 13/02/06 14:37:39 INFO zookeeper.ZooKeeper: Client environment:zookeeper.version=3.4.5-1392090, built on 09/30/2012 17:52 GMT 13/02/06 14:37:39 INFO zookeeper.ZooKeeper: Client environment:host.name=DWUS1B045.hsc.com 13/02/06 14:37:39 INFO zookeeper.ZooKeeper: Client environment:java.version=1.6.0_39 13/02/06 14:37:39 INFO zookeeper.ZooKeeper: Client environment:java.vendor=Sun Microsystems Inc. 13/02/06 14:37:39 INFO zookeeper.ZooKeeper: Client environment:java.home=C:\Program Files\Java\jre6 13/02/06 14:37:39 INFO zookeeper.ZooKeeper: Client environment:java.class.path=C:\Documents and Settings\ggne0509\workspace1\Hbase\bin;C:\HBase\hbase-0.94.4\lib\asm-3.1.jar;C:\HBase\hbase-0.94.4\lib\avro-1.5.3.jar;C:\HBase\hbase-0.94.4\lib\avro-ipc-1.5.3.jar;C:\HBase\hbase-0.94.4\lib\commons-beanutils-1.7.0.jar;C:\HBase\hbase-0.94.4\lib\commons-beanutils-core-1.8.0.jar;C:\HBase\hbase-0.94.4\lib\commons-cli-1.2.jar;C:\HBase\hbase-0.94.4\lib\commons-codec-1.4.jar;C:\HBase\hbase-0.94.4\lib\commons-collections-3.2.1.jar;C:\HBase\hbase-0.94.4\lib\commons-configuration-1.6.jar;C:\HBase\hbase-0.94.4\lib\commons-digester-1.8.jar;C:\HBase\hbase-0.94.4\lib\commons-el-1.0.jar;C:\HBase\hbase-0.94.4\lib\commons-httpclient-3.1.jar;C:\HBase\hbase-0.94.4\lib\commons-io-2.1.jar;C:\HBase\hbase-0.94.4\lib\commons-lang-2.5.jar;C:\HBase\hbase-0.94.4\lib\commons-logging-1.1.1.jar;C:\HBase\hbase-0.94.4\lib\commons-math-2.1.jar;C:\HBase\hbase-0.94.4\lib\commons-net-1.4.1.jar;C:\HBase\hbase-0.94.4\lib\core-3.1.1.jar;C:\HBase\hbase-0.94.4\lib\guava-11.0.2.jar;C:\HBase\hbase-0.94.4\lib\hadoop-core-1.0.4.jar;C:\HBase\hbase-0.94.4\lib\high-scale-lib-1.1.1.jar;C:\HBase\hbase-0.94.4\lib\httpclient-4.1.2.jar;C:\HBase\hbase-0.94.4\lib\httpcore-4.1.3.jar;C:\HBase\hbase-0.94.4\lib\jackson-core-asl-1.8.8.jar;C:\HBase\hbase-0.94.4\lib\jackson-jaxrs-1.8.8.jar;C:\HBase\hbase-0.94.4\lib\jackson-mapper-asl-1.8.8.jar;C:\HBase\hbase-0.94.4\lib\jackson-xc-1.8.8.jar;C:\HBase\hbase-0.94.4\lib\jamon-runtime-2.3.1.jar;C:\HBase\hbase-0.94.4\lib\jasper-compiler-5.5.23.jar;C:\HBase\hbase-0.94.4\lib\jasper-runtime-5.5.23.jar;C:\HBase\hbase-0.94.4\lib\jaxb-api-2.1.jar;C:\HBase\hbase-0.94.4\lib\jaxb-impl-2.2.3-1.jar;C:\HBase\hbase-0.94.4\lib\jersey-core-1.8.jar;C:\HBase\hbase-0.94.4\lib\jersey-json-1.8.jar;C:\HBase\hbase-0.94.4\lib\jersey-server-1.8.jar;C:\HBase\hbase-0.94.4\lib\jettison-1.1.jar;C:\HBase\hbase-0.94.4\lib\jetty-6.1.26.jar;C:\HBase\hbase-0.94.4\lib\jetty-util-6.1.26.jar;C:\HBase\hbase-0.94.4\lib\jruby-complete-1.6.5.jar;C:\HBase\hbase-0.94.4\lib\jsp-2.1-6.1.14.jar;C:\HBase\hbase-0.94.4\lib\jsp-api-2.1-6.1.14.jar;C:\HBase\hbase-0.94.4\lib\jsr305-1.3.9.jar;C:\HBase\hbase-0.94.4\lib\junit-4.10-HBASE-1.jar;C:\HBase\hbase-0.94.4\lib\libthrift-0.8.0.jar;C:\HBase\hbase-0.94.4\lib\log4j-1.2.16.jar;C:\HBase\hbase-0.94.4\lib\metrics-core-2.1.2.jar;C:\HBase\hbase-0.94.4\lib\netty-3.2.4.Final.jar;C:\HBase\hbase-0.94.4\lib\protobuf-java-2.4.0a.jar;C:\HBase\hbase-0.94.4\lib\servlet-api-2.5-6.1.14.jar;C:\HBase\hbase-0.94.4\lib\slf4j-api-1.4.3.jar;C:\HBase\hbase-0.94.4\lib\slf4j-log4j12-1.4.3.jar;C:\HBase\hbase-0.94.4\lib\snappy-java-1.0.3.2.jar;C:\HBase\hbase-0.94.4\lib\stax-api-1.0.1.jar;C:\HBase\hbase-0.94.4\lib\velocity-1.7.jar;C:\HBase\hbase-0.94.4\lib\xmlenc-0.52.jar;C:\HBase\hbase-0.94.4\lib\zookeeper-3.4.5.jar;C:\Documents and Settings\ggne0509\workspace1\Hbase\lib\hbase-0.94.4.jar 13/02/06 14:37:39 INFO zookeeper.ZooKeeper: Client environment:java.library.path=C:\Program Files\Java\jre6\bin;C:\WINDOWS\Sun\Java\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\Program Files\Java\jre6\bin\client;C:\Program
Re: Connecting to standalone HBase from a remote client
Thanks guys, Excuse my ignorance, but having sort of agreed that the configuration that determines which server should be contacted for what is on the HBase server, I am not sure how any of the practical suggestions made should solve the issue, and enable connecting from a remote client. Let me explain - setting /etc/hosts on my client side seems in this regard not relevant in that view. And the other suggestion for hbase-site.xml configuration I have already got covered as my client code successfully connects to zookeeper (the configuration properties mentioned on this thread are zookeeper specific, I don't directly see how they should solve the problem). On Mon, Nov 26, 2012 at 10:15 PM, Tariq [via Apache HBase] ml-node+s679495n4034419...@n3.nabble.com wrote: Hello Nicolas, You are right. It has been deprecated. Thank you for updating my knowledge base..:) Regards, Mohammad Tariq On Tue, Nov 27, 2012 at 12:17 AM, Nicolas Liochon [hidden email]http://user/SendEmail.jtp?type=nodenode=4034419i=0 wrote: Hi Mohammad, Your answer was right, just that specifying the master address is not necessary (anymore I think). But it does no harm. Changing the /etc/hosts (as you did) is right too. Lastly, if the cluster is standalone and accessed locally, having localhost in ZK will not be an issue. However, it's perfectly possible to have a standalone cluster accessed remotely, so you don't want to have the master to write I'm on the server named localhost in this case. I expect it won't be an issue for communications between the region servers or hdfs as they would be all on the same localhost... Cheers, Nicolas On Mon, Nov 26, 2012 at 7:16 PM, Mohammad Tariq [hidden email]http://user/SendEmail.jtp?type=nodenode=4034419i=1 wrote: what -- If you reply to this email, your message will be added to the discussion below: http://apache-hbase.679495.n3.nabble.com/Connecting-to-standalone-HBase-from-a-remote-client-tp4034362p4034419.html To unsubscribe from Connecting to standalone HBase from a remote client, click herehttp://apache-hbase.679495.n3.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_codenode=4034362code=bWF0YW5AY2xvdWRhbG9lLm9yZ3w0MDM0MzYyfC0xMDg3NTk1Njc3 . NAMLhttp://apache-hbase.679495.n3.nabble.com/template/NamlServlet.jtp?macro=macro_viewerid=instant_html%21nabble%3Aemail.namlbase=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespacebreadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml -- View this message in context: http://apache-hbase.679495.n3.nabble.com/Connecting-to-standalone-HBase-from-a-remote-client-tp4034362p4034438.html Sent from the HBase User mailing list archive at Nabble.com.
Re: Connecting to standalone HBase from a remote client
Thanks guys, Excuse my ignorance, but having sort of agreed that the configuration that determines which-server-should-be-contacted-for-what is on the HBase server, I am not sure how any of the practical suggestions made should solve the issue, and enable connecting from a remote client. Let me delineate - setting /etc/hosts on my client side seems in this regard not relevant in that view. And the other suggestion for hbase-site.xml configuration I have already got covered, as my client code successfully connects to zookeeper (the configuration properties mentioned on this thread are zookeeper specific according to my interpretation of documentation, I don't directly see how they should solve the problem). Perhaps Mohammad you can explain why those zookeeper properties relate to how the master references itself towards zookeeper? Should I take it from St.Ack that there is currently no way to specify the master's remotely accessible server/ip in the HBase configuration? Anyway, my HBase server's /etc/hosts has just one line now, in case it got lost on the thread - 127.0.0.1 localhost 'server-name'. Everything works fine on the HBase server itself, the same client code runs perfectly there. Thanks again, Matan On Mon, Nov 26, 2012 at 10:15 PM, Tariq [via Apache HBase] ml-node+s679495n4034419...@n3.nabble.com wrote: Hello Nicolas, You are right. It has been deprecated. Thank you for updating my knowledge base..:) Regards, Mohammad Tariq On Tue, Nov 27, 2012 at 12:17 AM, Nicolas Liochon [hidden email]http://user/SendEmail.jtp?type=nodenode=4034419i=0 wrote: Hi Mohammad, Your answer was right, just that specifying the master address is not necessary (anymore I think). But it does no harm. Changing the /etc/hosts (as you did) is right too. Lastly, if the cluster is standalone and accessed locally, having localhost in ZK will not be an issue. However, it's perfectly possible to have a standalone cluster accessed remotely, so you don't want to have the master to write I'm on the server named localhost in this case. I expect it won't be an issue for communications between the region servers or hdfs as they would be all on the same localhost... Cheers, Nicolas On Mon, Nov 26, 2012 at 7:16 PM, Mohammad Tariq [hidden email]http://user/SendEmail.jtp?type=nodenode=4034419i=1 wrote: what -- If you reply to this email, your message will be added to the discussion below: http://apache-hbase.679495.n3.nabble.com/Connecting-to-standalone-HBase-from-a-remote-client-tp4034362p4034419.html To unsubscribe from Connecting to standalone HBase from a remote client, click herehttp://apache-hbase.679495.n3.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_codenode=4034362code=bWF0YW5AY2xvdWRhbG9lLm9yZ3w0MDM0MzYyfC0xMDg3NTk1Njc3 . NAMLhttp://apache-hbase.679495.n3.nabble.com/template/NamlServlet.jtp?macro=macro_viewerid=instant_html%21nabble%3Aemail.namlbase=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespacebreadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml -- View this message in context: http://apache-hbase.679495.n3.nabble.com/Connecting-to-standalone-HBase-from-a-remote-client-tp4034362p4034439.html Sent from the HBase User mailing list archive at Nabble.com.
Re: Connecting to standalone HBase from a remote client
Hi there- re: From what I have understood, these properties are not for Hbase but for the Hbase client which we write. They tell the client where to look for ZK. Yep. That's how it works. Then the client looks up ROOT/META and then the client talks directly to the RegionServers. http://hbase.apache.org/book.html#client On 11/27/12 8:52 AM, Mohammad Tariq donta...@gmail.com wrote: Hello Matan, From what I have understood, these properties are not for Hbase but for the Hbase client which we write. They tell the client where to look for ZK. Hmaster registers its address with ZK. And from there client will come to know where to look for Hmaster. And if the Hmaster registers its address as 'localhost', the client will take it as the 'localhost', which is client's 'localhost' and not the 'localhost' where Hmaster is running. So, if you have the IP and hostname of the Hmaster in your /etc/hosts file the client can reach that machine without any problem as there is proper DNS resolution available. But this just is what I think. I need approval from the heavyweights. Stack sir?? Regards, Mohammad Tariq On Tue, Nov 27, 2012 at 5:57 PM, matan ma...@cloudaloe.org wrote: Thanks guys, Excuse my ignorance, but having sort of agreed that the configuration that determines which-server-should-be-contacted-for-what is on the HBase server, I am not sure how any of the practical suggestions made should solve the issue, and enable connecting from a remote client. Let me delineate - setting /etc/hosts on my client side seems in this regard not relevant in that view. And the other suggestion for hbase-site.xml configuration I have already got covered, as my client code successfully connects to zookeeper (the configuration properties mentioned on this thread are zookeeper specific according to my interpretation of documentation, I don't directly see how they should solve the problem). Perhaps Mohammad you can explain why those zookeeper properties relate to how the master references itself towards zookeeper? Should I take it from St.Ack that there is currently no way to specify the master's remotely accessible server/ip in the HBase configuration? Anyway, my HBase server's /etc/hosts has just one line now, in case it got lost on the thread - 127.0.0.1 localhost 'server-name'. Everything works fine on the HBase server itself, the same client code runs perfectly there. Thanks again, Matan On Mon, Nov 26, 2012 at 10:15 PM, Tariq [via Apache HBase] ml-node+s679495n4034419...@n3.nabble.com wrote: Hello Nicolas, You are right. It has been deprecated. Thank you for updating my knowledge base..:) Regards, Mohammad Tariq On Tue, Nov 27, 2012 at 12:17 AM, Nicolas Liochon [hidden email] http://user/SendEmail.jtp?type=nodenode=4034419i=0 wrote: Hi Mohammad, Your answer was right, just that specifying the master address is not necessary (anymore I think). But it does no harm. Changing the /etc/hosts (as you did) is right too. Lastly, if the cluster is standalone and accessed locally, having localhost in ZK will not be an issue. However, it's perfectly possible to have a standalone cluster accessed remotely, so you don't want to have the master to write I'm on the server named localhost in this case. I expect it won't be an issue for communications between the region servers or hdfs as they would be all on the same localhost... Cheers, Nicolas On Mon, Nov 26, 2012 at 7:16 PM, Mohammad Tariq [hidden email] http://user/SendEmail.jtp?type=nodenode=4034419i=1 wrote: what -- If you reply to this email, your message will be added to the discussion below: http://apache-hbase.679495.n3.nabble.com/Connecting-to-standalone-HBase-f rom-a-remote-client-tp4034362p4034419.html To unsubscribe from Connecting to standalone HBase from a remote client, click here http://apache-hbase.679495.n3.nabble.com/template/NamlServlet.jtp?macro=u nsubscribe_by_codenode=4034362code=bWF0YW5AY2xvdWRhbG9lLm9yZ3w0MDM0MzYy fC0xMDg3NTk1Njc3 . NAML http://apache-hbase.679495.n3.nabble.com/template/NamlServlet.jtp?macro=m acro_viewerid=instant_html%21nabble%3Aemail.namlbase=nabble.naml.namesp aces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view. web.template.NodeNamespacebreadcrumbs=notify_subscribers%21nabble%3Aemai l.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3 Aemail.naml -- View this message in context: http://apache-hbase.679495.n3.nabble.com/Connecting-to-standalone-HBase-f rom-a-remote-client-tp4034362p4034439.html Sent from the HBase User mailing list archive at Nabble.com.
Re: Connecting to standalone HBase from a remote client
Thank you both for the comments :) Regards, Mohammad Tariq On Tue, Nov 27, 2012 at 8:56 PM, ramkrishna vasudevan ramkrishna.s.vasude...@gmail.com wrote: You are right Mohammad, Regards Ram On Tue, Nov 27, 2012 at 8:53 PM, Doug Meil doug.m...@explorysmedical.com wrote: Hi there- re: From what I have understood, these properties are not for Hbase but for the Hbase client which we write. They tell the client where to look for ZK. Yep. That's how it works. Then the client looks up ROOT/META and then the client talks directly to the RegionServers. http://hbase.apache.org/book.html#client On 11/27/12 8:52 AM, Mohammad Tariq donta...@gmail.com wrote: Hello Matan, From what I have understood, these properties are not for Hbase but for the Hbase client which we write. They tell the client where to look for ZK. Hmaster registers its address with ZK. And from there client will come to know where to look for Hmaster. And if the Hmaster registers its address as 'localhost', the client will take it as the 'localhost', which is client's 'localhost' and not the 'localhost' where Hmaster is running. So, if you have the IP and hostname of the Hmaster in your /etc/hosts file the client can reach that machine without any problem as there is proper DNS resolution available. But this just is what I think. I need approval from the heavyweights. Stack sir?? Regards, Mohammad Tariq On Tue, Nov 27, 2012 at 5:57 PM, matan ma...@cloudaloe.org wrote: Thanks guys, Excuse my ignorance, but having sort of agreed that the configuration that determines which-server-should-be-contacted-for-what is on the HBase server, I am not sure how any of the practical suggestions made should solve the issue, and enable connecting from a remote client. Let me delineate - setting /etc/hosts on my client side seems in this regard not relevant in that view. And the other suggestion for hbase-site.xml configuration I have already got covered, as my client code successfully connects to zookeeper (the configuration properties mentioned on this thread are zookeeper specific according to my interpretation of documentation, I don't directly see how they should solve the problem). Perhaps Mohammad you can explain why those zookeeper properties relate to how the master references itself towards zookeeper? Should I take it from St.Ack that there is currently no way to specify the master's remotely accessible server/ip in the HBase configuration? Anyway, my HBase server's /etc/hosts has just one line now, in case it got lost on the thread - 127.0.0.1 localhost 'server-name'. Everything works fine on the HBase server itself, the same client code runs perfectly there. Thanks again, Matan On Mon, Nov 26, 2012 at 10:15 PM, Tariq [via Apache HBase] ml-node+s679495n4034419...@n3.nabble.com wrote: Hello Nicolas, You are right. It has been deprecated. Thank you for updating my knowledge base..:) Regards, Mohammad Tariq On Tue, Nov 27, 2012 at 12:17 AM, Nicolas Liochon [hidden email] http://user/SendEmail.jtp?type=nodenode=4034419i=0 wrote: Hi Mohammad, Your answer was right, just that specifying the master address is not necessary (anymore I think). But it does no harm. Changing the /etc/hosts (as you did) is right too. Lastly, if the cluster is standalone and accessed locally, having localhost in ZK will not be an issue. However, it's perfectly possible to have a standalone cluster accessed remotely, so you don't want to have the master to write I'm on the server named localhost in this case. I expect it won't be an issue for communications between the region servers or hdfs as they would be all on the same localhost... Cheers, Nicolas On Mon, Nov 26, 2012 at 7:16 PM, Mohammad Tariq [hidden email] http://user/SendEmail.jtp?type=nodenode=4034419i=1 wrote: what -- If you reply to this email, your message will be added to the discussion below: http://apache-hbase.679495.n3.nabble.com/Connecting-to-standalone-HBase-f rom-a-remote-client-tp4034362p4034419.html To unsubscribe from Connecting to standalone HBase from a remote client, click here http://apache-hbase.679495.n3.nabble.com/template/NamlServlet.jtp?macro=u nsubscribe_by_codenode=4034362code=bWF0YW5AY2xvdWRhbG9lLm9yZ3w0MDM0MzYy fC0xMDg3NTk1Njc3 . NAML http://apache-hbase.679495.n3.nabble.com/template/NamlServlet.jtp?macro=m acro_viewerid=instant_html%21nabble%3Aemail.namlbase=nabble.naml.namesp
Re: Connecting to standalone HBase from a remote client
Hi Mohammad, I'm loosing track... I came to understand that ZK tells the client where the ROOT/META is, and from there the client gets the region server it should contact. And yet I take it that you are saying that the configuration for the location of the ROOT/META or region server should be done on the client side. These two ideas seem to present a contradiction, and I probably don't have a good grasp of what is going on, or what should be done. Can you or anyone try to clarify? Thanks, matan On Tue, Nov 27, 2012 at 5:33 PM, Tariq [via Apache HBase] ml-node+s679495n4034446...@n3.nabble.com wrote: Thank you both for the comments :) Regards, Mohammad Tariq On Tue, Nov 27, 2012 at 8:56 PM, ramkrishna vasudevan [hidden email] http://user/SendEmail.jtp?type=nodenode=4034446i=0 wrote: You are right Mohammad, Regards Ram On Tue, Nov 27, 2012 at 8:53 PM, Doug Meil [hidden email]http://user/SendEmail.jtp?type=nodenode=4034446i=1 wrote: Hi there- re: From what I have understood, these properties are not for Hbase but for the Hbase client which we write. They tell the client where to look for ZK. Yep. That's how it works. Then the client looks up ROOT/META and then the client talks directly to the RegionServers. http://hbase.apache.org/book.html#client On 11/27/12 8:52 AM, Mohammad Tariq [hidden email]http://user/SendEmail.jtp?type=nodenode=4034446i=2 wrote: Hello Matan, From what I have understood, these properties are not for Hbase but for the Hbase client which we write. They tell the client where to look for ZK. Hmaster registers its address with ZK. And from there client will come to know where to look for Hmaster. And if the Hmaster registers its address as 'localhost', the client will take it as the 'localhost', which is client's 'localhost' and not the 'localhost' where Hmaster is running. So, if you have the IP and hostname of the Hmaster in your /etc/hosts file the client can reach that machine without any problem as there is proper DNS resolution available. But this just is what I think. I need approval from the heavyweights. Stack sir?? Regards, Mohammad Tariq On Tue, Nov 27, 2012 at 5:57 PM, matan [hidden email]http://user/SendEmail.jtp?type=nodenode=4034446i=3 wrote: Thanks guys, Excuse my ignorance, but having sort of agreed that the configuration that determines which-server-should-be-contacted-for-what is on the HBase server, I am not sure how any of the practical suggestions made should solve the issue, and enable connecting from a remote client. Let me delineate - setting /etc/hosts on my client side seems in this regard not relevant in that view. And the other suggestion for hbase-site.xml configuration I have already got covered, as my client code successfully connects to zookeeper (the configuration properties mentioned on this thread are zookeeper specific according to my interpretation of documentation, I don't directly see how they should solve the problem). Perhaps Mohammad you can explain why those zookeeper properties relate to how the master references itself towards zookeeper? Should I take it from St.Ack that there is currently no way to specify the master's remotely accessible server/ip in the HBase configuration? Anyway, my HBase server's /etc/hosts has just one line now, in case it got lost on the thread - 127.0.0.1 localhost 'server-name'. Everything works fine on the HBase server itself, the same client code runs perfectly there. Thanks again, Matan On Mon, Nov 26, 2012 at 10:15 PM, Tariq [via Apache HBase] [hidden email]http://user/SendEmail.jtp?type=nodenode=4034446i=4 wrote: Hello Nicolas, You are right. It has been deprecated. Thank you for updating my knowledge base..:) Regards, Mohammad Tariq On Tue, Nov 27, 2012 at 12:17 AM, Nicolas Liochon [hidden email] http://user/SendEmail.jtp?type=nodenode=4034419i=0 wrote: Hi Mohammad, Your answer was right, just that specifying the master address is not necessary (anymore I think). But it does no harm. Changing the /etc/hosts (as you did) is right too. Lastly, if the cluster is standalone and accessed locally, having localhost in ZK will not be an issue. However, it's perfectly possible to have a standalone cluster accessed remotely, so you don't want to have the master to write I'm on the server named localhost in this case. I expect it won't be an issue for communications between the region servers or hdfs as they would be all on the same localhost...
Re: Connecting to standalone HBase from a remote client
Matan, in short, your client should be able to resolve all names for all HBMaster, HBRegionServers and all ZK nodes. DNS or local /etc/hosts file, does not matter, but names should be resolvable correctly on the client machine. Then it will be able to connect to ZK, got HBmaster and ROOT/META locations . Thank you! Sincerely, Leonid Fedotov On Nov 27, 2012, at 8:10 AM, matan wrote: Hi Mohammad, I'm loosing track... I came to understand that ZK tells the client where the ROOT/META is, and from there the client gets the region server it should contact. And yet I take it that you are saying that the configuration for the location of the ROOT/META or region server should be done on the client side. These two ideas seem to present a contradiction, and I probably don't have a good grasp of what is going on, or what should be done. Can you or anyone try to clarify? Thanks, matan On Tue, Nov 27, 2012 at 5:33 PM, Tariq [via Apache HBase] ml-node+s679495n4034446...@n3.nabble.com wrote: Thank you both for the comments :) Regards, Mohammad Tariq On Tue, Nov 27, 2012 at 8:56 PM, ramkrishna vasudevan [hidden email] http://user/SendEmail.jtp?type=nodenode=4034446i=0 wrote: You are right Mohammad, Regards Ram On Tue, Nov 27, 2012 at 8:53 PM, Doug Meil [hidden email]http://user/SendEmail.jtp?type=nodenode=4034446i=1 wrote: Hi there- re: From what I have understood, these properties are not for Hbase but for the Hbase client which we write. They tell the client where to look for ZK. Yep. That's how it works. Then the client looks up ROOT/META and then the client talks directly to the RegionServers. http://hbase.apache.org/book.html#client On 11/27/12 8:52 AM, Mohammad Tariq [hidden email]http://user/SendEmail.jtp?type=nodenode=4034446i=2 wrote: Hello Matan, From what I have understood, these properties are not for Hbase but for the Hbase client which we write. They tell the client where to look for ZK. Hmaster registers its address with ZK. And from there client will come to know where to look for Hmaster. And if the Hmaster registers its address as 'localhost', the client will take it as the 'localhost', which is client's 'localhost' and not the 'localhost' where Hmaster is running. So, if you have the IP and hostname of the Hmaster in your /etc/hosts file the client can reach that machine without any problem as there is proper DNS resolution available. But this just is what I think. I need approval from the heavyweights. Stack sir?? Regards, Mohammad Tariq On Tue, Nov 27, 2012 at 5:57 PM, matan [hidden email]http://user/SendEmail.jtp?type=nodenode=4034446i=3 wrote: Thanks guys, Excuse my ignorance, but having sort of agreed that the configuration that determines which-server-should-be-contacted-for-what is on the HBase server, I am not sure how any of the practical suggestions made should solve the issue, and enable connecting from a remote client. Let me delineate - setting /etc/hosts on my client side seems in this regard not relevant in that view. And the other suggestion for hbase-site.xml configuration I have already got covered, as my client code successfully connects to zookeeper (the configuration properties mentioned on this thread are zookeeper specific according to my interpretation of documentation, I don't directly see how they should solve the problem). Perhaps Mohammad you can explain why those zookeeper properties relate to how the master references itself towards zookeeper? Should I take it from St.Ack that there is currently no way to specify the master's remotely accessible server/ip in the HBase configuration? Anyway, my HBase server's /etc/hosts has just one line now, in case it got lost on the thread - 127.0.0.1 localhost 'server-name'. Everything works fine on the HBase server itself, the same client code runs perfectly there. Thanks again, Matan On Mon, Nov 26, 2012 at 10:15 PM, Tariq [via Apache HBase] [hidden email]http://user/SendEmail.jtp?type=nodenode=4034446i=4 wrote: Hello Nicolas, You are right. It has been deprecated. Thank you for updating my knowledge base..:) Regards, Mohammad Tariq On Tue, Nov 27, 2012 at 12:17 AM, Nicolas Liochon [hidden email] http://user/SendEmail.jtp?type=nodenode=4034419i=0 wrote: Hi Mohammad, Your answer was right, just that specifying the master address is not necessary (anymore I think). But it does no harm. Changing the /etc/hosts (as you did) is right too. Lastly, if the cluster is standalone and accessed locally, having localhost in ZK will not be an issue. However, it's perfectly possible to have a standalone cluster accessed remotely, so you don't want to have the master to write I'm on the server named localhost in this case. I expect it won't be an issue for communications between the region
Re: Connecting to standalone HBase from a remote client
Thanks, but hard-coding the master's IP in my client code doesn't work - I also don't really understand why it has to be set in the client, as according to the flow you describe, the client is getting all it needs to know from zookeeper (?). Doing some digging on the HBase server side, I found that conf/regionservers has a single line containing the name 'localhost'. I changed it to the IP of the server, and restarted hbase. However my hbase client still thinks it should contact localhost after successfully connecting to zookeeper My hbase-site.xml only contains what http://hbase.apache.org/book.html#quickstart asked for, as seen right below. Perhaps that's not enough? configuration property namehbase.rootdir/name valuefile:/usr/local/hbase/hbase-0.94.2/data/hbase/value /property property namehbase.zookeeper.property.dataDir/name value/usr/local/hbase/hbase-0.94.2/data/zookeeper/value /property /configuration Kind of hoping there's a straightforward way to configure a solution. Must be something that's always being configured when clustering, otherwise the same problems would arise in a clustered environment, yet in my case I'm still running a standalone instance... On Sun, Nov 25, 2012 at 10:48 PM, Tariq [via Apache HBase] ml-node+s679495n4034365...@n3.nabble.com wrote: Also, add the IP and hostname of the machine running Hbase in your /etc/hosts file. Regards, Mohammad Tariq On Mon, Nov 26, 2012 at 2:15 AM, Mohammad Tariq [hidden email]http://user/SendEmail.jtp?type=nodenode=4034365i=0 wrote: Sent from handheld, don't mind typos. :) Regards, Mohammad Tariq On Mon, Nov 26, 2012 at 2:14 AM, Mohammad Tariq [hidden email]http://user/SendEmail.jtp?type=nodenode=4034365i=1wrote: Hello Matan, The client first contact the zookeeper to get the region that holds the ROOt table. From ROOt, client gets the server that holds META and from there it gets the info about the server which actually holds the key of the table of interest. Your client seems to get wrong info. Please add these props in your client code and see it works : hbaseConfiguration.set(hbase.zookeeper.quorum, 192.168.2.121); hbaseConfiguration.set(hbase.zookeeper.property.clientPort,2181); hbaseConfiguration.set(hbase.master, 192.168.2.121:6); Change the ports and addresses as per your config. HTH Regards, Mohammad Tariq On Mon, Nov 26, 2012 at 2:07 AM, matan [hidden email]http://user/SendEmail.jtp?type=nodenode=4034365i=2 wrote: Hi, With gracious help on this forum (from ramkrishna vasudevan) I've managed to setup HBase 0.94.2 in standalone mode on Ubuntu, and proceeded to writing a small client. I am trying to run the client from a remote server, not the one where HBase is running on. It seems pretty obvious looking at both server and client side logs, that my client successfully connects to zookeeper, but then tries to perform the actual interaction against the wrong network address. It looks like it is wrongfully trying to address localhost on the HBase client side rather than addressing the server where HBase is installed. In terms of flow, I guess that zookeeper provides my client with how to interact with HBase, and that it informs my client to that end that the name of the server to contact is 'localhost'. I can guess this may be changed, presumably by configuring HBase on the server side. Assuming that the correct flow should be that my client would get informed of the real name of the HBase server, by zookeeper. However I failed managing to configure just that. I tried the hbase.master property, but it had no effect. local HBase shell works just fine. The logs which led me to this analysis follow, perhaps you will agree with my analysis. How should I change my configuration to solve this? (making my client able to communicate with HBase after making the zookeeper connection...). *Server side log:* 2012-11-25 22:25:14,856 INFO org.apache.hadoop.hbase.master.AssignmentManager: The master has opened the region test4,,1353836779589.bb29c037092c5d69c9efc8f13c2b2563. that was online on localhost,58063,1353875103994 2012-11-25 22:26:05,670 INFO org.apache.zookeeper.server.NIOServerCnxnFactory: Accepted socket connection from /my-client-ip:49447 2012-11-25 22:26:05,672 INFO org.apache.zookeeper.server.ZooKeeperServer: Client attempting to establish new session at /my-client-ip:49447 2012-11-25 22:26:05,720 INFO org.apache.zookeeper.server.ZooKeeperServer:* Established session 0x13b393e9d1d0004 with negotiated timeout 4 for client /my-client-ip:49447* 2012-11-25 22:27:05,354 WARN org.apache.zookeeper.server.NIOServerCnxn: Exception causing close of session 0x13b393e9d1d0004 due to java.io.IOException: Connection reset by peer 2012-11-25 22:27:05,355 INFO
Re: Connecting to standalone HBase from a remote client
Yes, it's not useful to set the master address in the client. I suppose it was different a long time ago, hence there are some traces on different documentation. The master references itself in ZooKeeper. So if the master finds itself to be locahost, ZooKeeper will contain locahost, and the clients on another computer won't be able to connect. The issue lies on the master host, not the client. On Mon, Nov 26, 2012 at 4:06 PM, matan ma...@cloudaloe.org wrote: also don't really understand why it has to be set in the client, as according to the flow you describe, the client is getting all it needs to know from zookeeper (?).
Re: Connecting to standalone HBase from a remote client
On Mon, Nov 26, 2012 at 7:28 AM, Nicolas Liochon nkey...@gmail.com wrote: Yes, it's not useful to set the master address in the client. I suppose it was different a long time ago, hence there are some traces on different documentation. The master references itself in ZooKeeper. So if the master finds itself to be locahost, ZooKeeper will contain locahost, and the clients on another computer won't be able to connect. The issue lies on the master host, not the client. Sounds like something to fix. If distributed, write other than localhost to zk? St.Ack
Re: Connecting to standalone HBase from a remote client
Hello Matan, Did it work?If not, add these properties in your hbase-site.xml file and see if it works for you. property namehbase.zookeeper.quorum/name valueZH-HOST_MACHINE/value /property property namehbase.zookeeper.property.clientPort/name value2181/value /property property namehbase.zookeeper.property.dataDir/name valuepath_to_your_datadir/value /property HTH Regards, Mohammad Tariq On Mon, Nov 26, 2012 at 8:58 PM, Nicolas Liochon nkey...@gmail.com wrote: Yes, it's not useful to set the master address in the client. I suppose it was different a long time ago, hence there are some traces on different documentation. The master references itself in ZooKeeper. So if the master finds itself to be locahost, ZooKeeper will contain locahost, and the clients on another computer won't be able to connect. The issue lies on the master host, not the client. On Mon, Nov 26, 2012 at 4:06 PM, matan ma...@cloudaloe.org wrote: also don't really understand why it has to be set in the client, as according to the flow you describe, the client is getting all it needs to know from zookeeper (?).
Re: Connecting to standalone HBase from a remote client
Hi Mohammad, Your answer was right, just that specifying the master address is not necessary (anymore I think). But it does no harm. Changing the /etc/hosts (as you did) is right too. Lastly, if the cluster is standalone and accessed locally, having localhost in ZK will not be an issue. However, it's perfectly possible to have a standalone cluster accessed remotely, so you don't want to have the master to write I'm on the server named localhost in this case. I expect it won't be an issue for communications between the region servers or hdfs as they would be all on the same localhost... Cheers, Nicolas On Mon, Nov 26, 2012 at 7:16 PM, Mohammad Tariq donta...@gmail.com wrote: what
Re: Connecting to standalone HBase from a remote client
Hello Nicolas, You are right. It has been deprecated. Thank you for updating my knowledge base..:) Regards, Mohammad Tariq On Tue, Nov 27, 2012 at 12:17 AM, Nicolas Liochon nkey...@gmail.com wrote: Hi Mohammad, Your answer was right, just that specifying the master address is not necessary (anymore I think). But it does no harm. Changing the /etc/hosts (as you did) is right too. Lastly, if the cluster is standalone and accessed locally, having localhost in ZK will not be an issue. However, it's perfectly possible to have a standalone cluster accessed remotely, so you don't want to have the master to write I'm on the server named localhost in this case. I expect it won't be an issue for communications between the region servers or hdfs as they would be all on the same localhost... Cheers, Nicolas On Mon, Nov 26, 2012 at 7:16 PM, Mohammad Tariq donta...@gmail.com wrote: what
