On ParserRegistry and classloaders
by Sanne Grinovero
I see the ParserRegistry was changed quite a bit; in Infinispan 6 it
allowed to specify a different classloader for some operations, now it
only takes a classloader during construction time.
For WildFly/JBoss users, it is quite common that the configuration
file we want parsed is not in the same classloader that the
ParserRegistry needs to lookup its own parser components (as its
design uses the ServiceLoader to discover components of the parser).
This is especially true when Infinispan is not used by the application
directly but via another module (so I guess also critical for
capedwarf).
I initially though to workaround the problem using a "wrapping
classloader" so that I could pass a single CL instance which would try
both the deployment classloader and the Infinispan's module
classloader, but - besides this being suboptimal - it doesn't work as
I'm violating isolation between modules: I can get exposed to an
Infinispan 6 module which contains also Parser components, which get
loaded as a service but are not compatible (different class
definition).
I'll need these changes in the ParserRegistry reverted please. Happy
to send a pull myself, but before I attempt to patch it myself could
someone explain what the goal was?
thanks,
Sanne
9 years, 6 months
New configuration
by Radim Vansa
Hi,
looking on the new configuration parser, I've noticed that you cannot
configure ConsistentHashFactory anymore - is this by purpose?
Another my concern is the fact that you enable stuff by parsing the
element - for example L1. I expect that omitting the element and setting
it with the default value (as presented in XSD) makes no difference, but
this is not how current configuration works.
My opinion comes probably too late as the PR was already reviewed,
discussed and integrated, but at least, please clearly describe the
behaviour in the XSD. The fact that l1-lifespan "Defaults to 10
minutes." is not correct - it defaults to L1 being disabled.
Thanks
Radim
--
Radim Vansa <rvansa(a)redhat.com>
JBoss DataGrid QA
9 years, 9 months
Clustered Listener
by Pierre Sutra
Hello,
As part of the LEADS project, we have been using recently the clustered
listeners API. In our use case, the application is employing a few
thousands listeners, constantly installing and un-installing them. The
overall picture is that things work smoothly up to a few hundreds
listeners, but above the cost is high due to the full replication
schema. To sidestep this issue, we have added a mechanism that allows
listening only to a single key. In such a case, the listener is solely
installed at the key owners. This greatly helps the scalability of the
mechanism at the cost of fault-tolerance since, in the current state of
the implementation, listeners are not forwarded to new data owners.
Since as a next step [1] it is planned to handle topology change, do you
plan also to support key (or key range) specific listener ? Besides,
regarding this last point and the current state of the implementation, I
would have like to know what is the purpose of the re-installation of
the cluster listener in case of a view change in the addedListener()
method of the CacheNotifierImpl class. Many thanks in advance.
Best,
Pierre Sutra
[1]
https://github.com/infinispan/infinispan/wiki/Clustered-listeners#handlin...
9 years, 9 months
Where's the roadmap?
by Sanne Grinovero
I was asked about the Infinispan roadmap on a forum post, my draft reads:
"Sure it's available online, see.."
but then I could actually only find this:
https://community.jboss.org/wiki/InfinispanRoadmap
(which is very outdated).
So, what's the roadmap?
Would be nice if we could have it updated and published on the new website.
Cheers,
Sanne
9 years, 9 months
Re: [infinispan-dev] CD datastore inserts slow
by Sanne Grinovero
Hi all,
some context, as this conversation started offlist:
performance problems with CapeDwarf's storage system, as you probably
know based on Infinispan.
So, storing some thousand entities in a single transaction takes a
little more than 1 second, while running each put operation in a
single transaction takes ~50 seconds.
I'm afraid that's nothing new?
When you use indexing, this is expected: it shines much better in
parallel operations than in sequential, individual transactions.
I expect some of the changes we have planned for Infinispan 7 to
improve on this, but it's unlikely to get faster than a single order
of magnitude.
These are some issues which affected my previous performance tests:
https://issues.jboss.org/browse/ISPN-3690
https://issues.jboss.org/browse/ISPN-1764
https://issues.jboss.org/browse/ISPN-3831
https://issues.jboss.org/browse/ISPN-3891
https://issues.jboss.org/browse/ISPN-3905
And of course the Hibernate Search and Lucene upgrades ;-)
(in no particular order, as relevance depends on the test and on what
metric I'm looking to improve)
If you need better figures the best thing we can do is measure your
specific test, and see if we need to add further tasks to my wishlist
or if it's enough to prioritize these.
Currently I think if you expect to use a transaction for each
operation, there is nothing wrong in CD as unfortunately these figures
match my expectations on a non-tuned system.. you could tune things a
bit, like better sizing of packets for JGroups and network stack, but
I wouldn't expect much higher figures without patching things in
Infinispan.
For the record, I'm more concerned that storing "a few thousand"
entities in a single TX takes a full second: that's not expected, but
my guess is that in this specific case you're not warming up the JVM
nor repeating the test. Having batching enabled, I'd expect this to be
in the order of millions / second.
Sanne
Previous discussion - sorry, the formatting got crazy:
> 17:20:17,640 INFO [com.google.appengine.tck.benchmark.ObjectifyBenchmarkTest] (default task-1) >>>> Save [2000] time: 1149ms
> 17:21:55,659 INFO [com.google.appengine.tck.benchmark.ObjectifyBenchmarkTest] (default task-1) >>>> Save [2000] time: 50675ms
> The first time is when whole 2000 is inserted in single Tx,
> the other one is when there is no existing Tx.
> OK, in reality doing non-Tx for whole batch is a no go,
> so on that side we're good.
> But I would still like to see non-Tx do much better then 1sec vs. 50sec (for 2k entities).
> -Ales
> On 28 May 2014, at 17:20, Mircea Markus <mmarkus(a)redhat.com> wrote:
> Can we isolate the tests somehow?
> On May 28, 2014, at 15:53, Ales Justin <ales.justin(a)gmail.com> wrote:
> Objectify is a popular GAE ORM, so it does plenty of persistence magic.
> Hence my simple answer is no.
> But it should be easy to take latest CapeDwarf release -- 2.0.0.CR2,
> and run + debug things, and see why it's so slow.
> Either Terry or me is gonna add this test to GAE TCK.
> I'll shoot an email on how to run this against CapeDwarf once it's added.
> Looking at this:
> * https://gist.github.com/alesj/1d24ad24dfbef8b5e12c
> It looks like a problem of Tx usage -- Tx per Cache::put.
> This snapshot only shows the time spent within Infinispan. Out of this time, 9% is spent indeed within cache.put. How much time does the test spend doing non-infinispan related activities? Where I'm trying to get to is: are we sure Infinispan is the culprit?
> It could be that our default config isn't suited to handle such things.
> So we're open for any suggestions.
> ---
> I've added this test to GAE TCK:
> * https://github.com/GoogleCloudPlatform/appengine-tck/blob/master/core/ben...
> You need CapeDwarf 2.0.0.CR2:
> * http://capedwarf.org/downloads/
> And clone GAE TCK:
> * https://github.com/GoogleCloudPlatform/appengine-tck
> Run CapeDwarf:
> * https://github.com/capedwarf/capedwarf-blue/blob/master/README.md (see (5))
> Then run the ObjectifyBenchmarkTest:
> * cd <GAE_TCK_HOME>
> * mvn clean install
> * cd core/benchmark
> * mvn clean install -Pcapedwarf,benchmark
> Ping me for any issues.
> Thanks!
> -Ales
> Cheers,
> --
> Mircea Markus
> Infinispan lead (www.infinispan.org)
9 years, 10 months
Reliability of return values
by Radim Vansa
Hi,
recently I've stumbled upon one already expected behaviour (one instance
is [1]), but which did not got much attention.
In non-tx cache, when the primary owner fails after the request has been
replicated to backup owner, the request is retried in the new topology.
Then, the operation is executed on the new primary (the previous
backup). The outcome has been already fixed in [2], but the return value
may be wrong. For example, when we do a put, the return value for the
second attempt will be the currently inserted value (although the entry
was just created). Same situation may happen for other operations.
Currently, it's not possible to return the correct value (because it has
already been overwritten and we don't keep a history of values), but
shouldn't we rather throw an exception if we were not able to fulfil the
API contract?
Radim
[1] https://issues.jboss.org/browse/ISPN-2956
[2] https://issues.jboss.org/browse/ISPN-3422
--
Radim Vansa <rvansa(a)redhat.com>
JBoss DataGrid QA
9 years, 10 months
OGM, Hot Rod and Grouping API
by Davide D'Alto
Hi all,
some time ago we talked on the mailing list about the integration between
Hibernate OGM and Hot Rod.
To achieve this we would need to include the grouping API in the Hot Rod
protocol and to add a couple of methods in the grouping API:
- to get the keys in a group
- to remove the keys in a group
Mircea created an experimental stub where the method " <G, KG> Set<KG>
getGroupKeys(G group) " is added to the Cache interface.
I've rebased the branch to the latest changes (I might have introduce some
errors): https://github.com/DavideD/infinispan/compare/ISPN-3981
I should have implemented the methods but I haven't had the time to work on
these features.
There are also two issues to keep track of this:
https://issues.jboss.org/browse/ISPN-3732
https://issues.jboss.org/browse/ISPN-3981
As far as I know, the API for Infinispan 7 is going to be freezed soon,
I was wondering if this changes have been taken into account and,
if not, is it possible to include them?
Thanks,
Davide
9 years, 10 months
book on Infinispan
by Mircea Markus
Hi Wagner,
How's the book progressing? If you want someone to review it happy to take a look.
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
9 years, 11 months
