Date   

Re: [DISCUSS] Move to GitHub Actions

Jan....@...
 

Hi

I’m pretty sure about our limitations, which are just 20 concurrent runner at the same time for all public repos. The 2000 minutes are just for private repos (no build time limit for public repos).

Greetings, 
Jan 

On 19. Nov 2020, at 21:55, Oleksandr Porunov <alexan...@...> wrote:


Hi,

Moving to GitHub actions seems to be a good idea but we need to understand our limitations. This link says that GitHub actions gives us 2000 minutes per month:
https://docs.github.com/en/free-pro-team@latest/github/setting-up-and-managing-billing-and-payments-on-github/about-billing-for-github-actions

Best regards,
Oleksandr
On Wednesday, November 18, 2020 at 12:24:51 PM UTC+2 fa...@... wrote:
Hi

I did a small evaluation of GitHub Actions in February. GitHub Actions didn't allowed to run to open source project unlimited time at this time. This changed in April.

Old results can be found here.

Greetings,
Jan

On Wednesday, November 18, 2020 at 11:05:41 AM UTC+1 Florian Hockmann wrote:
Hi,

Travis CI has recently announced that they will only offer 1000 build minutes / month for OSS projects. Given that our builds currently take ~10h, we would only be able to execute around 2 builds per month of our main repository. While the linked
blog post also mentions the possibility to request more free build minutes, I'm not sure whether we want to rely on that and how realistic it is that they will provide us with enough build minutes. (Just to give an example: We would need around 50,000 build minutes per month to be able to execute 3 builds per day.)

To make matters worse, we're still on travis-ci.org which will be abandoned at the end of this year in favor of travis-ci.com. So, even if we want to stay with Travis, we would need to migrate our projects over from travis-ci.org to travis-ci.com.

Given these policy changes by Travis CI, I propose that we migrate to GitHub Actions which seems to be much more OSS friendly nowadays and which probably also allows us to better parallelize and therefore speed up our builds. It allows up to 20 concurrent jobs with a maximum runtime of 6h per job. This should also make it easier to execute the TinkerPop tests for more backends.

Any thoughts or concerns on this topic?


PS: For a bit more context about the changes in Travis CI for OSS projects, I recommend this blog post which made me aware of this in the first place.

--
You received this message because you are subscribed to the Google Groups "JanusGraph developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgraph-dev+unsu...@....
To view this discussion on the web visit https://groups.google.com/d/msgid/janusgraph-dev/7fd40424-814e-4afd-abe6-70834a5d5b94n%40googlegroups.com.


Re: [DISCUSS] Move to GitHub Actions

Oleksandr Porunov <alexand...@...>
 

Hi,

Moving to GitHub actions seems to be a good idea but we need to understand our limitations. This link says that GitHub actions gives us 2000 minutes per month:
https://docs.github.com/en/free-pro-team@latest/github/setting-up-and-managing-billing-and-payments-on-github/about-billing-for-github-actions

Best regards,
Oleksandr

On Wednesday, November 18, 2020 at 12:24:51 PM UTC+2 fa...@... wrote:
Hi

I did a small evaluation of GitHub Actions in February. GitHub Actions didn't allowed to run to open source project unlimited time at this time. This changed in April.

Old results can be found here.

Greetings,
Jan

On Wednesday, November 18, 2020 at 11:05:41 AM UTC+1 Florian Hockmann wrote:
Hi,

Travis CI has recently announced that they will only offer 1000 build minutes / month for OSS projects. Given that our builds currently take ~10h, we would only be able to execute around 2 builds per month of our main repository. While the linked
blog post also mentions the possibility to request more free build minutes, I'm not sure whether we want to rely on that and how realistic it is that they will provide us with enough build minutes. (Just to give an example: We would need around 50,000 build minutes per month to be able to execute 3 builds per day.)

To make matters worse, we're still on travis-ci.org which will be abandoned at the end of this year in favor of travis-ci.com. So, even if we want to stay with Travis, we would need to migrate our projects over from travis-ci.org to travis-ci.com.

Given these policy changes by Travis CI, I propose that we migrate to GitHub Actions which seems to be much more OSS friendly nowadays and which probably also allows us to better parallelize and therefore speed up our builds. It allows up to 20 concurrent jobs with a maximum runtime of 6h per job. This should also make it easier to execute the TinkerPop tests for more backends.

