| Simon,
Congrats! That's great news. If I recall, this error primarily happens when things get out of during shutdown (on our end, nothing you did is wrong).
I think your patch is likely going to work for the situation where the client is handling only one Kerberos identity. In the case of GeoServer use, this will make sense for some situations.
I could imagine a situation where each user accessing GeoServer may need to have their token passed through. We can iterate on that though.
Thanks again, and I'm glad that the integration is going well!
Jim
----- Original Message -----
From: "Geomesa User discussions" <geomesa-users@xxxxxxxxxxxxxxxx>
To: "Geomesa User discussions" <geomesa-users@xxxxxxxxxxxxxxxx>
Cc:
Sent: Sat, 6 Jun 2015 23:27:40 -0400
Subject: Re: [geomesa-users] kerberos auth
I patched geomesa very minimally and got an ingestion script to work
using kerberos auth against accumulo 1.7. It works well, except for an
annoying error message at the end of the execution:
15/06/07 00:29:22 INFO zookeeper.ZooCache: Zookeeper error, will retry
java.lang.InterruptedException
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:503)
at org.apache.zookeeper.ClientCnxn.submitRequest(ClientCnxn.java:1342)
at org.apache.zookeeper.ZooKeeper.exists(ZooKeeper.java:1036)
at org.apache.accumulo.fate.zookeeper.ZooCache$2.run(ZooCache.java:264)
at org.apache.accumulo.fate.zookeeper.ZooCache.retry(ZooCache.java:162)
at org.apache.accumulo.fate.zookeeper.ZooCache.get(ZooCache.java:289)
at org.apache.accumulo.fate.zookeeper.ZooCache.get(ZooCache.java:238)
at org.apache.accumulo.core.client.impl.Tables.getTableState(Tables.java:180)
at org.apache.accumulo.core.client.impl.ConnectorImpl.getTableId(ConnectorImpl.java:82)
at org.apache.accumulo.core.client.impl.ConnectorImpl.createBatchWriter(ConnectorImpl.java:128)
at org.locationtech.geomesa.core.stats.StatWriter$$anonfun$write$2.apply(StatWriter.scala:174)
at org.locationtech.geomesa.core.stats.StatWriter$$anonfun$write$2.apply(StatWriter.scala:156)
at scala.collection.immutable.Map$Map1.foreach(Map.scala:109)
at org.locationtech.geomesa.core.stats.StatWriter$.write(StatWriter.scala:156)
at org.locationtech.geomesa.core.stats.StatWriter$.drainQueue(StatWriter.scala:148)
at org.locationtech.geomesa.core.stats.StatWriter$.run(StatWriterscala:116)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:304)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at javautil.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
This doesn't impact the correctness of my ingestion/query program.
Seems to be something that needs proper clean up.
-Simon
On Sat, Jun 6, 2015 at 12:16 AM, James Hughes <jnh5y@xxxxxxxx> wrote:
> Simon,
>
> I think I prefer the first option given the context of Accumulo 1.7. The PR
> can go against just that branch. I'm happy to look at intermediate branches
> to answer questions or provide feedback
>
> In terms of contributing, GeoMesa is open-sourced through the Eclipse
> Foundation, so you'll need to register for an Eclipse account to sign a
> contributor license agreement. I'll try and send along some more details
> about that off-list.
>
> Thanks in advance for the contribution! Cheers,
>
> Jim
>
>
> ----- Original Message -----
> From:
> "Geomesa User discussions" <geomesa-users@xxxxxxxxxxxxxxxx>
>
> To:
> "Geomesa User discussions" <geomesa-users@xxxxxxxxxxxxxxxx>
> Cc:
>
> Sent:
> Fri, 5 Jun 2015 19:02:21 -0400
> Subject:
> Re: [geomesa-users] kerberos auth
>
>
>
> Jim,
>
> Sure... I've been reading the code and trying to get a patch going. I'll be
> happy to send in a pull request at some point.
>
> Before I go too far, how shall we decide to perform kerberos auth instead of
> password auth? My current plan is to make user and password both optional.
> And if user is null, AccumuloDataStoreFactory would try to use
> KerberosToken() instead. Does this make sense, or would you rather pass in a
> boolean flag, like kerboersAuth, which defaults to false?
>
> Basically with kerberos, there is no need to pass in user/pass - a kerberos
> ticket (usually stored locally in filename $KRB5CCNAME) is tied to a
> kerberos principal (user@realm) and can be used for authentication.
>
> Thanks.
> -Simon
>
>
> On Fri, Jun 5, 2015 at 6:18 PM, Jim Hughes <jnh5y@xxxxxxxx> wrote:
>>
>> Hi Simon,
>>
>> In general, we do plan to support new Accumulo features such as this. At
>> the minute, it isn't on the our immediate internal development schedule.
>>
>> That said, if you're willing to share in some of the legwork, we can
>> likely coordinate a branch that will get the ball rolling. If you can help
>> identify some of the config we'd need to pass in (as a replacement for a
>> username/password), we can start to think about would have to change.
>>
>> Assuming that you are willing to share in some of the development, I'd be
>> happy to see this move along.
>>
>> Cheers,
>>
>> Jim
>>
>>
>> On 06/05/2015 03:28 PM, Xu (Simon) Chen wrote:
>>
>> Hey folks,
>>
>> I just converted my accumulo to 1.7 and enabled kerberos auth. Now I need
>> to get geomesa-quickstart to work with kerberos auth.
>>
>> Currently, it looks like the current AccumuloDataStoreFactory's
>> buildAccumuloConnector function is tied to password auth, at least in
>> rc7_a1.7_h2.5 branch (thanks, Jim!) and master branch.
>>
>>
>> https://github.com/locationtech/geomesa/blob/master/geomesa-accumulo/geomesa-accumulo-datastore/src/main/scala/org/locationtech/geomesa/accumulo/data/AccumuloDataStoreFactory.scala#L167
>>
>>
>> https://github.com/locationtech/geomesa/blob/rc7_a1.7_h2.5/geomesa-core/src/main/scala/org/locationtech/geomesa/core/data/AccumuloDataStoreFactory.scala#L167
>>
>> I am curious if there is any plan to support kerberos auth of accumulo in
>> geomesa.
>>
>> Thanks.
>> -Simon
>>
>>
>> _______________________________________________
>> geomesa-users mailing list
>> geomesa-users@xxxxxxxxxxxxxxxx
>> To change your delivery options, retrieve your password, or unsubscribe
>> from this list, visit
>> http://www.locationtech.org/mailman/listinfo/geomesa-users
>>
>>
>>
>> _______________________________________________
>> geomesa-users mailing list
>> geomesa-users@locationtechorg
>> To change your delivery options, retrieve your password, or unsubscribe
>> from this list, visit
>> http://www.locationtech.org/mailman/listinfo/geomesa-users
>
>
>
> _______________________________________________
> geomesa-users mailing list
> geomesa-users@xxxxxxxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit
> http://www.locationtech.org/mailman/listinfo/geomesa-users
_______________________________________________
geomesa-users mailing list
geomesa-users@xxxxxxxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
http://www.locationtech.org/mailman/listinfo/geomesa-users
|
