Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [geomesa-users] GeoMesa 1.2.2

Hi Diane,

I believe that there is a jar mismatch somewhere. You shouldn't need to do any intermediate updates to go from 1.2.0 to 1.2.2. Could you list the jars you currently have in your geoserver lib folder?

Thanks,

Emilio

On 05/20/2016 02:02 PM, Diane Griffith wrote:

I did attempt to upgrade one of the existing systems to this version for that fix for indexed columns and the IN clause. 

 

The geotools version seemed to match fine.  It was a working system running against accumulo 1.6.0 and using GeoMesa 1.2.0 and GeoServer 2.8.1  I built from source and I am attempting to go from GeoMesa 1.2.0 to GeoMesa 1.2.2. 

 

It did not work, I cannot render data via geoserver currently.

 

I shut everything down and placed the geomesa-accumulo-distributed-runtime-1.2.2.jar on the accumulo tablet servers and removed the 1.2.0 version of that jar.

 

For GeoServer I had taken the current war and then overlayed the jars in the geomea-accumulo-gs-plugin-1.2.2-install.tar.gz into the existing geoservers WEB-INF/lib directory.  I removed any of the 1.2.0 based geomesa jars,  I believe for imageio*, I had to delete some older jars for that to be replaced by a newer version of those same jars.  I also noticed that the one jar, geomesa-utils-gs-plugin-1.2.0.jar, seemed to become geomesa-utils-1.2.2.jar.  (It is a class in this jar that is giving me issues on retrieving data via GeoServer to render as a WMS tile.) and then started up accumulo stack and then geoserver.

 

So when I took an existing configured geoserver layer (backed by an existing geomesa accumulo store) and tried to render the data I got a stacktrace that basically started as:

 

[geotools.rendering] – org.locationtech.geomesa.utils.geotools.SimpleFeatureTypes$.encodeType(Lorg/opengis/feature/simpleFeatureType;)Ljava/lang/String;

Java.lang.NoSuchMethodError: org.locationtech.geomesa.utils.gotools.SimpleFeatureTypes$.encodeType(Lorg/opengis/feature/simple/SimpleFeatureType;)Ljava/jang/String;

     at org.locationtech.geomesa.accumulo.index.Strategy$.conifgureFeatureType(Strategy.scala:141)

     at org.locationtech.geomesa.accumulo.index.STIdxStrategy$$anonfun$conifgureIndexIterator$1.apply(STIdxStrategy.scala:177)

     at org.locationtech.geomesa.accumulo.index.STIdxStrategy$$anonfun$conifgureIndexIterator$1.apply(STIdxStrategy.scala:177)

     at scala.Option.foreach(Option.scala:257)

     at org.locationtech.geomesa.accumulo.index.STIdxStrategy.conifgureIndexIterator (STIdxStrategy.scala:177)

     ….

 

When I tried to configure a new store and layer in GeoServer to an already ingested GeoMesa table it gave the same error.  I then ingested new data again (ingested fine).  Configured another new store and layer in GeoServer but got the same error.

 

So in looking at that class, SimpleFeatureType.scala

 

In 1.2.0

 

def encodeType(sft: SimpleFeatureType): String =

….

 

In 1.2.2

def encodeType(sft: SimpleFeatureType, includeUserData: Boolean = false): String = {

 

So there is a difference in signature.

 

I have not been able to find that I didn’t upgrade something correctly.  Did I need to go from 1.2.0->1.2.1->1.2.2 or does that suggest something I missed when I rolled the upgraded jars out? 

 

Thanks,

Diane

 

On 05/19/2016 12:46 PM, Emilio Lahr-Vivaz wrote:

> 

>Hi Diane,

> 

>TL/DR: all versions of GeoMesa should be backwards compatible going back to around Mar 30, 2015 (you need to make sure your >jar versions match across all your clients/servers, though).

> 

>That said, we often improve our indexing, which you won't be able to take advantage of without migrating or re-ingesting your >data. If you're interested in migrating it, we have a map/reduce job that you can run, detailed here:

> 

>http://www.geomesa.org/documentation/developer/modules/geomesa-jobs.html#updating-existing-data-to-the-latest-index->format

> 

>The Z2 index is a case where we have improved our indexing - for spatial-only queries, the new index tends to be 2-4 times faster >than the old geohash index, so it might be worthwhile to re-ingest.

> 

>Thanks,

> 

>Emilio

> 

>On 05/19/2016 12:26 PM, Diane Griffith wrote:

> 

> Jim,

> 

> 

> What does the following in the release change log of 1.2.2 mean:

> 

> 

> * GeoHash index replaced with a Z2 index.

> 

> 

> Will everything (GeoServer store querying data from existing ingested code under 1.2.0) sill work once I upgrade both the accumulo side and libraries in GeoServer?

> 

> 

> Will I need to re-ingest for a new index once I upgrade?

> 

> 

> Or if I wanted to add data to the existing feature I already set up, will I have to change my ingest code (does it still support the old index)?

> 

> 

> If there is a specific example that helps me understand this part of the new release let me know.

> 

> 

> Thanks,

> 

> Diane



_______________________________________________
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


Back to the top