FIFO ordering...
by Bryan Grunow
I posted JIRA issue https://jira.jboss.org/jira/browse/ISPN-132 a while ago and I'm wondering if it's on the roadmap anywhere?
I've worked on this internally and have a working solution but I'd like to know it's coming soon or not. If not I will continue working on it but I need some guidance on the design to make sure it fits properly into Infifispan.
Thanks,
Bryan
15 years, 1 month
Update on the DSL
by Navin Surtani
Hello all,
Just to let you know that I'm focusing on writing up the DSL asap. I
realise that since I've switched over to part-time due to university
term it's tough to keep in touch with everyone constantly. So I
thought I'd just drop the list a quick spam email.
Emmanuel, you had mentioned that you want this done fairly quick (from
other emails on the list) so I'm gonna push to do this as quick as I
can. The next couple of weeks are likely to be slightly busy but I
should have one or two Mondays off in the run-in to Devoxx so fingers
crossed over those I can sit down and hack through some coding. Also
since I'll be around for a full day it will be easier to communicate
via Skype etc etc.
I'll generally try and keep people updated as much as I can via
emailing the devlists so I can get some feedback/input/strokes of
genius from the various crews.
Thanks,
Navin Surtani
Intern Infinispan
Intern JBoss Cache Searchable
15 years, 1 month
Extreme transactions and replication
by Mark Little
One of the things we started to do with transactions and replication
was build a scalable replication protocol that unified replication and
cacheing.
http://www.cs.ncl.ac.uk/publications/inproceedings/papers/584.pdf
This works because strongly consistent replication protocols don't
scale beyond a few replicas or over more than a LAN. That's why weak
consistency protocols were developed back in the late 1980's. However,
the problem with them is that they are weakly (or eventually)
consistent and most applications can't cope with uncertainty.
Anyway, with the advent of Web Services and their need for
transactions that span multiple companies or organizations, the notion
of uncertainty of data becomes natural for those types of
applications: it is simply not possible to run transactions with
strict ACID semantics across large scale (number of participants and
physical location). Participants need to be split into domains and
there are typically known degrees of inconsistency between those
domains (e.g., it takes up to an hour for all domains to become
totally consistent assuming no further updates occur). Each
participant in the transaction may well be a subordinate transaction
coordinator (aka interposition) or a real business participant. If
it's the former then within a domain there's a guarantee of
consistency. Of course this is a hierarchical structure, so you can
have domains within domains.
This approach has impacts on the transaction manager: failure during
the "prepare" or "commit" protocol no longer necessarily means atomic
outcome or assuming everything will eventually undo. But also on the
replication protocols used (see paper). This is really what I call
extreme transaction processing, and not what Gartner understands it to
be. (Gartner and I have argued about this and last time we spoke I
won ;-)
We did some of this within the OASIS WS-CAF effort, but the
implementation needs revisiting. I've been working on and off (more
off than on) on updating the original paper and there's been interest
from our local university to collaborate on some R&D. I think JBossTS
+ Infinispan would work well to solve this problem.
Mark.
---
Mark Little
mlittle(a)redhat.com
JBoss, by Red Hat
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire, SI4 1TE, United Kingdom.
Registered in UK and Wales under Company Registration No. 3798903
Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt
Parsons (USA) and Brendan Lane (Ireland).
15 years, 1 month
Re: [infinispan-dev] Module configuration proposal
by Manik Surtani
Hmm, I don't know. The whole purpose behind this was to simplify our inter-module dependencies on config beans, etc. And if simplifying means pushing more complexity on to the end user, then that's not good. I'd rather have inter-dependencies and complexity in our codebase and a simple end-user experience than the other way around.
I suppose the alternative is that every time a module requires some cfg params, we modify the Configuration bean in core to accommodate this. So this will add *some* knowledge of the modules in core (only from a configuration perspective) but at least it would keep the end-user experience clean. So in the case of querying, something like:
Configuration.setIndexingEnabled(), Configuration.setIndexLocalOnly() and this would give us a config file that looks like the following?
<infinispan>
<namedCache name="blah">
<indexing enabled="true" localOnly="false" />
</>
</>
If that is the case then this would mean we don't bother with ISPN-193 - sorry, I know you did put effort into investigating this :( - but we would still need ISPN-245.
Thoughts?
Cheers
Manik
----- Original Message -----
From: "Vladimir Blagojevic" <vblagoje(a)redhat.com>
To: "infinispan -Dev List" <infinispan-dev(a)lists.jboss.org>
Sent: Sunday, 8 November, 2009 20:29:27 GMT +00:00 GMT Britain, Ireland, Portugal
Subject: Re: [infinispan-dev] Module configuration proposal
I do understand that sentiment - not wanting to overwhelm end user with
complex configuration file. How about we make a trade off. Module
develop can specify default configuration bean setup in module.cfg (XML
format), end user just references that module in cache.xml. End user, of
course, has an option to change or overrride configuration in that
module.cfg file package by either modifying it inside module jar or by
specifying configuration directly in cache.xml as we have it now.
<infinispan>
<namedCache name="blah">
<modules>
<module name="query"/>
</modules>
</>
</>
On 09-11-08 11:04 AM, Manik Surtani wrote:
> Hmm - lets have a think about this. Can't say I like having the<module> tag exposed to end users.
>
> So I guess the alternative is to have module-specific config beans in the core module? E.g., move the QueryConfiguration to the core package, and then we could have something like the following?
>
>
>> <infinispan>
>> <namedCache name="blah">
>> <indexing enabled="true" localOnly="false" />
>> </>
>> </>
>>
> Cheers
> Manik
>
>
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
15 years, 1 month
playing as Hudson
by Sanne Grinovero
Hello,
I'm going to play the role of Hudson today, as the last build
published on http://hudson.jboss.org/hudson/view/Infinispan/ is from 5
months ago.
Isn't there a working CI for Infinispan? I've had some trouble today
with unexpected issues, according to JIRA I could find some issues
related to my problems,
but most of them were solved recently according to JIRA. The tests I
just have run are having a different opinion:
Failed tests:
testTransactional(org.infinispan.distribution.rehash.ConcurrentOverlappingLeaveTest)
testWriteSkewWithOnlyPut(org.infinispan.api.mvcc.repeatable_read.WriteSkewTest)
testEnableJmxStats(org.infinispan.jmx.RpcManagerMBeanTest)
testTransactional(org.infinispan.distribution.rehash.ConcurrentJoinTest)
testNonTransactional(org.infinispan.distribution.rehash.ConcurrentJoinTest)
testonInfinispanDIST(org.infinispan.stress.PutIfAbsentStressTest)
Some comments:
org.infinispan.distribution.rehash.ConcurrentOverlappingLeaveTest
Is NOT failing consistently (it sometimes runs fine); It's
inconsistent even running it alone mvn test
-Dtest=org.infinispan.distribution.rehash.ConcurrentOverlappingLeaveTest
org.infinispan.api.mvcc.repeatable_read.WriteSkewTest
Is failing all the time.
org.infinispan.jmx.RpcManagerMBeanTest is "interesting" as the assert
fails on this message "Expected 1, was 1".
Debugging I see it's the wrong type:
mBeanServer.getAttribute(rpcManager1, "ReplicationCount").equals("1")
fails because getAttribute is returning a "Long", not a String.
org.infinispan.distribution.rehash.ConcurrentJoinTest
This one was the reason for me to rerun all tests, as it's making me
fail several Lucene index tests.
The message "Some caches have not finished rehashing after 8 minutes":
gets me a bit worried :-)
org.infinispan.stress.PutIfAbsentStressTest
This one is also breaking Lucene; we know for sure that it was running
fine as I've tested it several times when Markus fixed the related
issue.
I'm attaching the full reports with stacktraces.
Isn't there a real Hudson running to prevent this? The weird things I
experienced today were killing my brain, as I was looking in the wrong
direction expecting that stuff fixed last week was stil fine.
Sorry for telling that all was fine with Lucene Directory this
morning; I'm going to step through recent versions to identify the
breaking change, it's the only way I can help.
Cheers,
Sanne
15 years, 1 month
Releasing 4.0.0.CR2
by Manik Surtani
Hello all.
How does everyone feel about cutting 4.0.0.CR2 this week? I think we have some important fixes in place:
http://tinyurl.com/ydb4ucd
including an API one (yes, I know I hate myself for doing this so late) - ISPN-251
Anyway, how do people feel about getting their open issues in by close of Wednesday? What do people have pending?
Noel - you reckon you could have the code part of ISPN-123 in place by then?
Sanne - what's the state of the Lucene dir provider?
Vladimir - I don't think ISPN-245 has any impact on this release since it is an internal API and not used at the moment anyway, although if it is in place it would be good to change the Query module to use it - a good showcase.
Galder/Mircea - anything else pending? Galder let's chat re: ISPN-259 on IRC.
Cheers
Manik
15 years, 1 month
Lucene Directory status
by Sanne Grinovero
Hi,
I think the Lucene Directory is in good shape; I'm not aware of any
good reason to not include it in CR2; still some improvements could be
done on locking, but I'll keep that to another thread.
I've prepared a little demo-like application to run in a terminal, you
can launch it several times and then add/query a simple string on the
different processes and verify they are sharing the index. This is not
in SVN and would need a couple of hours to frame it in some packaging;
would you like me to contribute it somewhere? as a subproject of
lucene-directory or demos/lucene ? The "demos/directory" is clashing a
bit on names, any better option?
cheers,
Sanne
15 years, 1 month
Module configuration proposal
by Vladimir Blagojevic
Hey guys,
I completed module configuration proposal Manik and I agreed upon. It is
very important to get this one right so I want to run it by you before
proceeding further!
Have a look at [1] and follow proposed module configuration example below:
<infinispan xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="urn:infinispan:config:4.0">
<global>
<transport clusterName="demoCluster"/>
</global>
<default>
<clustering mode="replication">
</clustering>
<modules>
<module name="query"
configClassName="org.infinispan.query.config.QueryConfigurationBean">
<indexing enabled="true" indexLocalOnly="true"/>
</module>
</modules>
</default>
</infinispan>
A few things to notice:
a) Any configuration (including default and namedCache) can have a
module definition
b) Instance of configClassName is a rich object structure filled from
module's child XML content
c) Module's XML content can be arbitrary
d) Custom module configuration bean is accessed by module name:
Configuration def = c.parseDefaultConfiguration();
ModuleConfigurationBean extensionConfig =
def.getModuleConfigurationBean("query");
QueryConfigurationBean bean = (QueryConfigurationBean)
extensionConfig.getConfigurationBean();
assert bean.isEnabled();
assert bean.isIndexLocalOnly();
The proposal achieves full flexibility when it comes to having rich
object configuration structure that modules define themselves.
Furthermore, core module is completely isolated from module
configuration extensions. Schema easily accommodates this model and
there is no adverse effect on performance!
[1] https://jira.jboss.org/jira/browse/ISPN-193
15 years, 1 month
decommission s3 cachestore
by Adrian Cole
Hi, team.
There are a lot of differences between the beta-2 s3 implementation of
jclouds and "blobstore" our portable cross/cloud storage engine.
Moreover, there are significant differences between the s3 code in
jclouds trunk and the beta-2 one used by infinispan.
There's as much work to do rewriting and retesting cachestore-s3 as
there is to make cachestore-cloud, which could open infinispan to a
few more clouds.
AFAIK, the current cachestore-s3 is stable and is in no emergency to
update. I'd recommend leaving the cachestore-s3 as is with the
beta-2 version of jclouds and deprecating it in favor of
cachestore-clouds. It is then a scheduling decision whether to block
infinispoan GA on cachestore-clouds, or leave it for a follow-up.
What do you think?
Regards,
-Adrian
15 years, 2 months
