Date   

Re: Shared cache store for JG

Misha Brukman <mbru...@...>
 

+1 to optional, process-external, pluggable (multi-implementation) caching system.

I like Rafael's idea of decoupling serialization from objects by allowing custom marshall/unmarshall API — for example, if your Java objects are protocol buffers, the custom API lets you use the protobuf methods rather than Java object serialization methods, which may be faster.

On Wed, Jun 7, 2017 at 3:22 PM, Rafael Fernandes <luizr...@...> wrote:
Hi Tg,
We we've decided to implement a cache layer (a cache-as-a-service microservice layer) outside KCVS due to the control over the cache on our data.
We've tried Redis as well as Hazelcast, the later has performed around 3x faster than Redis using their client/server terminology. their auto discovery is also fantastic.

I love the idea of sharing the cache across multiple processes (we had to implement outside) I'd say we make it as generic as possible so we can plug other vendors like hazelcast.

as for point 1), 
not a fan of serializing all the object chain and state, some times is just too much work and we don't need all to be serialized, I'd say you make the caller implement a "marshall/unmarshal" method so you call it before sending it through the wire and restoring the state. being using this strategy for a while and it is faster, a lot faster.

point 2) 
oh yeah, we're all implementing caching all over the place, making it OOB, optional with many vendors is like a dream.

I'd be more than happy to implement the hazelcast version if we get up votes on this.

cheers,
rafa


On Tuesday, June 6, 2017 at 7:23:09 PM UTC-4, Tunay Gür wrote:
Hi JG Developers, 

We (uber) currently using JG in production with a multi-machine deployment. Even though each JG process are able to cache KeySliceQuery and results individually (db-cache), the fact that it's not shared among all the instances makes it less efficient. We thought we could get a better performance by replacing per-process/in-memory cache with a shared cache (ie. Redis + Twemproxy). Since I'm at the early stages of implementation I'd really appreciate any suggestions in this direction. Also I have the following particular questions. 

1. I'll be providing RedisKCVSCache.java which will be similar to ExpirationKCVSCache.java and make them both implement a common cache interface. ExpirationKCVSCache has the luxury to save the java objects directly since it's sitting inside the java process itself. However to be able to cache KeySliceQuery result objects (i.e ) I'm going to make them serializable. Any other suggestions here ? 

2. My initial benchmarks showed ~15x latency improvements with %100 cache utilization compared to a cassandra-backed/cache-disabled deployment. Overall perf gains look lucrative to us to invest in the implementation, however I'm still not sure if this can be a useful feature for other JG users. Are you aware of any interest for this kind of a feature ? 

Thanks 
-Tg

--
You received this message because you are subscribed to the Google Groups "JanusGraph developer list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgraph-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Shared cache store for JG

Rafael Fernandes <luizr...@...>
 

Hi Tg,
We we've decided to implement a cache layer (a cache-as-a-service microservice layer) outside KCVS due to the control over the cache on our data.
We've tried Redis as well as Hazelcast, the later has performed around 3x faster than Redis using their client/server terminology. their auto discovery is also fantastic.

I love the idea of sharing the cache across multiple processes (we had to implement outside) I'd say we make it as generic as possible so we can plug other vendors like hazelcast.

as for point 1), 
not a fan of serializing all the object chain and state, some times is just too much work and we don't need all to be serialized, I'd say you make the caller implement a "marshall/unmarshal" method so you call it before sending it through the wire and restoring the state. being using this strategy for a while and it is faster, a lot faster.

point 2) 
oh yeah, we're all implementing caching all over the place, making it OOB, optional with many vendors is like a dream.

I'd be more than happy to implement the hazelcast version if we get up votes on this.

cheers,
rafa


On Tuesday, June 6, 2017 at 7:23:09 PM UTC-4, Tunay Gür wrote:
Hi JG Developers, 

We (uber) currently using JG in production with a multi-machine deployment. Even though each JG process are able to cache KeySliceQuery and results individually (db-cache), the fact that it's not shared among all the instances makes it less efficient. We thought we could get a better performance by replacing per-process/in-memory cache with a shared cache (ie. Redis + Twemproxy). Since I'm at the early stages of implementation I'd really appreciate any suggestions in this direction. Also I have the following particular questions. 

