Apache Ignite

[bitchkat]

I'm interested in developing a plugin for Apache Ignite in memory data grid. I'm wondering if there is any documentation on developing a backend? Ignite has a lock (really just a mutex) that we can build from and has event listeners we can use to monitor cache entries. So even though it provides an SQL view of the caches, we shouldn't need to write any sql polling code.

[madelson]

Hi @bitchkat just to clarify are you interested in contributing an open source implementation to this repository based on Apache Ignite? If so, I'd be happy to guide you through the process and what would need to be done.

[bitchkat]

That is absolutely what I'm interested in.

[madelson]

@bitchkat that's great! I'd really appreciate having the contribution. Here's how I would recommend proceeding.

First off, I think it would be worth discussing the high level algorithm approach on this thread. For example:

• What libraries would we be taking dependencies on?
• What synchronization primitives are we proposing to support (mutex, rw-lock, and/or semaphore)?
• What is the pseudo-code for the locking algorithm?
• Does the underlying technology support async IO? Sync IO?
• Any challenges around connection management?
• How will we support cancellation?
• How will we support timeouts?

Having alignment on these kinds of questions early should help things go smoothly.

Next, we can get started writing code. In your DistributedLock repo fork:

• Add a new project DistributedLock.Ignite, copying the csproj from DistributedLock.ZooKeeper with appropriate modifications
• Add a new InternalsVisibleTo attribute in DistributedLock.Core's AssemblyAttributes.cs
• Add a project reference to the new project from DistributedLock.csproj
• Declare your lock type (as partial!) and handle type implementing the right interfaces but with no implementations yet (yes, it won't build; that's ok). See for example ZooKeeperDistributedLock and ZooKeeperDistributedLockHandle.
• Run the tests in the DistributedLockCodeGen project. They will fail (means they generated new code), and then succeed on the next run.
• Add an explicit implementation for InternalTryAcquireAsync in your lock class; put the core implementation here.
• Flesh out constructors

Please ask me questions about anything you run into; I'd love for this thread to result in a robust guide for adding new lock implementations.

After that, we'd want to hook the new provider into the test project; that's a few steps ahead though; I can write those up when things are further along.