8:33 a.m.
Hi,
Currently, we have two local CacheStore implementations - BDBJE and JDBM.
If someone distributes an application that uses BDBJE, that application
must be under an open source license. It's not a problem to Infinispan,
but it is to our users who want to distribute Infinispan with their
applications and want to use BDBJE as a backend.
JDBM has one of the most permissive license, but the recent
investigation revealed a significant performance issue:
https://jira.jboss.org/browse/ISPN-663
Moreover, JDBM hasn't been maintained actively for a long time.
If we write our own native CacheStore implementation that is optimized
for our CacheStore API, we will be able to present the whole new
performance numbers to wider audience.
WDYT?
--
http://gleamynode.net/
8:44 a.m.
I might also add that the Cassandra CacheStore has good performance (well,
Cassandra does :))
Tristan
On Tue, Oct 12, 2010 at 15:37, Tristan Tarrant <tristan.tarrant(a)gmail.com>wrote:
On Tue, Oct 12, 2010 at 15:33, "이희승 (Trustin Lee)"
<trustin(a)gmail.com>wrote:
> Currently, we have two local CacheStore implementations - BDBJE and JDBM.
>
Correction: there is also the FileCacheStore.
Tristan
8:55 a.m.
Yeah, I omitted it however because it brings another level of
abstraction. NoSQL over NoSQL... :-)
Tristan Tarrant wrote:
I might also add that the Cassandra CacheStore has good performance
(well, Cassandra does :))
Tristan
On Tue, Oct 12, 2010 at 15:37, Tristan Tarrant
<tristan.tarrant(a)gmail.com <mailto:tristan.tarrant@gmail.com>> wrote:
On Tue, Oct 12, 2010 at 15:33, "이희승 (Trustin Lee)"
<trustin(a)gmail.com <mailto:trustin@gmail.com>> wrote:
Currently, we have two local CacheStore implementations - BDBJE
and JDBM.
Correction: there is also the FileCacheStore.
Tristan
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
http://gleamynode.net/
8:47 a.m.
Tristan Tarrant wrote:
On Tue, Oct 12, 2010 at 15:33, "이희승 (Trustin Lee)"
<trustin(a)gmail.com
<mailto:trustin@gmail.com>> wrote:
Currently, we have two local CacheStore implementations - BDBJE and
JDBM.
Correction: there is also the FileCacheStore.
You are right. I missed that, argh! :)
How does it perform then comparing to BDBJE and JDBM? Out of curiosity,
if there is a good file-based cache store implementation, why BDBJE and
JDBM backends were introduced?
--
http://gleamynode.net/
8:53 a.m.
How does it perform then comparing to BDBJE and JDBM? Out of curiosity,
if there is a good file-based cache store implementation, why BDBJE and
JDBM backends were introduced?
Haven't tried BDBJE, but it certainly is faster than JDBM. We should setup
Hudson's performance plugin
http://wiki.hudson-ci.org/display/HUDSON/Performance+Plugin
so we can monitor regressions.
Tristan
8:55 a.m.
2010/10/12 Tristan Tarrant <tristan.tarrant(a)gmail.com>:
> How does it perform then comparing to BDBJE and JDBM? Out of
curiosity,
> if there is a good file-based cache store implementation, why BDBJE and
> JDBM backends were introduced?
>
Haven't tried BDBJE, but it certainly is faster than JDBM. We should setup
Hudson's performance plugin
http://wiki.hudson-ci.org/display/HUDSON/Performance+Plugin
so we can monitor regressions.
Tristan
definitely! and not to monitor the cacheStores only, but the cache itself too.
(and Lucene, and Query, ...)
Sanne
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
10:30 a.m.
2010/10/12 Tristan Tarrant <tristan.tarrant(a)gmail.com>:
> How does it perform then comparing to BDBJE and JDBM? Out of
curiosity,
> if there is a good file-based cache store implementation, why BDBJE and
> JDBM backends were introduced?
>
Haven't tried BDBJE, but it certainly is faster than JDBM.
My finding so far - FileCacheStore is a BucketBasedCacheStore that uses
the hashCode of the key as the bucket name. FileCacheStore creates a
new file for each bucket. It means a lot of files will be created as
new entries are added. I don't think it will perform better than JDBM
or BDBJE in most cases.
--
http://gleamynode.net/
11:43 a.m.
On 12 Oct 2010, at 14:47, 이희승 (Trustin Lee) wrote:
Tristan Tarrant wrote:
> On Tue, Oct 12, 2010 at 15:33, "이희승 (Trustin Lee)" <trustin(a)gmail.com
> <mailto:trustin@gmail.com>> wrote:
>
> Currently, we have two local CacheStore implementations - BDBJE and
> JDBM.
>
>
> Correction: there is also the FileCacheStore.
You are right. I missed that, argh! :)
How does it perform then comparing to BDBJE and JDBM? Out of curiosity,
if there is a good file-based cache store implementation, why BDBJE and
JDBM backends were introduced?
One reason is that FileCacheStore is not good with
transactions.Transactions & cache stores will get more attention in 5.0. Also
FileCacheStore is a BucketBasedCacheStore which might not be good if keys hash in the same
bucket.
I like your idea of native cache store though, and I think as long as we can outperform
the other stores we should only maintain that one.
--
http://gleamynode.net/
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
2:32 a.m.
On Oct 12, 2010, at 6:43 PM, Mircea Markus wrote:
On 12 Oct 2010, at 14:47, 이희승 (Trustin Lee) wrote:
> Tristan Tarrant wrote:
>> On Tue, Oct 12, 2010 at 15:33, "이희승 (Trustin Lee)"
<trustin(a)gmail.com
>> <mailto:trustin@gmail.com>> wrote:
>>
>> Currently, we have two local CacheStore implementations - BDBJE and
>> JDBM.
>>
>>
>> Correction: there is also the FileCacheStore.
>
> You are right. I missed that, argh! :)
>
> How does it perform then comparing to BDBJE and JDBM? Out of curiosity,
> if there is a good file-based cache store implementation, why BDBJE and
> JDBM backends were introduced?
One reason is that FileCacheStore is not good with transactions.Transactions & cache
stores will get more attention in 5.0. Also FileCacheStore is a BucketBasedCacheStore
which might not be good if keys hash in the same bucket.
I like your idea of native cache store though, and I think as long as we can outperform
the other stores we should only maintain that one.
Trustin/Mircea,
What exactly do you guys mean by 'native'? Something like what HornetQ guys did?
Or your talking more about adapting an existing cache store impl library to suit our type
of ops?
I suppose you'd be targeting the local cache store space and not the shared one,
correct?
I do have some doubts on whether spending time implementing another cache store impl would
be really that useful.
When I was in Berlin, rather than implementing another X cache store due to performance, I
heard users asking more about whether they could have their existing databases be read by
Infinispan cache stores, to avoid having multiple databases, one for a shared JDBC cache
store and one for their JPA or similar ORM databases. Granted that this could be done with
a Hibernate based cache store but then again you could be wondering whether they should
not just use Hibernate directly with a 2LC.
> --
> http://gleamynode.net/
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
6:39 a.m.
Galder Zamarreño wrote:
On Oct 12, 2010, at 6:43 PM, Mircea Markus wrote:
> On 12 Oct 2010, at 14:47, 이희승 (Trustin Lee) wrote:
>
>> Tristan Tarrant wrote:
>>> On Tue, Oct 12, 2010 at 15:33, "이희승 (Trustin Lee)"
<trustin(a)gmail.com
>>> <mailto:trustin@gmail.com>> wrote:
>>>
>>> Currently, we have two local CacheStore implementations - BDBJE and
>>> JDBM.
>>>
>>>
>>> Correction: there is also the FileCacheStore.
>> You are right. I missed that, argh! :)
>>
>> How does it perform then comparing to BDBJE and JDBM? Out of curiosity,
>> if there is a good file-based cache store implementation, why BDBJE and
>> JDBM backends were introduced?
> One reason is that FileCacheStore is not good with transactions.Transactions &
cache stores will get more attention in 5.0. Also FileCacheStore is a
BucketBasedCacheStore which might not be good if keys hash in the same bucket.
> I like your idea of native cache store though, and I think as long as we can
outperform the other stores we should only maintain that one.
Trustin/Mircea,
What exactly do you guys mean by 'native'? Something like what HornetQ guys did?
Or your talking more about adapting an existing cache store impl library to suit our type
of ops?
Something similar to the latter. Basically, I think we need to replace
the current FileCacheStore implementation. We could utilize what
HornetQ guys did with libaio if that will yield even higher performance,
but it's not the first task to do.
I suppose you'd be targeting the local cache store space and not
the shared one, correct?
Correct.
I do have some doubts on whether spending time implementing another
cache store impl would be really that useful.
When I was in Berlin, rather than implementing another X cache store due to performance,
I heard users asking more about whether they could have their existing databases be read
by Infinispan cache stores, to avoid having multiple databases, one for a shared JDBC
cache store and one for their JPA or similar ORM databases. Granted that this could be
done with a Hibernate based cache store but then again you could be wondering whether they
should not just use Hibernate directly with a 2LC.
I think that depends on how solid and fast FileCacheStore is. If it's
good, more people will use it. For now, not many people seem to use it
and that might be why we don't hear much about it.
Also, having a good reference local cache store implementation is
important to initial adoption, because people will find better numbers
when they evaluate Infinispan. They could begin their tests with other
cache stores like JdbcCacheStore, but most people will start with the
most easy-to-configure one with the least dependency.
Just my 2 cents. :)
--
Trustin Lee - http://gleamynode.net/
9:10 a.m.
On 14 Oct 2010, at 12:39, 이희승 (Trustin Lee) wrote:
Galder Zamarreño wrote:
> On Oct 12, 2010, at 6:43 PM, Mircea Markus wrote:
>
>> On 12 Oct 2010, at 14:47, 이희승 (Trustin Lee) wrote:
>>
>>> Tristan Tarrant wrote:
>>>> On Tue, Oct 12, 2010 at 15:33, "이희승 (Trustin Lee)"
<trustin(a)gmail.com
>>>> <mailto:trustin@gmail.com>> wrote:
>>>>
>>>> Currently, we have two local CacheStore implementations - BDBJE and
>>>> JDBM.
>>>>
>>>>
>>>> Correction: there is also the FileCacheStore.
>>> You are right. I missed that, argh! :)
>>>
>>> How does it perform then comparing to BDBJE and JDBM? Out of curiosity,
>>> if there is a good file-based cache store implementation, why BDBJE and
>>> JDBM backends were introduced?
>> One reason is that FileCacheStore is not good with transactions.Transactions
& cache stores will get more attention in 5.0. Also FileCacheStore is a
BucketBasedCacheStore which might not be good if keys hash in the same bucket.
>> I like your idea of native cache store though, and I think as long as we can
outperform the other stores we should only maintain that one.
>
> Trustin/Mircea,
>
> What exactly do you guys mean by 'native'? Something like what HornetQ guys
did? Or your talking more about adapting an existing cache store impl library to suit our
type of ops?
Something similar to the latter. Basically, I think we need to replace
the current FileCacheStore implementation. We could utilize what
HornetQ guys did with libaio if that will yield even higher performance,
but it's not the first task to do.
Same here! I would like to be able to supply
users a very fast cache store that would come out of the box. I.e. no need to install a DB
etc.
> I suppose you'd be targeting the local cache store space and not the shared one,
correct?
Correct.
> I do have some doubts on whether spending time implementing another cache store impl
would be really that useful.
>
> When I was in Berlin, rather than implementing another X cache store due to
performance, I heard users asking more about whether they could have their existing
databases be read by Infinispan cache stores, to avoid having multiple databases, one for
a shared JDBC cache store and one for their JPA or similar ORM databases. Granted that
this could be done with a Hibernate based cache store but then again you could be
wondering whether they should not just use Hibernate directly with a 2LC.
I think that depends on how solid and fast FileCacheStore is. If it's
good, more people will use it. For now, not many people seem to use it
and that might be why we don't hear much about it.
We explicitly discourage
people to use file cache store:
http://community.jboss.org/wiki/CacheLoaders#Shipped_Implementations
Also, having a good reference local cache store implementation is
important to initial adoption, because people will find better numbers
when they evaluate Infinispan.
They could begin their tests with other
cache stores like JdbcCacheStore, but most people will start with the
most easy-to-configure one with the least dependency.
+1
Not something urgent IMO, but I think it's worth keeping it in mind as this is
something that can easily be passed to a potential contributor.
Just my 2 cents. :)
--
Trustin Lee - http://gleamynode.net/
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
9:19 a.m.
On Oct 14, 2010, at 4:10 PM, Mircea Markus wrote:
On 14 Oct 2010, at 12:39, 이희승 (Trustin Lee) wrote:
>
>
> Galder Zamarreño wrote:
>
>> I do have some doubts on whether spending time implementing another cache store
impl would be really that useful.
>>
>> When I was in Berlin, rather than implementing another X cache store due to
performance, I heard users asking more about whether they could have their existing
databases be read by Infinispan cache stores, to avoid having multiple databases, one for
a shared JDBC cache store and one for their JPA or similar ORM databases. Granted that
this could be done with a Hibernate based cache store but then again you could be
wondering whether they should not just use Hibernate directly with a 2LC.
>
> I think that depends on how solid and fast FileCacheStore is. If it's
> good, more people will use it. For now, not many people seem to use it
> and that might be why we don't hear much about it.
We explicitly discourage people to use file cache store:
http://community.jboss.org/wiki/CacheLoaders#Shipped_Implementations
I don't think that's totally right actually. JBoss AS has been using the
FileCacheStore in JBoss Cache for EJB3 SFSB passivation and HTTP session passivation and
afaik, I haven't heard any complaints from them.
So, there must be something right about it and we're not talking about sporadic use
here. Remember that this is actually part of the supported EAP 5.x as well.
Granted that using FCS as shared cache store is crazy, but there's a valid use for
local use.
FYI:
https://svn.jboss.org/repos/jbossas/tags/JBPAPP_5_1_0_GA/cluster/src/reso...
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
6:50 p.m.
actually I consider it a mayor value that there are many stores available.
sure performance is important, but on cloud you might love to use S3
for flexibility reasons (for example it easy to manage).
Also in some companies they just have "policies" which aren't easy to
change, a quite frequent one reads
*"all state shall be stored in Oracle"*
Developers might have many different reasons to oppose these rule, but
no way, if your app is going
to store critical information in the filesystem (or whatever else your
propose which is not the DB) it's not going to be set in production -
no way for that.
Of course, this reflects just my limited experience, a speedy version
would be cool, but it has to be damn fast to be of any interest,
and I'd prefer to have all existing implementations "tuned" as far as
possible (including the Cassandra one, which seems to fit nicely as a
potential native speedy implementation..).
Cheers,
Sanne
2010/10/14 Galder Zamarreño <galder(a)redhat.com>:
On Oct 14, 2010, at 4:10 PM, Mircea Markus wrote:
>
> On 14 Oct 2010, at 12:39, 이희승 (Trustin Lee) wrote:
>
>>
>>
>> Galder Zamarreño wrote:
>>
>>> I do have some doubts on whether spending time implementing another cache
store impl would be really that useful.
>>>
>>> When I was in Berlin, rather than implementing another X cache store due to
performance, I heard users asking more about whether they could have their existing
databases be read by Infinispan cache stores, to avoid having multiple databases, one for
a shared JDBC cache store and one for their JPA or similar ORM databases. Granted that
this could be done with a Hibernate based cache store but then again you could be
wondering whether they should not just use Hibernate directly with a 2LC.
>>
>> I think that depends on how solid and fast FileCacheStore is. If it's
>> good, more people will use it. For now, not many people seem to use it
>> and that might be why we don't hear much about it.
> We explicitly discourage people to use file cache store:
http://community.jboss.org/wiki/CacheLoaders#Shipped_Implementations
I don't think that's totally right actually. JBoss AS has been using the
FileCacheStore in JBoss Cache for EJB3 SFSB passivation and HTTP session passivation and
afaik, I haven't heard any complaints from them.
So, there must be something right about it and we're not talking about sporadic use
here. Remember that this is actually part of the supported EAP 5.x as well.
Granted that using FCS as shared cache store is crazy, but there's a valid use for
local use.
FYI:
https://svn.jboss.org/repos/jbossas/tags/JBPAPP_5_1_0_GA/cluster/src/reso...
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
6:40 a.m.
On Oct 15, 2010, at 1:50 AM, Sanne Grinovero wrote:
actually I consider it a mayor value that there are many stores
available.
sure performance is important, but on cloud you might love to use S3
for flexibility reasons (for example it easy to manage).
Sure, that's already covered with JClouds based cache store. It's called cloud
cache store :)
Also in some companies they just have "policies" which aren't easy to
change, a quite frequent one reads
*"all state shall be stored in Oracle"*
Developers might have many different reasons to oppose these rule, but
no way, if your app is going
to store critical information in the filesystem (or whatever else your
propose which is not the DB) it's not going to be set in production -
no way for that.
Of course, this reflects just my limited experience, a speedy version
would be cool, but it has to be damn fast to be of any interest,
and I'd prefer to have all existing implementations "tuned" as far as
possible (including the Cassandra one, which seems to fit nicely as a
potential native speedy implementation..).
Cheers,
Sanne
2010/10/14 Galder Zamarreño <galder(a)redhat.com>:
>
> On Oct 14, 2010, at 4:10 PM, Mircea Markus wrote:
>
>>
>> On 14 Oct 2010, at 12:39, 이희승 (Trustin Lee) wrote:
>>
>>>
>>>
>>> Galder Zamarreño wrote:
>>>
>>>> I do have some doubts on whether spending time implementing another cache
store impl would be really that useful.
>>>>
>>>> When I was in Berlin, rather than implementing another X cache store due
to performance, I heard users asking more about whether they could have their existing
databases be read by Infinispan cache stores, to avoid having multiple databases, one for
a shared JDBC cache store and one for their JPA or similar ORM databases. Granted that
this could be done with a Hibernate based cache store but then again you could be
wondering whether they should not just use Hibernate directly with a 2LC.
>>>
>>> I think that depends on how solid and fast FileCacheStore is. If it's
>>> good, more people will use it. For now, not many people seem to use it
>>> and that might be why we don't hear much about it.
>> We explicitly discourage people to use file cache store:
http://community.jboss.org/wiki/CacheLoaders#Shipped_Implementations
>
> I don't think that's totally right actually. JBoss AS has been using the
FileCacheStore in JBoss Cache for EJB3 SFSB passivation and HTTP session passivation and
afaik, I haven't heard any complaints from them.
>
> So, there must be something right about it and we're not talking about sporadic
use here. Remember that this is actually part of the supported EAP 5.x as well.
>
> Granted that using FCS as shared cache store is crazy, but there's a valid use
for local use.
>
> FYI:
https://svn.jboss.org/repos/jbossas/tags/JBPAPP_5_1_0_GA/cluster/src/reso...
>
> --
> Galder Zamarreño
> Sr. Software Engineer
> Infinispan, JBoss Cache
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
4:15 a.m.
Sanne Grinovero wrote:
actually I consider it a mayor value that there are many stores
available.
sure performance is important, but on cloud you might love to use S3
for flexibility reasons (for example it easy to manage).
Private cloud?
no way, if your app is going
to store critical information in the filesystem (or whatever else your
propose which is not the DB) it's not going to be set in production -
no way for that.
Of course, this reflects just my limited experience, a speedy version
would be cool, but it has to be damn fast to be of any interest,
and I'd prefer to have all existing implementations "tuned" as far as
possible (including the Cassandra one, which seems to fit nicely as a
potential native speedy implementation..).
If Infinispan stores multiple copies of entries across the cluster,
storing the entries in the filesystem shouldn't be a problem. Can we do
that by the way? (I still know nothing about ISPN. ;)
Cheers,
Trustin
--
Trustin Lee - http://gleamynode.net/
12:44 p.m.
On Oct 18, 2010, at 11:15 AM, 이희승 (Trustin Lee) wrote:
Sanne Grinovero wrote:
> actually I consider it a mayor value that there are many stores available.
> sure performance is important, but on cloud you might love to use S3
> for flexibility reasons (for example it easy to manage).
Private cloud?
> no way, if your app is going
> to store critical information in the filesystem (or whatever else your
> propose which is not the DB) it's not going to be set in production -
> no way for that.
>
> Of course, this reflects just my limited experience, a speedy version
> would be cool, but it has to be damn fast to be of any interest,
> and I'd prefer to have all existing implementations "tuned" as far as
> possible (including the Cassandra one, which seems to fit nicely as a
> potential native speedy implementation..).
If Infinispan stores multiple copies of entries across the cluster,
storing the entries in the filesystem shouldn't be a problem. Can we do
that by the way? (I still know nothing about ISPN. ;)
Do what exactly? Persist to a filesystem?
Cheers,
Trustin
--
Trustin Lee - http://gleamynode.net/
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
8:40 p.m.
Galder Zamarreño wrote:
On Oct 18, 2010, at 11:15 AM, 이희승 (Trustin Lee) wrote:
> Sanne Grinovero wrote:
>> actually I consider it a mayor value that there are many stores available.
>> sure performance is important, but on cloud you might love to use S3
>> for flexibility reasons (for example it easy to manage).
> Private cloud?
>
>> no way, if your app is going
>> to store critical information in the filesystem (or whatever else your
>> propose which is not the DB) it's not going to be set in production -
>> no way for that.
>>
>> Of course, this reflects just my limited experience, a speedy version
>> would be cool, but it has to be damn fast to be of any interest,
>> and I'd prefer to have all existing implementations "tuned" as far
as
>> possible (including the Cassandra one, which seems to fit nicely as a
>> potential native speedy implementation..).
> If Infinispan stores multiple copies of entries across the cluster,
> storing the entries in the filesystem shouldn't be a problem. Can we do
> that by the way? (I still know nothing about ISPN. ;)
Do what exactly? Persist to a filesystem?
Storing an entry to multiple nodes so that it survives a crash.
--
Trustin Lee - http://gleamynode.net/
2:30 a.m.
>>> no way, if your app is going
>>> to store critical information in the filesystem (or whatever else your
>>> propose which is not the DB) it's not going to be set in production -
>>> no way for that.
Sorry for replying out of (the current) context :)
Actually I've seen many customers rely on SAN/NAS for critical data, without
the need for a DB.
Tristan
6:51 a.m.
On 18 Oct 2010, at 10:15, 이희승 (Trustin Lee) wrote:
Sanne Grinovero wrote:
> actually I consider it a mayor value that there are many stores available.
> sure performance is important, but on cloud you might love to use S3
> for flexibility reasons (for example it easy to manage).
Private cloud?
CloudCacheStore uses JClouds which has (or will have?) support for VMWare/vSphere,
Eucalyptus, etc.
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
7:12 a.m.
thank you, but I know I think I have used all CacheStore implementations
already : )
Sorry for not being clear: I didn't mean to ask for these features but to
point out that the strenght of Infinispan is this existing flexibility, I
don't see much added value in wasting your precious time on a specific FS
based cache store, but would rather prefer to improve all of them - the only
implementation I don't think I would use much on a cloud are the ones
relying on local filesystem.
BTW to have a super-optimized store with nice hashing, we now have
Cassandra; I have no direct experience with it but it seems to me people
have already spent much effort on it and I assume optimizing it as much as
possible.
Cheers,
Sanne
Il giorno 25/ott/2010 12:51, "Manik Surtani" <manik(a)jboss.org> ha
scritto:
On 18 Oct 2010, at 10:15, 이희승 (Trustin Lee) wrote:
Sanne Grinovero wrote:
> actually I consider...
CloudCacheStore uses JClouds which has (or will have?)
support for
VMWare/vSphere, Eucalyptus, etc.
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http:...
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/...
4:12 a.m.
Galder Zamarreño wrote:
On Oct 14, 2010, at 4:10 PM, Mircea Markus wrote:
> On 14 Oct 2010, at 12:39, 이희승 (Trustin Lee) wrote:
>
>>
>> Galder Zamarreño wrote:
>>
>>> I do have some doubts on whether spending time implementing another cache
store impl would be really that useful.
>>>
>>> When I was in Berlin, rather than implementing another X cache store due to
performance, I heard users asking more about whether they could have their existing
databases be read by Infinispan cache stores, to avoid having multiple databases, one for
a shared JDBC cache store and one for their JPA or similar ORM databases. Granted that
this could be done with a Hibernate based cache store but then again you could be
wondering whether they should not just use Hibernate directly with a 2LC.
>> I think that depends on how solid and fast FileCacheStore is. If it's
>> good, more people will use it. For now, not many people seem to use it
>> and that might be why we don't hear much about it.
> We explicitly discourage people to use file cache store:
http://community.jboss.org/wiki/CacheLoaders#Shipped_Implementations
I don't think that's totally right actually. JBoss AS has been using the
FileCacheStore in JBoss Cache for EJB3 SFSB passivation and HTTP session passivation and
afaik, I haven't heard any complaints from them.
So, there must be something right about it and we're not talking about sporadic use
here. Remember that this is actually part of the supported EAP 5.x as well.
Granted that using FCS as shared cache store is crazy, but there's a valid use for
local use.
Perhaps stupid question: what does FCS stand for? :)
FileCacheStore might perform fairly well on a very good filesystem
implementation such as those available in Linux, but it can be improved
to perform even better, especially in less optimal filesystems like NTFS.
It's obviously not a high priority task, but I think we need to spend
some time on it in background for later harvest.
Cheers,
Trustin
--
Trustin Lee - http://gleamynode.net/
11:29 a.m.
On Oct 18, 2010, at 11:12 AM, 이희승 (Trustin Lee) wrote:
Galder Zamarreño wrote:
> On Oct 14, 2010, at 4:10 PM, Mircea Markus wrote:
>
>> On 14 Oct 2010, at 12:39, 이희승 (Trustin Lee) wrote:
>>
>>>
>>> Galder Zamarreño wrote:
>>>
>>>> I do have some doubts on whether spending time implementing another cache
store impl would be really that useful.
>>>>
>>>> When I was in Berlin, rather than implementing another X cache store due
to performance, I heard users asking more about whether they could have their existing
databases be read by Infinispan cache stores, to avoid having multiple databases, one for
a shared JDBC cache store and one for their JPA or similar ORM databases. Granted that
this could be done with a Hibernate based cache store but then again you could be
wondering whether they should not just use Hibernate directly with a 2LC.
>>> I think that depends on how solid and fast FileCacheStore is. If it's
>>> good, more people will use it. For now, not many people seem to use it
>>> and that might be why we don't hear much about it.
>> We explicitly discourage people to use file cache store:
http://community.jboss.org/wiki/CacheLoaders#Shipped_Implementations
>
> I don't think that's totally right actually. JBoss AS has been using the
FileCacheStore in JBoss Cache for EJB3 SFSB passivation and HTTP session passivation and
afaik, I haven't heard any complaints from them.
>
> So, there must be something right about it and we're not talking about sporadic
use here. Remember that this is actually part of the supported EAP 5.x as well.
>
> Granted that using FCS as shared cache store is crazy, but there's a valid use
for local use.
Perhaps stupid question: what does FCS stand for? :)
LOL, read the first word of the next paragraph ;)
FileCacheStore might perform fairly well on a very good filesystem
implementation such as those available in Linux, but it can be improved
to perform even better, especially in less optimal filesystems like NTFS.
It's obviously not a high priority task, but I think we need to spend
some time on it in background for later harvest.
p.s. In case you didn't figure it out, FCS = FileCacheStore ;)
Cheers,
Trustin
--
Trustin Lee - http://gleamynode.net/
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
6:54 a.m.
On 14 Oct 2010, at 08:32, Galder Zamarreño wrote:
What exactly do you guys mean by 'native'? Something like
what HornetQ guys did? Or your talking more about adapting an existing cache store impl
library to suit our type of ops?
I would actually like to see a LibAIO based impl for Linux. Similar in some ways who what
HornetQ has, but with some crucial differences: HQ uses this as a file journal, which is
sequentially accessed and always appended to. We would need random access, and most
likely some sort of hash/bucket system to ensure quick lookup on keys.
But I must stress that this cannot be high prio for now - we could spend a few spare
cycles and sketch up a design on the wiki, or maybe even invite designs from the
community, and see who contribs impls, for now.
Cheers
Manik
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
6:47 a.m.
On 12 Oct 2010, at 14:47, 이희승 (Trustin Lee) wrote:
How does it perform then comparing to BDBJE and JDBM? Out of
curiosity,
if there is a good file-based cache store implementation, why BDBJE and
JDBM backends were introduced?
Legacy. JBoss Cache had both of these impls and they were ported to Infinispan from JBoss
Cache.
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
11:43 p.m.
On Tue, Oct 12, 2010 at 6:33 AM, "이희승 (Trustin Lee)" <trustin(a)gmail.com>
wrote:
JDBM has one of the most permissive license, but the recent
investigation revealed a significant performance issue:
https://jira.jboss.org/browse/ISPN-663
Moreover, JDBM hasn't been maintained actively for a long time.
Just a note: JDBM has been effectively forked (or continued?) and is
hosted here:
http://jdbm2.googlecode.com/
The new lead on the project has done a number of performance
improvements. Since I worked on the original JDBM CacheStore, I was
considering doing an update to version 2. Still, there are performance
issues to address in JDBM, e.g.
http://code.google.com/p/jdbm2/issues/detail?id=1 and the JDBM 2 is
still in Beta.
I also came up, before JBossCache was effectively abandoned, a new
cache operation: TreeCache.store(K, Map) which did not return the
existing value. Also, TreeCache.clear(K). These were substitutes for
put and remove in 99% of cases when the return value is not of use.
I'm not sure these would necessarily fit into the Infinispan API, but
they are a lot easier for end users to understand what they do and
they are a lot more efficient.
6:55 a.m.
On 15 Oct 2010, at 05:43, Elias Ross wrote:
On Tue, Oct 12, 2010 at 6:33 AM, "이희승 (Trustin Lee)"
<trustin(a)gmail.com> wrote:
> JDBM has one of the most permissive license, but the recent
> investigation revealed a significant performance issue:
>
> https://jira.jboss.org/browse/ISPN-663
>
> Moreover, JDBM hasn't been maintained actively for a long time.
Just a note: JDBM has been effectively forked (or continued?) and is
hosted here:
http://jdbm2.googlecode.com/
The new lead on the project has done a number of performance
improvements. Since I worked on the original JDBM CacheStore, I was
considering doing an update to version 2. Still, there are performance
issues to address in JDBM, e.g.
http://code.google.com/p/jdbm2/issues/detail?id=1 and the JDBM 2 is
still in Beta.
Are you volunteering to update the JdbmCacheStore impl, Elias? ;)
Cheers
Manik
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
5120
days inactive
5133
days old
infinispan-dev@lists.jboss.org
27 comments
7 participants
participants (7)
-
"이희승 (Trustin Lee)" -
Elias Ross -
Galder Zamarreño -
Manik Surtani -
Mircea Markus -
Sanne Grinovero -
Tristan Tarrant