1. I'll be providing RedisKCVSCache.java which will be similar to ExpirationKCVSCache.java and make them both implement a common cache interface. ExpirationKCVSCache has the luxury to save the java objects directly since it's sitting inside the java process itself. However to be able to cache KeySliceQuery result objects (i.e ) I'm going to make them serializable. Any other suggestions here ? 

2. My initial benchmarks showed ~15x latency improvements with %100 cache utilization compared to a cassandra-backed/cache-disabled deployment. Overall perf gains look lucrative to us to invest in the implementation, however I'm still not sure if this can be a useful feature for other JG users. Are you aware of any interest for this kind of a feature ? 

Thanks 
-Tg


Re: [WARNING] 0.1.0 to 0.1.1 upgrade

Alexander Patrikalakis <amcpatr...@...>
 

It seems like 0.2.0 is on the horizon for June/early July. If the next TinkerPop release slips, we may consider a 0.1.2 release to fix the JG 0.1.0 compatibility issue and include the following adjustment the DynamoDB backend would like to have:
https://github.com/JanusGraph/janusgraph/commit/5d9ebb46c0e11c57f9336e9f38057e6e3b2e49a5

Alex


On Thursday, May 18, 2017 at 12:19:05 PM UTC-10, Ted Wilmes wrote:
Hello,
A step was missed during the release prep and the 0.1.1 release was not marked as compatible with JanusGraph 0.1.0. Consequently, if you point 0.1.1 at a previously loaded 0.1.0 backend (not Titan), JanusGraph will not start and you'll get: 

"StorageBackend version is incompatible with current JanusGraph version: storage [0.1.0] vs. runtime [0.1.1]"

The backend format is not really incompatible and an issue has been entered to address this [1].

The 0.1.1 release mainly fixes a serious Titan compatibility issue [2] and if you are upgrading from Titan, you will not be affected by this incompatibility error and can upgrade because Janus is correctly marked as compatible with Titan 1.0 and Titan 1.1-SNAPSHOT.

If you are running 0.1.0 right now from a brand new JanusGraph load (not an upgrade from Titan), hold off on upgrading until this issues is taken care of. If you planned on rebuilding your data from scratch when upgrading to 0.1.1, you can go ahead and upgrade as this only affects a previously loaded system.

Thanks,
Ted


Re: Guided use of Lombok in JG?

Alexander Patrikalakis <amcpatr...@...>
 

What are the benefits for polyglot support Lombok lacks that JanusGraph-Core needs? I think a non-Java rewrite of JanusGraph is not on the radar of our short-term and medium-term roadmap.
Also, the service interface of JanusGraph is provided by Gremlin Server over HTTP and Websockets, not inside JanusGraph, so it also seems like supporting polyglot service front ends within JanusGraph-Core is out of scope.


On Tuesday, June 6, 2017 at 7:42:37 AM UTC-10, Henry Saputra wrote:
Thanks for taking the initiative, Kedar.

One problem from my experience with Lombok and other similar code generator-like framework its that it generates code that developers don't control without benefits for polyglot support like with Protobuf or Apache Thrift.

So, would love to see possible approach and which areas can be moved or leverage Lombok in JG codebase.

- Henry

On Tue, Jun 6, 2017 at 9:11 AM, 'Kedar Mhaswade' via JanusGraph developer list <janusgr...@googlegroups.com> wrote:
Dear Fellow JG developers,

Alex Patrikalakis (@amcp) thought (and I agree) that we should find out how this community thinks about a guided use of Project Lombok in JG codebase. IMO, we should perhaps define a subset of Lombok that are pretty useful at reducing the Java boilerplate and use the features from that subset consistently across the JG codebase.

I do not want this thread to become a flamewar, but if we all find Lombok as useful as others do, why not use its best parts while still retaining code clarity?

Depending upon your response, I will start two things:
1- a Wiki defining our approach/styleguide to Lombok's use in JG code. If we all feel that everything in Lombok (stable) could be used in JG code, then this wiki should say so, otherwise, it should encourage devs to use a few of its features and discourage them from using other (controversial) ones.
2- an issue that tries use of Lombok on a subset of packages. Others can then take up the use of Lombok in the areas they are familiar with.

Regards,
Kedar

--
You received this message because you are subscribed to the Google Groups "JanusGraph developer list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgraph-de...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Guided use of Lombok in JG?

