Kilim for enterprise application development

[Lyubomir Stefanov]

Hello,

I'm considering actor frameworks kilim and akka for enterprise application. I have several questions

1. Does kilim support maven build?
2. Is it planned to upload kilim on central maven repository?
3. Does kilim support Java 1.7?
4. Is it planned to support Java 1.8?
5. What are the plans for kilims development?
6. What is the support policy for the future?
7. Do you have some best practices for migrating existing multi-thread applications to kilim?

Kind regards,
Lyubo

[Sriram Srinivasan]

On Feb 19, 2014, at 2:40 PM, Lyubomir Stefanov <lste...@gmail.com> wrote:

> Hello,
>
> I'm considering actor frameworks kilim and akka for enterprise application. I have several questions
>
> 1. Does kilim support maven build?

I'll let the others who have experience with maven reply to this. I know there are projects that have used the two together.

> 2. Is it planned to upload kilim on central maven repository?

Can do if there's demand.

> 3. Does kilim support Java 1.7?

Yes.

> 4. Is it planned to support Java 1.8?

Yes, but not before April.

> 5. What are the plans for kilims development?

None from my side, except for support for 1.8. I would like some concrete help on hardening and improving some features, such as using lock-free data structures for mailboxes and scheduling, work-stealing schedulers, monitoring and debugging, stack traces of all tasks etc.

> 6. What is the support policy for the future?

No guarantees, as with open source. I'll extend my help to anyone who wishes to modify/extend Kilim.

> 7. Do you have some best practices for migrating existing multi-thread applications to kilim?
>

The brain-dead version is to replace all java.lang.Thread with kilim.Tasks, replace locks with kilim.RWLock.
I did this for Berkeley db (which involved tedious but conceptually simple change to a few hundred files!), and saw throughput jump about 30% (described in my thesis).

But overall, one can get much better structure and performance by adopting the communicating process model. As the golang folks say, "share by communicating", instead of "communicate by sharing". This is not to say that shared data structures should not be used. They can be for sharing data, but for the control plane, I prefer messaging to using semaphores, condition variables and locks. Mailbox.select is your friend; it allows a task on one of n event sources. This is the kind of thing that gets very convoluted with traditional concurrency mechanisms.

[Jason Pell]

Hi,

There is a pom file included in github that we use to deploy kilim to our local nexus repo.  We then include it into the build just like any other dependency.

You have to embrace the message passing paradigm for kilim to be useful.

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

[Sriram Srinivasan]

Hi all, 

I'm going to give a talk in San Francisco  contrasting design choices using iterators, generators, coroutines and lightweight threads.   The idea is to examine what it takes to program servers in a variety of paradigms, from async event frameworks like Netty, to reactive frameworks (RxJava), to synchronous programming paradigms in Erlang, Go and of course, Kilim!

Hopefully I'll get to see some of you there. 

--sriram