love it

[jon stevens]

Just found out about hazelcast and I am loving it because there is so
much in one easy to use package. Great job.

A few thoughts:

a) I'd love to see a bit more javadoc in the code. Just makes things
easier to read.

b) I'd love to see the hibernate 2nd level cache stuff documented. In
my app, I just replaced JBoss Cache 1.x (i know, i know) with Ehcache
and now I wish I had known about hazelcast before I did that. It is
great to accept donations of code, but the requirement for acceptance
should include documentation. =)

c) I'd love to see a HA Singleton implementation similar to the jboss
one, but without all the configuration crap and horrible documentation
that jboss has... http://www.jboss.org/community/wiki/HASingletonDeployer
It shouldn't be too hard to do as it would essentially be a
Distributed Execution/Lock combo with a nice api. Effectively ensuring
a Distributed Execution starts up a Thread on one member in the
cluster at a time. If one member dies, start up a new Thread on
another member.

d) Performance metrics. How well does HC compare to ehcache?

[David Pellegrini]

Hi Jon!

David

> --
>
> You received this message because you are subscribed to the Google Groups "Hazelcast" group.
> To post to this group, send email to haze...@googlegroups.com.
> To unsubscribe from this group, send email to hazelcast+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/hazelcast?hl=en.
>
>
>

[Talip Ozturk]

On Fri, Dec 4, 2009 at 10:44 PM, jon stevens <latc...@gmail.com> wrote:
> Just found out about hazelcast and I am loving it because there is so
> much in one easy to use package. Great job.

thanks!

> a) I'd love to see a bit more javadoc in the code. Just makes things
> easier to read.

Agreed.

> b) I'd love to see the hibernate 2nd level cache stuff documented. In
> my app, I just replaced JBoss Cache 1.x (i know, i know) with Ehcache
> and now I wish I had known about hazelcast before I did that. It is
> great to accept donations of code, but the requirement for acceptance
> should include documentation. =)

Agreed.

> c) I'd love to see a HA Singleton implementation similar to the jboss
> one, but without all the configuration crap and horrible documentation
> that jboss has... http://www.jboss.org/community/wiki/HASingletonDeployer
> It shouldn't be too hard to do as it would essentially be a
> Distributed Execution/Lock combo with a nice api. Effectively ensuring
> a Distributed Execution starts up a Thread on one member in the
> cluster at a time. If one member dies, start up a new Thread on
> another member.

I have to read and think about it.

> d) Performance metrics. How well does HC compare to ehcache?

No performance metrics. I am very confident when it comes to
performance though. I am hoping someone would do benchmarks against
ehcache/coherence etc. If hazelcast committers do the benchmarks then
it would not be really convincing, would it :) ?

-talip

[jon stevens]

> > c) I'd love to see a HA Singleton implementation similar to the jboss
> > one, but without all the configuration crap and horrible documentation

> > that jboss has...http://www.jboss.org/community/wiki/HASingletonDeployer

> > It shouldn't be too hard to do as it would essentially be a
> > Distributed Execution/Lock combo with a nice api. Effectively ensuring
> > a Distributed Execution starts up a Thread on one member in the
> > cluster at a time. If one member dies, start up a new Thread on
> > another member.
>
> I have to read and think about it.

Usecase:

Imagine that you have a cluster of web front end jboss instances
writing to a database. Those instances are running in a cluster. It
would be cool to be able to run a 'thread' on only one instance at a
time.

For instance, say you have a pay per minute system video billing
system. User A on machine A opens up a 'viewing session' and money is
essentially being deducted from their account. Now, say that user
disappears for some reason. You need a background task that is timing
out those open sessions. Without spinning up more machines/jvm's to
handle this, it would be nice to be able to just do it in the cluster.
But having X machines all performing this task at the same time gets
into concurrency issues.

cheers,

jon