Terry Moschou <tmos...@...>
 

Too bad JanusGraph wasn't written in Scala - boilerplate is kinda Java's thing right haha ;-p

First time I've heard of Lombok so I though I would try out their @Cleanup since in my experience ARM is usually implemented with unintended semantics. Looks like it allows exceptions thrown in finally-close() to mask any original exception currently throwing which isn't good and differs from java try-with-resource semantics (perhaps it came before Java 7?). I wouldn't recommend that feature at least.


On Wednesday, 7 June 2017 01:42:06 UTC+9:30, Kedar Mhaswade wrote:
Dear Fellow JG developers,

Alex Patrikalakis (@amcp) thought (and I agree) that we should find out how this community thinks about a guided use of Project Lombok in JG codebase. IMO, we should perhaps define a subset of Lombok that are pretty useful at reducing the Java boilerplate and use the features from that subset consistently across the JG codebase.

I do not want this thread to become a flamewar, but if we all find Lombok as useful as others do, why not use its best parts while still retaining code clarity?

Depending upon your response, I will start two things:
1- a Wiki defining our approach/styleguide to Lombok's use in JG code. If we all feel that everything in Lombok (stable) could be used in JG code, then this wiki should say so, otherwise, it should encourage devs to use a few of its features and discourage them from using other (controversial) ones.
2- an issue that tries use of Lombok on a subset of packages. Others can then take up the use of Lombok in the areas they are familiar with.

Regards,
Kedar


Shared cache store for JG

Tunay Gür <tuna...@...>
 

Hi JG Developers, 

We (uber) currently using JG in production with a multi-machine deployment. Even though each JG process are able to cache KeySliceQuery and results individually (db-cache), the fact that it's not shared among all the instances makes it less efficient. We thought we could get a better performance by replacing per-process/in-memory cache with a shared cache (ie. Redis + Twemproxy). Since I'm at the early stages of implementation I'd really appreciate any suggestions in this direction. Also I have the following particular questions. 

1. I'll be providing RedisKCVSCache.java which will be similar to ExpirationKCVSCache.java and make them both implement a common cache interface. ExpirationKCVSCache has the luxury to save the java objects directly since it's sitting inside the java process itself. However to be able to cache KeySliceQuery result objects (i.e StaticArrayEntryList) I'm going to make them serializable. Any other suggestions here ? 

2. My initial benchmarks showed ~15x latency improvements with %100 cache utilization compared to a cassandra-backed/cache-disabled deployment. Overall perf gains look lucrative to us to invest in the implementation, however I'm still not sure if this can be a useful feature for other JG users. Are you aware of any interest for this kind of a feature ? 

Thanks 
-Tg


Re: Guided use of Lombok in JG?

Henry Saputra <henry....@...>
 

Thanks for taking the initiative, Kedar.

One problem from my experience with Lombok and other similar code generator-like framework its that it generates code that developers don't control without benefits for polyglot support like with Protobuf or Apache Thrift.

So, would love to see possible approach and which areas can be moved or leverage Lombok in JG codebase.

- Henry

On Tue, Jun 6, 2017 at 9:11 AM, 'Kedar Mhaswade' via JanusGraph developer list <janusgr...@...> wrote:
Dear Fellow JG developers,

Alex Patrikalakis (@amcp) thought (and I agree) that we should find out how this community thinks about a guided use of Project Lombok in JG codebase. IMO, we should perhaps define a subset of Lombok that are pretty useful at reducing the Java boilerplate and use the features from that subset consistently across the JG codebase.

I do not want this thread to become a flamewar, but if we all find Lombok as useful as others do, why not use its best parts while still retaining code clarity?

Depending upon your response, I will start two things:
1- a Wiki defining our approach/styleguide to Lombok's use in JG code. If we all feel that everything in Lombok (stable) could be used in JG code, then this wiki should say so, otherwise, it should encourage devs to use a few of its features and discourage them from using other (controversial) ones.
2- an issue that tries use of Lombok on a subset of packages. Others can then take up the use of Lombok in the areas they are familiar with.

Regards,
Kedar

--
You received this message because you are subscribed to the Google Groups "JanusGraph developer list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgraph-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Guided use of Lombok in JG?

Kedar Mhaswade <ke...@...>
 

Dear Fellow JG developers,

