Hi Group,
Some here may have been following my thread working through bug fixes to get geomesa running on a HDP cluster.
I’m still not able to ingest data in distributed mode, but got past the initial errors and am now on to new ones - so making progress I think. If anyone can help - please pitch in.
Apologies for such a long email, but I’m including my running install notes, errors found, and fixes that work so far.
I’ll eventually write these up and stick them up on my github.
## Running Geomesa on a Hortonworks HDP cluster.
NOTE: I have a single node HDP dev cluster. In larger clusters or with different configurations, your mileage may vary. I’m running: HDP-2.4.0.0-169
1. Follow the geomesa installation instructions. Ensure you install the geomesa version that works with accumulo 1.7+ 2. When you get to the point where you are able to run geomesa env and get results, you are now ready to ingest data. 3. First I suggest you ingest local files. Follow instructions to download a sample gdelt events files and pop it into a data directory on the local filesystem. 4. in $GEOMESA_HOME create a loadscripts directory where you can create test ingestion scripts cd $GEOMESA_HOME; mkdir loadscripts; cd loadscripts 5. create a test load script for your data as below. Note I’m including parameters that expose passwords, so this is not ideal. be wary in prod., but to hack a fix, it was quickest.
vi load_local_gdelt.sh
create a base script that includes the hack to set the hp.version environment variable properly and echo it out to logs.
## # this is a test of the gemomesa ingestion.
accumulo_instance_id_param="hdp-accumulo-instance" accumulo_user=‘your_user_name' accumulo_pw=‘your_accumulo_pw' myHortonVersion=`hadoop version | grep "^This command" | sed " s/^.*hdp.// " | sed "s/.hadoop.hadoop-common.*//" | sed "s/^/-Dhdp.version=/" ` echo "using these java opts:" echo ${myHortonVersion} export JAVA_OPTS=${myHortonVersion} echo "Using this Java Option: "${JAVA_OPTS}
geomesa ingest \ -u ${accumulo_user} -p ${accumulo_pw} \ -i ${accumulo_instance_id_param} -z ${zookeeper_param} \ -c myGeomesa.gdelt -s gdelt-schema \ -C gdelt-reader \ /home/andrew/data/geo/geomesa-1.2.4/dist/tools/geomesa-tools-1.2.4/data/gdelt/20160601.export.CSV ## Then if you run this load script you should be able to ingest local data, as the version variable is passed through properly.
6. Now we have a working ingestion routine to test with, we try running a load from HDFS in distributed mode. Copy and rename your load script for edit.
cp load_local_gdelt.sh load_hdfs_gdelt.sh vi load_hdfs_gdelt.sh
these are the edits I’m testing:
## # this is a test of the gemomesa ingestion.
accumulo_instance_id_param="hdp-accumulo-instance" accumulo_user=‘your_user_name' accumulo_pw=‘your_accumulo_pw' myHortonVersion=`hadoop version | grep "^This command" | sed " s/^.*hdp.// " | sed "s/.hadoop.hadoop-common.*//" | sed "s/^/-Dhdp.version=/" ` echo "using these java opts:" echo ${myHortonVersion} export JAVA_OPTS=${myHortonVersion} echo "Using this Java Option: "${JAVA_OPTS} geomesa ingest \ -u ${accumulo_user} -p ${accumulo_pw} \ -i ${accumulo_instance_id_param} -z ${zookeeper_param} \ -c myGeomesa.gcam -s gcam-schema \ -C gcam-reader \ hdfs:///user/feeds/gdelt/datastore/GcamGeo/GCAM_201606*.csv ## *note I’m ingesting my own dataset here, and am referencing a file glob in hdfs rather than a local file. Adjust as needed for your data / SFTS config. If you run this you will most likely get the following error on HDP 2.4.0.0-169
[andrew@gzet loadscripts]$ . load_gcam.sh using these java opts: -Dhdp.version=2.4.0.0-169 Using this Java Option: -Dhdp.version=2.4.0.0-169 Using GEOMESA_HOME = /home/andrew/data/geo/geomesa-1.2.4/dist/tools/geomesa-tools-1.2.4 Creating schema gcam-schema Running ingestion in distributed mode Submitting job - please wait... Unable to parse '/hdp/apps/${hdp.version}/mapreduce/mapreduce.tar.gz#mr-framework' as a URI, check the setting for mapreduce.application.framework.path java.lang.IllegalArgumentException: Unable to parse '/hdp/apps/${hdp.version}/mapreduce/mapreduce.tar.gz#mr-framework' as a URI, check the setting for mapreduce.application.framework.path
7. Fixing Hortonwork settings to resolve the error:
and navigate to the mapreduce2 configs tab.
Search the configuration for “mapreduce.application” and you’ll see the short list of two properties to correct: These are:
mapreduce.application.classpath mapreduce.application.framework.path
After some trial and error I discovered you need to append
/hdp/apps/${hdp.version}/mapreduce/mapreduce.tar.gz#mrframework
to the end of your mapreduce.application.classpath
and set mapreduce.application.framework.path
to being /hdp/apps/${hdp.version}/mapreduce/mapreduce.tar.gz#mrframework
Additionally, you also need to create a new custom property. Do so under the configuration section called "Custom mapred-site” by clicking "add property". In the pop up window, fill in these values for your version of HDP (that matches the one calculated in the load script above). In my case:
key = hdp.version value = 2.4.0.0-169
and hit save. This will create a hdp.version property that will be included into the configurations held in mapred-set.xml on a restart, and allow your class paths to continue to be relative rather than hardcoded. I found this tip on the web, and it seems to work and be better than hardcoding directories.
To finalise the configuration change, click save, jot some version notes, and then follow the on screen prompts to restart all your affected mapreduce2, yarn, and hive services.
8. OK - now we can re-test running the distributed map reduce ingestion load script again.
[andrew@gzet loadscripts]$ . load_gcam.sh using these java opts: -Dhdp.version=2.4.0.0-169 Using this Java Option: -Dhdp.version=2.4.0.0-169 Using GEOMESA_HOME = /home/andrew/data/geo/geomesa-1.2.4/dist/tools/geomesa-tools-1.2.4 Creating schema gcam-schema Running ingestion in distributed mode Submitting job - please wait... [ ] 0% complete 0 ingested 0 failed in 00:00:43 Job failed with state FAILED due to: Application application_1469962580597_0003 failed 2 times due to AM Container for appattempt_1469962580597_0003_000002 exited with exitCode: 1 For more detailed output, check application tracking page:http://gzet.bytesumo.com:8088/cluster/app/application_1469962580597_0003Then, click on links to logs of each attempt. Diagnostics: Exception from container-launch. Container id: container_e38_1469962580597_0003_02_000001 Exit code: 1 Stack trace: ExitCodeException exitCode=1: at org.apache.hadoop.util.Shell.runCommand(Shell.java:576) at org.apache.hadoop.util.Shell.run(Shell.java:487) at org.apache.hadoop.util.Shell$ShellCommandExecutor.execute(Shell.java:753) at org.apache.hadoop.yarn.server.nodemanager.DefaultContainerExecutor.launchContainer(DefaultContainerExecutor.java:212) at org.apache.hadoop.yarn.server.nodemanager.containermanager.launcher.ContainerLaunch.call(ContainerLaunch.java:303) at org.apache.hadoop.yarn.server.nodemanager.containermanager.launcher.ContainerLaunch.call(ContainerLaunch.java:82) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745)
Container exited with a non-zero exit code 1 Failing this attempt. Failing the application. Distributed ingestion complete in 00:00:43 Ingested 0 features with no failures.
We can see that our environment variable issues went away, and that it found the mapreduce framework code, and that it even got as far trying to launch the job’s yarn containers. When I examine the logs and zoom in on the actual error, I find the following:
Log Type: stderr Log Upload Time: Sun Jul 31 11:41:01 +0100 2016 Log Length: 88 Error: Could not find or load main class org.apache.hadoop.mapreduce.v2.app.MRAppMaster
It seems that the new problem is another classpath issue, but this time in yarn. Searching maven central I see that the un-findable class is delivered in this jar file:
hadoop-mapreduce-client-app
And to check my yarn paths to see if it’s being picked up I try this:
[andrew@gzet loadscripts]$ ls -lart `yarn classpath | sed 's/:/ /g'` | grep hadoop-mapreduce-client-app ls: cannot access mysql-connector-java.jar: No such file or directory -rw-r--r--. 1 root root 514884 Feb 10 06:44 /usr/hdp/2.4.0.0-169/hadoop-mapreduce/.//hadoop-mapreduce-client-app-2.7.1.2.4.0.0-169.jar lrwxrwxrwx. 1 root root 49 Mar 29 01:29 /usr/hdp/2.4.0.0-169/hadoop-mapreduce/.//hadoop-mapreduce-client-app.jar -> hadoop-mapreduce-client-app-2.7.1.2.4.0.0-169.jar lrwxrwxrwx. 1 root root 88 Mar 29 01:31 hadoop-mapreduce-client-app.jar -> /usr/hdp/2.4.0.0-169/hadoop-mapreduce//hadoop-mapreduce-client-app-2.7.1.2.4.0.0-169.jar lrwxrwxrwx. 1 root root 88 Mar 29 01:31 hadoop-mapreduce-client-app-2.7.1.2.4.0.0-169.jar -> /usr/hdp/2.4.0.0-169/hadoop-mapreduce//hadoop-mapreduce-client-app-2.7.1.2.4.0.0-169.jar
9. And this is where I’m currently stuck, and now reading up on yarn. It seems the jar is on the class path - so perhaps there is a permissions issue somewhere?
Any help at this point would be very welcome.
Andrew
Andrew J Morgan CEO, Bytesumo Limited E-mail: andrew@xxxxxxxxxxxx
Bytesumo Limited - Registered Company in England and Wales 33 Brodrick Grove, London, SE2 0SR, UK. Company Number: 8505203
Hi Jason, It's a good idea. I'm going to dig into this and drop you a line when I test out some things and find out more. A Sent from my iPhone On 29 Jul 2016, at 17:26, Jason Brown <jbrown@xxxxxxxx> wrote:
Andrew,
Can you check the value of `mapreduce.application.classpath` in mapred-default.xml? If that's not set, I would use the output of `hadoop classpath` as a first guess.
-Jason
On 07/29/2016 12:00 PM, geomesa-users-request@xxxxxxxxxxxxxxxx wrote: Send geomesa-users mailing list submissions to geomesa-users@xxxxxxxxxxxxxxxx
To subscribe or unsubscribe via the World Wide Web, visit https://www.locationtech.org/mailman/listinfo/geomesa-users or, via email, send a message with subject or body 'help' to geomesa-users-request@xxxxxxxxxxxxxxxx
You can reach the person managing the list at geomesa-users-owner@xxxxxxxxxxxxxxxx
When replying, please edit your Subject line so it is more specific than "Re: Contents of geomesa-users digest..."
Today's Topics:
1. Re: Hortonworks/Geomesa distributed ingestion, error. (Andrew Morgan) 2. Re: Hortonworks/Geomesa distributed ingestion, error. (Andrew Morgan) 3. Program using Accumulo backed DataStore won't exit (Bryan Moore) 4. Re: Program using Accumulo backed DataStore won't exit (Jim Hughes)
----------------------------------------------------------------------
Message: 1 Date: Thu, 28 Jul 2016 15:37:36 +0100 From: Andrew Morgan <andrew@xxxxxxxxxxxx> To: Jason Brown <jbrown@xxxxxxxx> Cc: geomesa-users@xxxxxxxxxxxxxxxx Subject: Re: [geomesa-users] Hortonworks/Geomesa distributed ingestion, error. Message-ID: <A560F774-8850-40B4-82E1-AFACF13FDF5E@xxxxxxxxxxxx> Content-Type: text/plain; charset="utf-8"
I did try this, and I thought it would work.
In my shell scrip that launches the load I included these lines:
myHortonVersion=`hadoop version | grep "^This command" | sed " s/^.*hdp.// " | sed "s/.hadoop.hadoop-common.*//" | sed "s/^/-Dhdp.version=/" `
echo ?determined this is the local hortonworks version:" echo ${myHortonVersion}
export JAVA_OPTS=${myHortonVersion} echo "Using this Java Option: ? echo ${JAVA_OPTS}
geomesa ingest \ -u ${accumulo_user} -p ${accumulo_pw} \ -i ${accumulo_instance_id_param} -z ${zookeeper_param} \ -c myGeomesa.gcam -s gcam-schema \ -C gcam-reader \ hdfs:///user/feeds/gdelt/datastore/GcamGeo/GCAM_201606*.csv
When I run it I still get the same error, pasted below:
[andrew@gzet loadscripts]$ . load_gcam.sh using these java opts: -Dhdp.version=2.4.0.0-169 Using this Java Option: -Dhdp.version=2.4.0.0-169 Using GEOMESA_HOME = /home/andrew/data/geo/geomesa-1.2.4/dist/tools/geomesa-tools-1.2.4 Creating schema gcam-schema Running ingestion in distributed mode Submitting job - please wait... Unable to parse '/hdp/apps/${hdp.version}/mapreduce/mapreduce.tar.gz#mr-framework' as a URI, check the setting for mapreduce.application.framework.path java.lang.IllegalArgumentException: Unable to parse '/hdp/apps/${hdp.version}/mapreduce/mapreduce.tar.gz#mr-framework' as a URI, check the setting for mapreduce.application.framework.path
when I inspect the error further I find the mapreduce.tar.gz that the code is looking for here:
/usr/hdp/2.4.0.0-169/hadoop/mapreduce.tar.gz
We see that we are looking at the wrong path, albeit with the right version embedded in it. The way the version option is assembled from the JAVA_OPTS into the URI for the file it?s searching for needs adjusting.
Is there a way you can pass that in an an option too?
many thanks with this Andrew
Andrew J Morgan CEO, Bytesumo Limited Tel: +44?(0)7970130767 <> E-mail: andrew@xxxxxxxxxxxx <mailto:andrew@xxxxxxxxxxxx>
Bytesumo Limited - Registered Company in England and Wales 33 Brodrick Grove, London, SE2 0SR, UK. Company Number: 8505203
On 27 Jul 2016, at 23:17, Andrew Morgan <andrew@xxxxxxxxxxxx> wrote:
James - this is really useful, thanks.
I?m now working through creating valid ingestion configuration routines for my files. I had some errors in my configurations and I?m tweaking things to fix them. For now I?m quickly testing using some local test files.
When my converter works properly, which should be shortly, I?ll re-point it at the HDFS data and try a larger ingest of my back history, and report back in.
thanks again! Andrew
Andrew J Morgan CEO, Bytesumo Limited Tel: +44?(0)7970130767 <> E-mail: andrew@xxxxxxxxxxxx <mailto:andrew@xxxxxxxxxxxx>
Bytesumo Limited - Registered Company in England and Wales 33 Brodrick Grove, London, SE2 0SR, UK. Company Number: 8505203
On 27 Jul 2016, at 20:09, Jason Brown <jbrown@xxxxxxxx <mailto:jbrown@xxxxxxxx>> wrote:
Andrew,
Hi and welcome! We're glad you're up and running and got smoothly this far!
The fix is to set (or append to) an environment variable JAVA_OPTS with the key `-Dhdp.version`. Use hadoop version to get the hdp.version. For example:
$ hadoop version
Hadoop 2.7.1.2.4.2.0-258 Subversion git@xxxxxxxxxx:hortonworks/hadoop.git -r 13debf893a605e8a88df18a7d8d214f571e05289 Compiled by jenkins on 2016-04-25T05:46Z Compiled with protoc 2.5.0 From source with checksum 2a2d95f05ec6c3ac547ed58cab713ac This command was run using /usr/hdp/2.4.2.0-258/hadoop/hadoop-common-2.7.1.2.4.2.0-258.jar
We parse as Hadoop 2.7.1 and HDP version 2.4.2.0-258. Note the HDP version appears in both the hadoop version and the directory for hadoop-common.jar. So now set (or append) your JAVA_OPTS.
$ JAVA_OPTS="-Dhdp.version=2.4.2.0-258"
And try your ingest again. Let us know if you run into any additional issues.
-Jason
-------------- next part -------------- An HTML attachment was scrubbed... URL: <https://www.locationtech.org/mhonarc/lists/geomesa-users/attachments/20160728/897dbfa8/attachment.html>
------------------------------
Message: 2 Date: Thu, 28 Jul 2016 16:19:36 +0100 From: Andrew Morgan <andrew@xxxxxxxxxxxx> To: geomesa-users@xxxxxxxxxxxxxxxx Subject: [geomesa-users] Re: Hortonworks/Geomesa distributed ingestion, error. Message-ID: <8E8F43F6-D42F-43FE-BBCB-4EC8C88EC467@xxxxxxxxxxxx> Content-Type: text/plain; charset="utf-8"
I did try this, and I thought it would work, but I still have an issue.
In my shell script that launches the load I included these lines:
myHortonVersion=`hadoop version | grep "^This command" | sed " s/^.*hdp.// " | sed "s/.hadoop.hadoop-common.*//" | sed "s/^/-Dhdp.version=/" `
echo ?determined this is the local hortonworks version:" echo ${myHortonVersion}
export JAVA_OPTS=${myHortonVersion} echo "Using this Java Option: ? echo ${JAVA_OPTS}
geomesa ingest \ -u ${accumulo_user} -p ${accumulo_pw} \ -i ${accumulo_instance_id_param} -z ${zookeeper_param} \ -c myGeomesa.gcam -s gcam-schema \ -C gcam-reader \ hdfs:///user/feeds/gdelt/datastore/GcamGeo/GCAM_201606*.csv <hdfs:///user/feeds/gdelt/datastore/GcamGeo/GCAM_201606*.csv>
When I run it I still get the same error, pasted below:
[andrew@gzet loadscripts]$ . load_gcam.sh using these java opts: -Dhdp.version=2.4.0.0-169 Using this Java Option: -Dhdp.version=2.4.0.0-169 Using GEOMESA_HOME = /home/andrew/data/geo/geomesa-1.2.4/dist/tools/geomesa-tools-1.2.4 Creating schema gcam-schema Running ingestion in distributed mode Submitting job - please wait... Unable to parse '/hdp/apps/${hdp.version}/mapreduce/mapreduce.tar.gz#mr-framework' as a URI, check the setting for mapreduce.application.framework.path java.lang.IllegalArgumentException: Unable to parse '/hdp/apps/${hdp.version}/mapreduce/mapreduce.tar.gz#mr-framework' as a URI, check the setting for mapreduce.application.framework.path
when I inspect the error further I find the mapreduce.tar.gz that the code is looking for here:
/usr/hdp/2.4.0.0-169/hadoop/mapreduce.tar.gz
We see that we are looking at the wrong path, albeit with the right version embedded in it. The way the version option is assembled from the JAVA_OPTS into the URI for the file it?s searching for needs adjusting.
Is there a way to pass the URI path in as an an option too?
many thanks with this Andrew
Andrew J Morgan CEO, Bytesumo Limited E-mail: andrew@xxxxxxxxxxxx <mailto:andrew@xxxxxxxxxxxx>
Bytesumo Limited - Registered Company in England and Wales 33 Brodrick Grove, London, SE2 0SR, UK. Company Number: 8505203
On 27 Jul 2016, at 23:17, Andrew Morgan <andrew@xxxxxxxxxxxx <mailto:andrew@xxxxxxxxxxxx>> wrote:
James - this is really useful, thanks.
I?m now working through creating valid ingestion configuration routines for my files. I had some errors in my configurations and I?m tweaking things to fix them. For now I?m quickly testing using some local test files.
When my converter works properly, which should be shortly, I?ll re-point it at the HDFS data and try a larger ingest of my back history, and report back in.
thanks again! Andrew
Andrew J Morgan CEO, Bytesumo Limited Tel: +44?(0)7970130767 <> E-mail: andrew@xxxxxxxxxxxx <mailto:andrew@xxxxxxxxxxxx>
Bytesumo Limited - Registered Company in England and Wales 33 Brodrick Grove, London, SE2 0SR, UK. Company Number: 8505203
On 27 Jul 2016, at 20:09, Jason Brown <jbrown@xxxxxxxx <mailto:jbrown@xxxxxxxx>> wrote:
Andrew,
Hi and welcome! We're glad you're up and running and got smoothly this far!
The fix is to set (or append to) an environment variable JAVA_OPTS with the key `-Dhdp.version`. Use hadoop version to get the hdp.version. For example:
$ hadoop version
Hadoop 2.7.1.2.4.2.0-258 Subversion git@xxxxxxxxxx:hortonworks/hadoop.git -r 13debf893a605e8a88df18a7d8d214f571e05289 Compiled by jenkins on 2016-04-25T05:46Z Compiled with protoc 2.5.0 From source with checksum 2a2d95f05ec6c3ac547ed58cab713ac This command was run using /usr/hdp/2.4.2.0-258/hadoop/hadoop-common-2.7.1.2.4.2.0-258.jar
We parse as Hadoop 2.7.1 and HDP version 2.4.2.0-258. Note the HDP version appears in both the hadoop version and the directory for hadoop-common.jar. So now set (or append) your JAVA_OPTS.
$ JAVA_OPTS="-Dhdp.version=2.4.2.0-258"
And try your ingest again. Let us know if you run into any additional issues.
-Jason
-------------- next part -------------- An HTML attachment was scrubbed... URL: <https://www.locationtech.org/mhonarc/lists/geomesa-users/attachments/20160728/7054f183/attachment.html>
------------------------------
Message: 3 Date: Fri, 29 Jul 2016 11:15:34 -0400 From: Bryan Moore <bryan@xxxxxxxxxxxxxx> To: geomesa-users@xxxxxxxxxxxxxxxx Subject: [geomesa-users] Program using Accumulo backed DataStore won't exit Message-ID: <d052a8a1-5c88-675f-cd35-28bf31e4e77f@xxxxxxxxxxxxxx> Content-Type: text/plain; charset="utf-8"; Format="flowed"
I've written a program using GeoMesa with an Accumulo backed DataStore that works fine but won't exit. Below is a minimal program that illustrates the problem. It prints the "Start" and "Finish" messages but doesn't exit.
Have I done something wrong, not done something I need to do, or is this a bug?
import java.io.IOException; import java.util.HashMap; import java.util.Map;
import org.apache.accumulo.core.client.AccumuloException; import org.apache.accumulo.core.client.AccumuloSecurityException; import org.geotools.data.DataStoreFinder; import org.locationtech.geomesa.accumulo.data.AccumuloDataStore;
public class Minimal {
public static void main(String[] args) throws AccumuloException, AccumuloSecurityException, IOException { System.out.println("Start"); Map<String, String> dsConf = new HashMap<>(); dsConf.put("instanceId", "myinstancename"); dsConf.put("zookeepers", "localhost:2181"); dsConf.put("user", "myuserid"); dsConf.put("password", "mypassword"); dsConf.put("tableName", "mysearchtable"); dsConf.put("auths", ""); AccumuloDataStore dataStore = (AccumuloDataStore) DataStoreFinder.getDataStore(dsConf); dataStore.dispose(); System.out.println("Finish"); } }
-------------- next part -------------- An HTML attachment was scrubbed... URL: <https://www.locationtech.org/mhonarc/lists/geomesa-users/attachments/20160729/855e74d2/attachment.html>
------------------------------
Message: 4 Date: Fri, 29 Jul 2016 11:43:29 -0400 From: Jim Hughes <jnh5y@xxxxxxxx> To: geomesa-users@xxxxxxxxxxxxxxxx Subject: Re: [geomesa-users] Program using Accumulo backed DataStore won't exit Message-ID: <579B79A1.9010806@xxxxxxxx> Content-Type: text/plain; charset="windows-1252"; Format="flowed"
Hi Bryan,
Which version of GeoMesa are you using? There is a known issue with GeoMesa 1.2.3 where a thread for pre-computed stats writing is not shutdown. We believe we addressed this in 1.2.4.
In terms of helping diagnose the problem, can you run jstack on the hanging JVM and look for anything notable in the output?
Thanks,
Jim
On 07/29/2016 11:15 AM, Bryan Moore wrote: I've written a program using GeoMesa with an Accumulo backed DataStore that works fine but won't exit. Below is a minimal program that illustrates the problem. It prints the "Start" and "Finish" messages but doesn't exit.
Have I done something wrong, not done something I need to do, or is this a bug?
import java.io.IOException; import java.util.HashMap; import java.util.Map;
import org.apache.accumulo.core.client.AccumuloException; import org.apache.accumulo.core.client.AccumuloSecurityException; import org.geotools.data.DataStoreFinder; import org.locationtech.geomesa.accumulo.data.AccumuloDataStore;
public class Minimal {
public static void main(String[] args) throws AccumuloException, AccumuloSecurityException, IOException { System.out.println("Start"); Map<String, String> dsConf = new HashMap<>(); dsConf.put("instanceId", "myinstancename"); dsConf.put("zookeepers", "localhost:2181"); dsConf.put("user", "myuserid"); dsConf.put("password", "mypassword"); dsConf.put("tableName", "mysearchtable"); dsConf.put("auths", ""); AccumuloDataStore dataStore = (AccumuloDataStore) DataStoreFinder.getDataStore(dsConf); dataStore.dispose(); System.out.println("Finish"); } }
_______________________________________________ geomesa-users mailing list geomesa-users@xxxxxxxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.locationtech.org/mailman/listinfo/geomesa-users
-------------- next part -------------- An HTML attachment was scrubbed... URL: <https://www.locationtech.org/mhonarc/lists/geomesa-users/attachments/20160729/3bce0bce/attachment.html>
------------------------------
_______________________________________________ geomesa-users mailing list geomesa-users@xxxxxxxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.locationtech.org/mailman/listinfo/geomesa-users
End of geomesa-users Digest, Vol 29, Issue 19 *********************************************
_______________________________________________ geomesa-users mailing list geomesa-users@xxxxxxxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.locationtech.org/mailman/listinfo/geomesa-users
|