Any thoughts or concerns on this topic?


PS: For a bit more context about the changes in Travis CI for OSS projects, I recommend this blog post which made me aware of this in the first place.


Re: To Contribute Our Code Enhancement Back to JanusGraph-FoundationDB Storage Plugin

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

Just noticed this one.

Congrats, Jun Li and Hieu Nguyen

It is great to see the hard work done inside eBay can be shared with the community!

- Henry


On Sun, Oct 4, 2020 at 7:11 AM Jun Li <jltz9...@...> wrote:

Hello,

In eBay, we now have JanusGraph deployed in production, with FoundationDB being the backend store. The details on the design, deployment and the eBay use cases can be found in last year’s FoundationDB Summit (https://www.youtube.com/watch?v=EtB1BPG00PE). We took the earlier version of JanusGraph-FoundationDB plugin developed by Ted Wilmes in February 2019, and have made bug fixing and improvement over the last two years.  Now we would like to contribute our code back to the open source community, with the following improved features:

(1)Some bug fixing for the current JanusGraph FoundationDB plugin, and support of Async. Iterator. With Asynchronous Iterator, we can greatly leverage FoundationDB’s Asynchronous Iterator in terms of on-demand data stream pulling, better memory efficiency, better parallelism for MultiQuery support. We introduce “iterator” mode, along with the current mode that we call “list” mode.

(2)Enable Prefetching on Global Read Version of FoundationDB. This allows read-only query to use a slightly delayed GRV for snap-shot read (configurable, say 100 ms delayed), but save the GRV fetching time from the Primary DC. In the cross-datacenter production environment, the saving can be as large as > 50 ms due to this GRV pre-fetching.

(3) Support Read-Only GraphDB from the specified environment variables at GraphDB engine start-up.

(4)Context propagation that allows the Client Application to express “read-only” optimization support from Feature 2 mentioned above, to the FoundationDB storage plugin. So that write-involved queries will not be optimized. Furthermore, we can allow transaction reset with “read-commit-write” mode to be per-transaction, and only for the “read-only” queries, further optimization for “read-only” queries.The write-involved queries will still follow "serializable" mode for strong consistency.

(5)Enable TLS that is supported by FoundationDB. Security is important in the production environment.

(6)Enable Prometheus Metrics Monitoring. So that we can have good visibility across multiple datacenter deployment in the production environment. From the metrics collected, dashboards and alerts can be further developed easily. We can share our Grafana dashboards JSON configuration files and Prometheus alert rules used in our production environment  to the open-source community also. 

The first PR on Feature 1 above can be found at: https://github.com/JanusGraph/janusgraph-foundationdb/pull/50

Regards,

Jun Li and Hieu Nguyen



--
You received this message because you are subscribed to the Google Groups "JanusGraph developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgr...@....
To view this discussion on the web visit https://groups.google.com/d/msgid/janusgraph-dev/43fd48ac-9211-48ee-a1ea-240354010dc2n%40googlegroups.com.


Re: [DISCUSS] Move to GitHub Actions

"fa...@googlemail.com" <faro...@...>
 

Hi

I did a small evaluation of GitHub Actions in February. GitHub Actions didn't allowed to run to open source project unlimited time at this time. This changed in April.

Old results can be found here.

Greetings,
Jan

On Wednesday, November 18, 2020 at 11:05:41 AM UTC+1 Florian Hockmann wrote:
Hi,

Travis CI has recently announced that they will only offer 1000 build minutes / month for OSS projects. Given that our builds currently take ~10h, we would only be able to execute around 2 builds per month of our main repository. While the linked
blog post also mentions the possibility to request more free build minutes, I'm not sure whether we want to rely on that and how realistic it is that they will provide us with enough build minutes. (Just to give an example: We would need around 50,000 build minutes per month to be able to execute 3 builds per day.)

To make matters worse, we're still on travis-ci.org which will be abandoned at the end of this year in favor of travis-ci.com. So, even if we want to stay with Travis, we would need to migrate our projects over from travis-ci.org to travis-ci.com.

Given these policy changes by Travis CI, I propose that we migrate to GitHub Actions which seems to be much more OSS friendly nowadays and which probably also allows us to better parallelize and therefore speed up our builds. It allows up to 20 concurrent jobs with a maximum runtime of 6h per job. This should also make it easier to execute the TinkerPop tests for more backends.

Any thoughts or concerns on this topic?


PS: For a bit more context about the changes in Travis CI for OSS projects, I recommend this blog post which made me aware of this in the first place.


[DISCUSS] Move to GitHub Actions

Florian Hockmann <f...@...>
 

Hi,

Travis CI has recently announced that they will only offer 1000 build minutes / month for OSS projects. Given that our builds currently take ~10h, we would only be able to execute around 2 builds per month of our main repository. While the linked
blog post also mentions the possibility to request more free build minutes, I'm not sure whether we want to rely on that and how realistic it is that they will provide us with enough build minutes. (Just to give an example: We would need around 50,000 build minutes per month to be able to execute 3 builds per day.)

To make matters worse, we're still on travis-ci.org which will be abandoned at the end of this year in favor of travis-ci.com. So, even if we want to stay with Travis, we would need to migrate our projects over from travis-ci.org to travis-ci.com.

Given these policy changes by Travis CI, I propose that we migrate to GitHub Actions which seems to be much more OSS friendly nowadays and which probably also allows us to better parallelize and therefore speed up our builds. It allows up to 20 concurrent jobs with a maximum runtime of 6h per job. This should also make it easier to execute the TinkerPop tests for more backends.

Any thoughts or concerns on this topic?


PS: For a bit more context about the changes in Travis CI for OSS projects, I recommend this blog post which made me aware of this in the first place.


Re: JanusGraph Community Meetup - September 30, 2020

Oleksandr Porunov <alexand...@...>
 

Hi Ted,

It would be great if you could add recording to https://github.com/JanusGraph/janusgraph.org

Best regards,
Oleksandr

On Wednesday, October 14, 2020 at 3:57:58 PM UTC+3 f....@... wrote:
Hi Ted,
have you already uploaded the recording of the meetup?

t...@... schrieb am Dienstag, 29. September 2020 um 23:51:51 UTC+2:
Hello,
Quick FYI, the date for this meetup has been moved to October 7th at 1 PM Central. Sign ups can still be made here: https://www.experoinc.com/get/janusgraph-user-group

Thanks,
Ted

On Wed, Sep 23, 2020 at 12:55 PM Ted Wilmes <t...@...> wrote:
Hello,
Expero Inc. will be hosting a JanusGraph community meetup one week from today on Wednesday, September 30th at 11 AM Central time. If you are interested in attending, you can sign up here: https://www.experoinc.com/get/janusgraph-user-group.

There will be two speakers discussing JanusGraph query optimization and how to manage multiple graphs from a single JanusGraph install along with a roundtable Q&A where we'll field JanusGraph questions from attendees.

Thanks,
Ted


Confusion with "Lock write succeeded but took too long" warning

"c...@gmail.com" <cjx...@...>
 

Environment: JG-0.5.2 with HBase and Elasticsearch

When running a java program to delete verteics and edges, many warnings "Lock write succeeded but took too long" show up.

Wanting to know what happens, I check the code and got confused,

@Override
protected ConsistentKeyLockStatus writeSingleLock(KeyColumn lockID, StoreTransaction txh) throws Throwable {

final StaticBuffer lockKey = serializer.toLockKey(lockID.getKey(), lockID.getColumn());
StaticBuffer oldLockCol = null;

for (int i = 0; i < lockRetryCount; i++) {
WriteResult wr = tryWriteLockOnce(lockKey, oldLockCol, txh);
if (wr.isSuccessful() && wr.getDuration().compareTo(lockWait) <= 0) {
final Instant writeInstant = wr.getWriteTimestamp();
final Instant expireInstant = writeInstant.plus(lockExpire);
return new ConsistentKeyLockStatus(writeInstant, expireInstant);
}
oldLockCol = wr.getLockCol();
handleMutationFailure(lockID, lockKey, wr, txh);
}
tryDeleteLockOnce(lockKey, oldLockCol, txh);
// TODO log exception or successful too-slow write here
throw new TemporaryBackendException("Lock write retry count exceeded");
}


In the code shown above, when wr.getDuration()  greater than lockWait, the warning "Lock write succeeded but took too long" will be printed, and than continue the for loop until to limit.  

And my confusion is that why we continue the for loop when the write is successful (even though it took too long, it's still a successful operation, right?)

Any help would be greatly appreciated.


Re: New committer: Florian Grieskamp

赵春亮 <pkz...@...>
 

welcome

At 2020-10-17 07:38:15, "Henry Saputra" <henr...@...> wrote:

Just read about this, welcome Florian.

- Henry

On Fri, Sep 11, 2020 at 2:25 AM Oleksandr Porunov <alexand...@...> wrote:

On behalf of the JanusGraph Technical Steering Committee (TSC), I'm pleased to welcome a new committer on the project!

Florian Grieskamp has been a solid contributor. He already contributed many performance improvements, contributions to janusgraph-foundationdb and provided many PR reviews.


Congratulations, Florian Grieskamp!

--
You received this message because you are subscribed to the Google Groups "JanusGraph developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgr...@....
To view this discussion on the web visit https://groups.google.com/d/msgid/janusgraph-dev/094bed1e-7b13-49bc-aca2-249bace3834dn%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "JanusGraph developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgr...@....
To view this discussion on the web visit https://groups.google.com/d/msgid/janusgraph-dev/CALuGr6Yq%2B0RZRZ151Xh7F7LWHSgA4DbSEdmXtD9bBZnT-Gakzw%40mail.gmail.com.


 


Re: New committer: Florian Grieskamp

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

Just read about this, welcome Florian.

- Henry

On Fri, Sep 11, 2020 at 2:25 AM Oleksandr Porunov <alexand...@...> wrote:

On behalf of the JanusGraph Technical Steering Committee (TSC), I'm pleased to welcome a new committer on the project!

Florian Grieskamp has been a solid contributor. He already contributed many performance improvements, contributions to janusgraph-foundationdb and provided many PR reviews.


Congratulations, Florian Grieskamp!

--
You received this message because you are subscribed to the Google Groups "JanusGraph developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgr...@....
To view this discussion on the web visit https://groups.google.com/d/msgid/janusgraph-dev/094bed1e-7b13-49bc-aca2-249bace3834dn%40googlegroups.com.


To Introduce Transaction Context to Allow Per-Transaction Configuration In JanusGraph Storage Plugin #2238

Jun Li <jltz9...@...>
 

Hi All,

As I am working on the feature improvement on JanusGraph-FoundationDB storage plugin, I found the need to introduce per-transaction configuration via a Transaction Context object. I have submitted the new API feature needed at  https://github.com/JanusGraph/janusgraph/issues/2238

As a summary, in JanusGraph-FoundationDB storage plugin, we like to have the following features to greatly improve functionality and performance:

*Allow the application to provide the hint that “the query is read-only” and thus we can use pre-fetching Global Read Version (GRV) to reduce query latency. In 3-datacenter deployment, we found that query latency can be reduced with 50 ms from this optimization.
*Allow the application to choose different transaction modes. The “serializable” mode is desired for “write-related queries”, but for “read-only queries”, the application may choose “read_committed_with_write” mode to circumvent the 5-second transaction time limit imposed by FoundationDB today.

To achieve the above improvement, we will need to have a Transaction Context object to be associated with the JanusGraph Transaction, so that the above query optimization configuration parameters can be specified in the Transaction Context and is associated with each individual transaction (query). Note that read-only queries and write-related queries can concurrently be processed in the same Graphdb.

Today, all of the JanusGraph configuration parameters are set at the JanusGraph process start-time from the property file “janusgraph.properties” or from the “store features” set by the Store Manager. Both mechanisms can not support per-transaction customization.

The proposed change is on JanusGraphTransaction interface to have two additional methods:

//defined in org.janusgraph.core 

interface Transaction { 

 void setContext (TransactionContext context); 

TransactionContext getContext(); 

 }

More detail can be found at: https://github.com/JanusGraph/janusgraph/issues/2238

What do you think about this suggested API feature  to allow big performance improvement over the distributed transaction backend store?

Regards,

Jun



Re: JanusGraph Community Meetup - September 30, 2020

Florian Grieskamp <f.gri...@...>
 

Hi Ted,
have you already uploaded the recording of the meetup?

t...@... schrieb am Dienstag, 29. September 2020 um 23:51:51 UTC+2:

Hello,
Quick FYI, the date for this meetup has been moved to October 7th at 1 PM Central. Sign ups can still be made here: https://www.experoinc.com/get/janusgraph-user-group

Thanks,
Ted

On Wed, Sep 23, 2020 at 12:55 PM Ted Wilmes <t...@...> wrote:
Hello,
Expero Inc. will be hosting a JanusGraph community meetup one week from today on Wednesday, September 30th at 11 AM Central time. If you are interested in attending, you can sign up here: https://www.experoinc.com/get/janusgraph-user-group.

There will be two speakers discussing JanusGraph query optimization and how to manage multiple graphs from a single JanusGraph install along with a roundtable Q&A where we'll field JanusGraph questions from attendees.

Thanks,
Ted


Re: To Contribute Our Code Enhancement Back to JanusGraph-FoundationDB Storage Plugin

Florian Grieskamp <f.gri...@...>
 

+1 Thank you for sharing your improvements with the JanusGraph community. From what you describe, the storage adapter will substantially profit of your modifications. I'm looking forward to have a closer look at it and rewiew the PR in detail. I'm very excited about the iterator mode, which sounds like a great idea!
jacks...@... schrieb am Dienstag, 6. Oktober 2020 um 16:22:13 UTC+2:

These all are welcome contributions, thanks so much for taking the time to share these with the community it's greatly appreciated! 

On Sunday, October 4, 2020 at 10:11:39 AM UTC-4 Jun Li wrote:

Hello,

In eBay, we now have JanusGraph deployed in production, with FoundationDB being the backend store. The details on the design, deployment and the eBay use cases can be found in last year’s FoundationDB Summit (https://www.youtube.com/watch?v=EtB1BPG00PE). We took the earlier version of JanusGraph-FoundationDB plugin developed by Ted Wilmes in February 2019, and have made bug fixing and improvement over the last two years.  Now we would like to contribute our code back to the open source community, with the following improved features:

(1)Some bug fixing for the current JanusGraph FoundationDB plugin, and support of Async. Iterator. With Asynchronous Iterator, we can greatly leverage FoundationDB’s Asynchronous Iterator in terms of on-demand data stream pulling, better memory efficiency, better parallelism for MultiQuery support. We introduce “iterator” mode, along with the current mode that we call “list” mode.

(2)Enable Prefetching on Global Read Version of FoundationDB. This allows read-only query to use a slightly delayed GRV for snap-shot read (configurable, say 100 ms delayed), but save the GRV fetching time from the Primary DC. In the cross-datacenter production environment, the saving can be as large as > 50 ms due to this GRV pre-fetching.

(3) Support Read-Only GraphDB from the specified environment variables at GraphDB engine start-up.

(4)Context propagation that allows the Client Application to express “read-only” optimization support from Feature 2 mentioned above, to the FoundationDB storage plugin. So that write-involved queries will not be optimized. Furthermore, we can allow transaction reset with “read-commit-write” mode to be per-transaction, and only for the “read-only” queries, further optimization for “read-only” queries.The write-involved queries will still follow "serializable" mode for strong consistency.

(5)Enable TLS that is supported by FoundationDB. Security is important in the production environment.

(6)Enable Prometheus Metrics Monitoring. So that we can have good visibility across multiple datacenter deployment in the production environment. From the metrics collected, dashboards and alerts can be further developed easily. We can share our Grafana dashboards JSON configuration files and Prometheus alert rules used in our production environment  to the open-source community also. 

The first PR on Feature 1 above can be found at: https://github.com/JanusGraph/janusgraph-foundationdb/pull/50

Regards,

Jun Li and Hieu Nguyen




Re: To Contribute Our Code Enhancement Back to JanusGraph-FoundationDB Storage Plugin

"jacks...@gmail.com" <jackson.ch...@...>
 

These all are welcome contributions, thanks so much for taking the time to share these with the community it's greatly appreciated! 


On Sunday, October 4, 2020 at 10:11:39 AM UTC-4 Jun Li wrote:

Hello,

In eBay, we now have JanusGraph deployed in production, with FoundationDB being the backend store. The details on the design, deployment and the eBay use cases can be found in last year’s FoundationDB Summit (https://www.youtube.com/watch?v=EtB1BPG00PE). We took the earlier version of JanusGraph-FoundationDB plugin developed by Ted Wilmes in February 2019, and have made bug fixing and improvement over the last two years.  Now we would like to contribute our code back to the open source community, with the following improved features:

(1)Some bug fixing for the current JanusGraph FoundationDB plugin, and support of Async. Iterator. With Asynchronous Iterator, we can greatly leverage FoundationDB’s Asynchronous Iterator in terms of on-demand data stream pulling, better memory efficiency, better parallelism for MultiQuery support. We introduce “iterator” mode, along with the current mode that we call “list” mode.

(2)Enable Prefetching on Global Read Version of FoundationDB. This allows read-only query to use a slightly delayed GRV for snap-shot read (configurable, say 100 ms delayed), but save the GRV fetching time from the Primary DC. In the cross-datacenter production environment, the saving can be as large as > 50 ms due to this GRV pre-fetching.

(3) Support Read-Only GraphDB from the specified environment variables at GraphDB engine start-up.

(4)Context propagation that allows the Client Application to express “read-only” optimization support from Feature 2 mentioned above, to the FoundationDB storage plugin. So that write-involved queries will not be optimized. Furthermore, we can allow transaction reset with “read-commit-write” mode to be per-transaction, and only for the “read-only” queries, further optimization for “read-only” queries.The write-involved queries will still follow "serializable" mode for strong consistency.

(5)Enable TLS that is supported by FoundationDB. Security is important in the production environment.

(6)Enable Prometheus Metrics Monitoring. So that we can have good visibility across multiple datacenter deployment in the production environment. From the metrics collected, dashboards and alerts can be further developed easily. We can share our Grafana dashboards JSON configuration files and Prometheus alert rules used in our production environment  to the open-source community also. 

The first PR on Feature 1 above can be found at: https://github.com/JanusGraph/janusgraph-foundationdb/pull/50

Regards,

Jun Li and Hieu Nguyen




Re: To Contribute Our Code Enhancement Back to JanusGraph-FoundationDB Storage Plugin

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

+1 thank you both for the enhancements. Looking forward to getting these contributions integrated into the project!


On Sunday, October 4, 2020 at 10:11:39 AM UTC-4 Jun Li wrote:

Hello,

In eBay, we now have JanusGraph deployed in production, with FoundationDB being the backend store. The details on the design, deployment and the eBay use cases can be found in last year’s FoundationDB Summit (https://www.youtube.com/watch?v=EtB1BPG00PE). We took the earlier version of JanusGraph-FoundationDB plugin developed by Ted Wilmes in February 2019, and have made bug fixing and improvement over the last two years.  Now we would like to contribute our code back to the open source community, with the following improved features:

(1)Some bug fixing for the current JanusGraph FoundationDB plugin, and support of Async. Iterator. With Asynchronous Iterator, we can greatly leverage FoundationDB’s Asynchronous Iterator in terms of on-demand data stream pulling, better memory efficiency, better parallelism for MultiQuery support. We introduce “iterator” mode, along with the current mode that we call “list” mode.

(2)Enable Prefetching on Global Read Version of FoundationDB. This allows read-only query to use a slightly delayed GRV for snap-shot read (configurable, say 100 ms delayed), but save the GRV fetching time from the Primary DC. In the cross-datacenter production environment, the saving can be as large as > 50 ms due to this GRV pre-fetching.

(3) Support Read-Only GraphDB from the specified environment variables at GraphDB engine start-up.

(4)Context propagation that allows the Client Application to express “read-only” optimization support from Feature 2 mentioned above, to the FoundationDB storage plugin. So that write-involved queries will not be optimized. Furthermore, we can allow transaction reset with “read-commit-write” mode to be per-transaction, and only for the “read-only” queries, further optimization for “read-only” queries.The write-involved queries will still follow "serializable" mode for strong consistency.

(5)Enable TLS that is supported by FoundationDB. Security is important in the production environment.

(6)Enable Prometheus Metrics Monitoring. So that we can have good visibility across multiple datacenter deployment in the production environment. From the metrics collected, dashboards and alerts can be further developed easily. We can share our Grafana dashboards JSON configuration files and Prometheus alert rules used in our production environment  to the open-source community also. 

The first PR on Feature 1 above can be found at: https://github.com/JanusGraph/janusgraph-foundationdb/pull/50

Regards,

Jun Li and Hieu Nguyen




To Contribute Our Code Enhancement Back to JanusGraph-FoundationDB Storage Plugin

Jun Li <jltz9...@...>
 

Hello,

In eBay, we now have JanusGraph deployed in production, with FoundationDB being the backend store. The details on the design, deployment and the eBay use cases can be found in last year’s FoundationDB Summit (https://www.youtube.com/watch?v=EtB1BPG00PE). We took the earlier version of JanusGraph-FoundationDB plugin developed by Ted Wilmes in February 2019, and have made bug fixing and improvement over the last two years.  Now we would like to contribute our code back to the open source community, with the following improved features:

(1)Some bug fixing for the current JanusGraph FoundationDB plugin, and support of Async. Iterator. With Asynchronous Iterator, we can greatly leverage FoundationDB’s Asynchronous Iterator in terms of on-demand data stream pulling, better memory efficiency, better parallelism for MultiQuery support. We introduce “iterator” mode, along with the current mode that we call “list” mode.

(2)Enable Prefetching on Global Read Version of FoundationDB. This allows read-only query to use a slightly delayed GRV for snap-shot read (configurable, say 100 ms delayed), but save the GRV fetching time from the Primary DC. In the cross-datacenter production environment, the saving can be as large as > 50 ms due to this GRV pre-fetching.

(3) Support Read-Only GraphDB from the specified environment variables at GraphDB engine start-up.

(4)Context propagation that allows the Client Application to express “read-only” optimization support from Feature 2 mentioned above, to the FoundationDB storage plugin. So that write-involved queries will not be optimized. Furthermore, we can allow transaction reset with “read-commit-write” mode to be per-transaction, and only for the “read-only” queries, further optimization for “read-only” queries.The write-involved queries will still follow "serializable" mode for strong consistency.

(5)Enable TLS that is supported by FoundationDB. Security is important in the production environment.

(6)Enable Prometheus Metrics Monitoring. So that we can have good visibility across multiple datacenter deployment in the production environment. From the metrics collected, dashboards and alerts can be further developed easily. We can share our Grafana dashboards JSON configuration files and Prometheus alert rules used in our production environment  to the open-source community also. 

The first PR on Feature 1 above can be found at: https://github.com/JanusGraph/janusgraph-foundationdb/pull/50

Regards,

Jun Li and Hieu Nguyen




Re: JanusGraph Community Meetup - September 30, 2020

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

Hello,
Quick FYI, the date for this meetup has been moved to October 7th at 1 PM Central. Sign ups can still be made here: https://www.experoinc.com/get/janusgraph-user-group

Thanks,
Ted

On Wed, Sep 23, 2020 at 12:55 PM Ted Wilmes <twi...@...> wrote:
Hello,
Expero Inc. will be hosting a JanusGraph community meetup one week from today on Wednesday, September 30th at 11 AM Central time. If you are interested in attending, you can sign up here: https://www.experoinc.com/get/janusgraph-user-group.

There will be two speakers discussing JanusGraph query optimization and how to manage multiple graphs from a single JanusGraph install along with a roundtable Q&A where we'll field JanusGraph questions from attendees.

Thanks,
Ted


Janus User Group Date Change

Scott Heath <scott...@...>
 

Hello fellow JanusGraph'rs
The date and time for the upcoming user group meeting has changed.  Please join us on the new date and time


Regards

Scott Heath | 

Expero Inc | www.experoinc.com
 | P+1 512.368.6080 | E: scott...@... |


JanusGraph Community Meetup - September 30, 2020

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

Hello,
Expero Inc. will be hosting a JanusGraph community meetup one week from today on Wednesday, September 30th at 11 AM Central time. If you are interested in attending, you can sign up here: https://www.experoinc.com/get/janusgraph-user-group.

There will be two speakers discussing JanusGraph query optimization and how to manage multiple graphs from a single JanusGraph install along with a roundtable Q&A where we'll field JanusGraph questions from attendees.

Thanks,
Ted


New committer: Boxuan Li

Oleksandr Porunov <alexand...@...>
 

On behalf of the JanusGraph Technical Steering Committee (TSC), I'm pleased to welcome a new committer on the project!

Boxuan Li has been a solid contributor. He already contributed many performance improvements, bug fixes and provided many PR reviews.


Congratulations, Boxuan Li!


New committer: Florian Grieskamp

Oleksandr Porunov <alexand...@...>
 

On behalf of the JanusGraph Technical Steering Committee (TSC), I'm pleased to welcome a new committer on the project!

Florian Grieskamp has been a solid contributor. He already contributed many performance improvements, contributions to janusgraph-foundationdb and provided many PR reviews.


Congratulations, Florian Grieskamp!

141 - 160 of 1585