Alex Patrikalakis (@amcp) thought (and I agree) that we should find out how this community thinks about a guided use of Project Lombok in JG codebase. IMO, we should perhaps define a subset of Lombok that are pretty useful at reducing the Java boilerplate and use the features from that subset consistently across the JG codebase.

I do not want this thread to become a flamewar, but if we all find Lombok as useful as others do, why not use its best parts while still retaining code clarity?

Depending upon your response, I will start two things:
1- a Wiki defining our approach/styleguide to Lombok's use in JG code. If we all feel that everything in Lombok (stable) could be used in JG code, then this wiki should say so, otherwise, it should encourage devs to use a few of its features and discourage them from using other (controversial) ones.
2- an issue that tries use of Lombok on a subset of packages. Others can then take up the use of Lombok in the areas they are familiar with.

Regards,
Kedar


Re: What's the plan for the next release?

Samik Raychaudhuri <sam...@...>
 

As mentioned, I reverted back to spark 1.6.1 and it works pretty well. I think we can stick with 1.6.1 till we move to TP 3.3, when that is available.

Regards,
-Samik

On 02-Jun-17 7:38 PM, Ted Wilmes wrote:

I think we'll need to stick with Spark 1.6.1 for now. Jason's plan also sounds good to me. The 3.2.5 TinkerPop bump should be pretty straightforward so we could probably target a late June, early July release for JanusGraph.

--Ted



Re: What's the plan for the next release?

Ted Wilmes <twi...@...>
 

I think we'll need to stick with Spark 1.6.1 for now. Jason's plan also sounds good to me. The 3.2.5 TinkerPop bump should be pretty straightforward so we could probably target a late June, early July release for JanusGraph.

--Ted

On Tuesday, May 30, 2017 at 2:00:59 PM UTC-5, Jerry He wrote:
It is a good plan from Jason. 

For the Spark support, based on the discussion link, it does not seem to be likely the Spark 2.x support will be back-ported to Tinkerpop 3.2.x. 
Without Tinkerpop 3.3, we will  have to live with Spark 1.6.1 for now in JanusGraph?

Thanks.

Jerry
 

On Saturday, May 27, 2017 at 8:03:19 AM UTC-7, Samik R wrote:
I recently tried using Spark 2.1.0 branch with Janusgraph for OLAP queries. Essentially, that entailed trying to compile spark-gremlin with Spark 2.1.0. I progressed a bit, but at the end, I was unable to successfully compile because of complex dependency structure.

I am not sure what is TP's plan for upgrading the version of spark. I wrote a post regarding that in the email list [https://groups.google.com/d/msgid/gremlin-users/1fd7a282-b18a-4b99-a436-f8448b1d7fe7%40googlegroups.com?utm_medium=email&utm_source=footer] but Stephen replied saying he is not aware of any plans.

In the end I reverted to using spark 1.6.1.

Regards,
-Samik

On 26-May-17 8:38 PM, Jason Plurad wrote:
You're right, I think the Cassandra and Elasticsearch bumps are the major items for the next release.

In mid-June there will be another TinkerPop release 3.2.5. I think it would be good to align a JanusGraph release relatively soon after that.

One item I want to get more focus on is which version of Spark to support or if we need to support multiple versions. If there are folks out there already doing Spark OLAP, what version are you using? Currently 1.6.1 is the supported version, but there are more recent versions available, and I'm not sure how easy it would be to support 2.0.x and 2.1.x.

Solr might need a bump -- any Solr folks out there want to chime in?


On Wednesday, May 24, 2017 at 11:17:50 AM UTC-4, Austin Sharp wrote:
Hi all,

I am pretty excited about the things getting merged into JanusGraph. In particular I really want to get my hands on the new CQL storage backend and the updated ElasticSearch indexing backend, since it'll take us a fair amount of work to get those integrated (i.e. upgrading existing installations of Cassandra and ES to much newer versions). In fact, we have logged bugs that get more or less instantly fixed by an upgrade.

So this leads me to ask: what's the plan for JanusGraph 0.2.0? As a Cassandra + ES user I feel like rewrites of both of those drivers is a pretty big deal, but those using other backends may feel differently. What's important to me is to have a timeline on when to expect the CQL + ES backends to be released, since if we don't get those in a certain time frame it'll mean finding ways to work around the problem.
--
You received this message because you are subscribed to the Google Groups "JanusGraph developer list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgraph-de...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Documentation updates on janusgraph.org

Christopher Quinones <therea...@...>
 

Here's a pull request with the documentation change I'd like to make: https://github.com/JanusGraph/janusgraph/pull/299.  It also includes an exception enhancement for the GraphOfTheGodsFactory (for the next release).

I do think it makes sense for the documentation entry-point to be the latest released version and allows users to select other stable versions we've released.  It'd be nice if we can patch the documentation to enhance it with changes that don't require a code change (like this one).


On Tuesday, May 30, 2017 at 5:51:07 PM UTC-4, Christopher Quinones wrote:
Hi everyone,

I'd like to contribute a blurb onto the getting-started tutorial indicating that it's possible to use the loadWithoutMixedIndex method when using a configuration that doesn't have an index backend enabled.

Is it possible to update the tutorial without publishing a brand new release?  I noticed that the documentation referenced 0.1.1 as the latest.

Thanks!


Re: Documentation updates on janusgraph.org

Jerry He <jerr...@...>
 

Hopefully everything is clear at first glance on the web site.
For example, people won't need a second look-up to know what the 'stable' is and points to which version.
If we have version 0.1.x, 0.2.x, and master, what will we provide on the web site for the docs?

Thanks.

Jerry

On Wed, May 31, 2017 at 12:36 PM, 'Misha Brukman' via JanusGraph developer list <janusgr...@...> wrote:
What about changing "latest" to point to the "latest version on GitHub (master)" and "stable" (or "release", or another name) pointing to the most-recent release?

Alternatively, "latest" can point to the latest release, and "snapshot" can point to latest version on GitHub. Thoughts?

On Wed, May 31, 2017 at 1:47 PM, Jerry He <jerr...@...> wrote:
Currently the http://docs.janusgraph.org/latest/ points to 0.1.1 version,  the same as the "Documentation (0.1.1)" link on the top of the site.

I like the ideal of providing a link to the master version of the docs.  I am fine with either 'latest' pointing to the master or 'latest' pointing to the last released version.
The important thing is we have to make it obviously distinguishable on the site.

Thanks,

Jerry

--
You received this message because you are subscribed to the Google Groups "JanusGraph developer list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgraph-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "JanusGraph developer list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgraph-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Documentation updates on janusgraph.org

Misha Brukman <mbru...@...>
 

What about changing "latest" to point to the "latest version on GitHub (master)" and "stable" (or "release", or another name) pointing to the most-recent release?

Alternatively, "latest" can point to the latest release, and "snapshot" can point to latest version on GitHub. Thoughts?

On Wed, May 31, 2017 at 1:47 PM, Jerry He <jerr...@...> wrote:
Currently the http://docs.janusgraph.org/latest/ points to 0.1.1 version,  the same as the "Documentation (0.1.1)" link on the top of the site.

I like the ideal of providing a link to the master version of the docs.  I am fine with either 'latest' pointing to the master or 'latest' pointing to the last released version.
The important thing is we have to make it obviously distinguishable on the site.

Thanks,

Jerry

--
You received this message because you are subscribed to the Google Groups "JanusGraph developer list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgraph-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Documentation updates on janusgraph.org

Jerry He <jerr...@...>
 

Currently the http://docs.janusgraph.org/latest/ points to 0.1.1 version,  the same as the "Documentation (0.1.1)" link on the top of the site.

I like the ideal of providing a link to the master version of the docs.  I am fine with either 'latest' pointing to the master or 'latest' pointing to the last released version.
The important thing is we have to make it obviously distinguishable on the site.

Thanks,

Jerry


Re: Documentation updates on janusgraph.org

Jason Plurad <plu...@...>
 

Publishing the snapshot documents is a nice convenience for feature developers. I'd rather have /latest/ pointing to the latest released version (for most users, i.e. those that aren't building a distribution from source code) and perhaps /snapshot/ pointing to latest from master (for feature developers, not indexed by web crawlers).


On Tuesday, May 30, 2017 at 5:56:04 PM UTC-4, Misha Brukman wrote:
Hi Christopher,

Go ahead and make the change on the master branch, and a new build of the docs will be published as soon as it's next built for an RC or SNAPSHOT or release. 

Right now, http://docs.janusgraph.org/latest/ points to the latest one of the above, which is currently "0.2.0-SNAPSHOT" as per the pom.xml, so we could technically publish that, and link "latest" to that as the directory.

What do others developers think?

Misha

On Tue, May 30, 2017 at 5:03 PM, Christopher Quinones wrote:
Hi everyone,

I'd like to contribute a blurb onto the getting-started tutorial indicating that it's possible to use the loadWithoutMixedIndex method when using a configuration that doesn't have an index backend enabled.

Is it possible to update the tutorial without publishing a brand new release?  I noticed that the documentation referenced 0.1.1 as the latest.

Thanks!

--
You received this message because you are subscribed to the Google Groups "JanusGraph developer list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgraph-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Documentation updates on janusgraph.org

Misha Brukman <mbru...@...>
 

Hi Christopher,

Go ahead and make the change on the master branch, and a new build of the docs will be published as soon as it's next built for an RC or SNAPSHOT or release. 

Right now, http://docs.janusgraph.org/latest/ points to the latest one of the above, which is currently "0.2.0-SNAPSHOT" as per the pom.xml, so we could technically publish that, and link "latest" to that as the directory.

What do others developers think?

Misha

On Tue, May 30, 2017 at 5:03 PM, Christopher Quinones <therea...@...> wrote:
Hi everyone,

I'd like to contribute a blurb onto the getting-started tutorial indicating that it's possible to use the loadWithoutMixedIndex method when using a configuration that doesn't have an index backend enabled.

Is it possible to update the tutorial without publishing a brand new release?  I noticed that the documentation referenced 0.1.1 as the latest.

Thanks!

--
You received this message because you are subscribed to the Google Groups "JanusGraph developer list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgraph-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Documentation updates on janusgraph.org

Christopher Quinones <therea...@...>
 

Hi everyone,

I'd like to contribute a blurb onto the getting-started tutorial indicating that it's possible to use the loadWithoutMixedIndex method when using a configuration that doesn't have an index backend enabled.

Is it possible to update the tutorial without publishing a brand new release?  I noticed that the documentation referenced 0.1.1 as the latest.

Thanks!


Re: What's the plan for the next release?

Jerry He <jerr...@...>
 

It is a good plan from Jason. 

For the Spark support, based on the discussion link, it does not seem to be likely the Spark 2.x support will be back-ported to Tinkerpop 3.2.x. 
Without Tinkerpop 3.3, we will  have to live with Spark 1.6.1 for now in JanusGraph?

Thanks.

Jerry
 


On Saturday, May 27, 2017 at 8:03:19 AM UTC-7, Samik R wrote:
I recently tried using Spark 2.1.0 branch with Janusgraph for OLAP queries. Essentially, that entailed trying to compile spark-gremlin with Spark 2.1.0. I progressed a bit, but at the end, I was unable to successfully compile because of complex dependency structure.

I am not sure what is TP's plan for upgrading the version of spark. I wrote a post regarding that in the email list [https://groups.google.com/d/msgid/gremlin-users/1fd7a282-b18a-4b99-a436-f8448b1d7fe7%40googlegroups.com?utm_medium=email&utm_source=footer] but Stephen replied saying he is not aware of any plans.

In the end I reverted to using spark 1.6.1.

Regards,
-Samik

On 26-May-17 8:38 PM, Jason Plurad wrote:
You're right, I think the Cassandra and Elasticsearch bumps are the major items for the next release.

In mid-June there will be another TinkerPop release 3.2.5. I think it would be good to align a JanusGraph release relatively soon after that.

One item I want to get more focus on is which version of Spark to support or if we need to support multiple versions. If there are folks out there already doing Spark OLAP, what version are you using? Currently 1.6.1 is the supported version, but there are more recent versions available, and I'm not sure how easy it would be to support 2.0.x and 2.1.x.

Solr might need a bump -- any Solr folks out there want to chime in?


On Wednesday, May 24, 2017 at 11:17:50 AM UTC-4, Austin Sharp wrote:
Hi all,

I am pretty excited about the things getting merged into JanusGraph. In particular I really want to get my hands on the new CQL storage backend and the updated ElasticSearch indexing backend, since it'll take us a fair amount of work to get those integrated (i.e. upgrading existing installations of Cassandra and ES to much newer versions). In fact, we have logged bugs that get more or less instantly fixed by an upgrade.

So this leads me to ask: what's the plan for JanusGraph 0.2.0? As a Cassandra + ES user I feel like rewrites of both of those drivers is a pretty big deal, but those using other backends may feel differently. What's important to me is to have a timeline on when to expect the CQL + ES backends to be released, since if we don't get those in a certain time frame it'll mean finding ways to work around the problem.
--
You received this message because you are subscribed to the Google Groups "JanusGraph developer list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgraph-de...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: What's the plan for the next release?

Samik Raychaudhuri <sam...@...>
 

I recently tried using Spark 2.1.0 branch with Janusgraph for OLAP queries. Essentially, that entailed trying to compile spark-gremlin with Spark 2.1.0. I progressed a bit, but at the end, I was unable to successfully compile because of complex dependency structure.

I am not sure what is TP's plan for upgrading the version of spark. I wrote a post regarding that in the email list [https://groups.google.com/d/msgid/gremlin-users/1fd7a282-b18a-4b99-a436-f8448b1d7fe7%40googlegroups.com?utm_medium=email&utm_source=footer] but Stephen replied saying he is not aware of any plans.

In the end I reverted to using spark 1.6.1.

Regards,
-Samik

On 26-May-17 8:38 PM, Jason Plurad wrote:

You're right, I think the Cassandra and Elasticsearch bumps are the major items for the next release.

In mid-June there will be another TinkerPop release 3.2.5. I think it would be good to align a JanusGraph release relatively soon after that.

One item I want to get more focus on is which version of Spark to support or if we need to support multiple versions. If there are folks out there already doing Spark OLAP, what version are you using? Currently 1.6.1 is the supported version, but there are more recent versions available, and I'm not sure how easy it would be to support 2.0.x and 2.1.x.

Solr might need a bump -- any Solr folks out there want to chime in?


On Wednesday, May 24, 2017 at 11:17:50 AM UTC-4, Austin Sharp wrote:
Hi all,

I am pretty excited about the things getting merged into JanusGraph. In particular I really want to get my hands on the new CQL storage backend and the updated ElasticSearch indexing backend, since it'll take us a fair amount of work to get those integrated (i.e. upgrading existing installations of Cassandra and ES to much newer versions). In fact, we have logged bugs that get more or less instantly fixed by an upgrade.

So this leads me to ask: what's the plan for JanusGraph 0.2.0? As a Cassandra + ES user I feel like rewrites of both of those drivers is a pretty big deal, but those using other backends may feel differently. What's important to me is to have a timeline on when to expect the CQL + ES backends to be released, since if we don't get those in a certain time frame it'll mean finding ways to work around the problem.
--
You received this message because you are subscribed to the Google Groups "JanusGraph developer list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgr...@....
For more options, visit https://groups.google.com/d/optout.


Re: What's the plan for the next release?

Jason Plurad <plu...@...>
 

You're right, I think the Cassandra and Elasticsearch bumps are the major items for the next release.

In mid-June there will be another TinkerPop release 3.2.5. I think it would be good to align a JanusGraph release relatively soon after that.

One item I want to get more focus on is which version of Spark to support or if we need to support multiple versions. If there are folks out there already doing Spark OLAP, what version are you using? Currently 1.6.1 is the supported version, but there are more recent versions available, and I'm not sure how easy it would be to support 2.0.x and 2.1.x.

Solr might need a bump -- any Solr folks out there want to chime in?


On Wednesday, May 24, 2017 at 11:17:50 AM UTC-4, Austin Sharp wrote:
Hi all,

I am pretty excited about the things getting merged into JanusGraph. In particular I really want to get my hands on the new CQL storage backend and the updated ElasticSearch indexing backend, since it'll take us a fair amount of work to get those integrated (i.e. upgrading existing installations of Cassandra and ES to much newer versions). In fact, we have logged bugs that get more or less instantly fixed by an upgrade.

So this leads me to ask: what's the plan for JanusGraph 0.2.0? As a Cassandra + ES user I feel like rewrites of both of those drivers is a pretty big deal, but those using other backends may feel differently. What's important to me is to have a timeline on when to expect the CQL + ES backends to be released, since if we don't get those in a certain time frame it'll mean finding ways to work around the problem.

1321 - 1340 of 1585