May 2014 - infinispan-dev - Jboss List Archives

by Manik Surtani

An awesome visual representation of RAFT that you guys should check out. http://thesecretlivesofdata.com/raft/ Some other good resources. http://thinkdistributed.io/blog/2013/07/12/consensus.html https://ramcloud.stanford.edu/wiki/download/attachments/11370504/raft.pdf https://github.com/mgodave/barge - M

10 years, 10 months

4
4
0 / 0

Re: [infinispan-dev] RAFT

by Gustavo Fernandes

On 16 May 2014 16:36, "Emmanuel Bernard" <emmanuel(a)hibernate.org> wrote: > > On Fri 2014-05-16 8:22, Bela Ban wrote: > > Interesting, thanks for the link ! > > Makes me want to implement this in JGroups. Should be relatively easy > > with *static* membership. Different ballgame though with dynamic > > memberships... > > That's the same of these approaches. They require a static membership. > Or number of nodes at least. > Section 6 of the Raft paper covers dynamic configuration (membership) changes, although it looks a bit involved Gustavo

10 years, 10 months

2
1
0 / 0

Welcome to Gustavo

by Sanne Grinovero

Hi all, today we finally have Gustavo joining us as a full time engineer on Infinispan. He worked with Tristan and myself in Italy before we came to Red Hat, and was already a Lucene expert back then. He then joined Red Hat as a consultant but that didn't last too long: he was too good and customers wanted him to travel an unreasonable amount. So he has been lost for a couple of years, but wisely spent them to deepen his skills in devops, more of Lucene but now in larger scale and distributed environments: a bit of JGroups, Infinispan and Hibernate Search and even some Scala, but also experience with MongoDB, Hadoop, Elastic Search and Solr so I'm thrilled to have this great blend of competences now available full time to improve the Search experience of Infinispan users. Welcome! He's gustavonalle on both IRC and GitHub. Sanne

10 years, 10 months

10
9
0 / 0

Configuration XSD missing, Infinispan not parsing v.6 configuration files ?

by Sanne Grinovero

The testing configuration files seem to point to this URL: http://www.infinispan.org/schemas/infinispan-config-7.0.xsd But I'm getting a 404 when attempting to find it. It would be very helpfull to make this available, as it seems Infinispan 7.0.0.Alpha4 is unable to read the old configuration format :-( Is that expected? Message: Unexpected element '{urn:infinispan:config:6.0}infinispan' at org.infinispan.configuration.parsing.ParserRegistry.parse(ParserRegistry.java:100) at org.infinispan.test.fwk.TestCacheManagerFactory.fromStream(TestCacheManagerFactory.java:106) at org.infinispan.test.fwk.TestCacheManagerFactory.fromXml(TestCacheManagerFactory.java:97) at org.infinispan.test.fwk.TestCacheManagerFactory.fromXml(TestCacheManagerFactory.java:91) at org.infinispan.manager.CacheManagerXmlConfigurationTest.testBatchingIsEnabled(CacheManagerXmlConfigurationTest.java:126) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80) at org.testng.internal.Invoker.invokeMethod(Invoker.java:714) at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901) at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231) at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127) at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111) at org.testng.TestRunner.privateRun(TestRunner.java:767) at org.testng.TestRunner.run(TestRunner.java:617) at org.testng.SuiteRunner.runTest(SuiteRunner.java:334) at org.testng.SuiteRunner.access$000(SuiteRunner.java:37) at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:368) at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:744) Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[5,41] Message: Unexpected element '{urn:infinispan:config:6.0}infinispan' at org.infinispan.configuration.parsing.ParserRegistry.parseElement(ParserRegistry.java:137) at org.infinispan.configuration.parsing.ParserRegistry.parse(ParserRegistry.java:121) at org.infinispan.configuration.parsing.ParserRegistry.parse(ParserRegistry.java:108) at org.infinispan.configuration.parsing.ParserRegistry.parse(ParserRegistry.java:95) ... 24 more

10 years, 10 months

4
6
0 / 0

[!] Reorganization of dependencies & release process

by Sanne Grinovero

This is a reboot of the thread previously started on both the infinispan-dev and the hibernate-dev mailing list as "Handling of mutual dependency with Infinispan" [1]. We discussed further during the Hibernate fortnightly meeting [2], and came to the conclusion that we need Infinispan to change how some repositories are organised and how the release is assembled. # The problem To restate the issue, as you might painfully remember, every time there is a need for a Lucene update or a Search update we need to sync up for a complex dance of releases in both projects to accommodate for a small-step iterative process to handle the circular dependency. This problem is not too bad today as since a year we're releasing the Lucene Directory in an unusual - and very unmaintainable - temporary solution to be compatible with two different major versions of Apache Lucene; namely what Infinispan Query needs and what Hibernate Search needs are different modules. But the party is over, and I want to finally drop support for Lucene 3 and cleanup the unusual and unmaintainable build mess targeting a single Lucene version only. As soon as we converge to building a single version however - we're back to the complex problem we had when we supported a single version which is handling of a circular dependency - just that the problem has worsened lately the Lucene project has been more active and more inclined than what it used to be to break both internal and public APIs. In short, we have a circular dependency between Hibernate Search and Infinispan which we've been able to handle via hacks and some luck, but it imposes a serious threat to development flexibility, and the locked-in release process is not desirable either. # The solution we think in conclusion there's a single "proper" way out, and it also happens to provide some very interesting side effects in terms of maintenance overhead for everyone: Infinispan Core needs to release independently from the non-core modules. This would have the Lucene Directory depend on a released tag of infinispan-core, and be able to be released independently. Minor situations with benefit: - we often don't make any change in the Lucene Directory, still we need to release it. - when I actually need a release of it, I'm currently begging for a quick release of Infinispan: very costly The Big Ones: - we can manage the Lucene Directory to provide support for different versions of Lucene without necessarily breaking other modules - we can release quickly what's needed to move Search ahead in terms of Lucene versions without needing to make the Infinispan Query module compatible at the same time (in case you haven't followed this area: this seems to be my main activity rather than making valuable stuff). The goal is of course to linearise the dependencies; it seems to also simplify some of our tasks which is a welcome side-effect. I expect it also to make the project less scary for new contributors. # How does it impact users ## Maven users modules will continue to be modules.. I guess nobody will notice, other than we might have a different versioning scheme, but we help people out via the Infinispan BOM. ## Distribution users There should be no difference, other than (as well) some jars might not be aligned in terms of version. But that's probably even less of a problem, as I expect distribution users to just put what they get on their classpath. # How it impacts us 1) I'll move the Lucene Directory project to an different repository; same for the Query related components. I think you should/could consider the same for other components, based on ad-hoc considerations of the trade offs, but I'd expect ultimately to see a more frequent and "core only" release. 2) We'll have different kinds of releases: the "core only" and the "full releases". I think we'll also see components being released independently, but these are either Maven-only or meant for preparation of other components, or preparation for a "full release". 3) Tests (!) Such a move should in no way relax the regression-safety of infinispan-core: we need to still consider it unacceptable for a core change to break one of the modules moving out of the main tree. Personally I think I've pushed many tests about problems found in the "query modules" as unit tests in core, so that should be relatively safe, but it also happened that someone would "tune" these. I realise it's not practical to expect people to run tests of downstream modules, so we'll have to automate most of these tasks in CI. Careful on perception: if today there are three levels of defence against a regression (the author, the reviewer and CI all running the suite for each change), in such an organisation you have only one. So ignoring a CI failure as a "probable hiccup" could be much more dangerous than usual. # When Doing this _might_ be a blocker for any Lucene update; so since one just happened I'll probably have no urgent need for a couple of weeks at least. But we shouldn't be in a position in which an update could not be possible, so I hope we'll agree to implement this sooner rather than later, so we won't have to do it during an emergency. Also while this might sound a bit crazy at first, I see many flexibility benefits which can't hurt now that the project is getting larger and more complex to release. Not least, having a micro release of "Infinispan essentials" would be very welcome in terms of lowing the initial barrier; this was proposed at various meetings and highly endorsed by many but just never happened. Any comment please? I hope I covered it all, and sorry for that :D Cheers, Sanne 1 - http://lists.jboss.org/pipermail/hibernate-dev/2014-May/011419.html 2 - http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/...

10 years, 10 months

4
5
0 / 0

Infinispan 7.0.0.Alpha4 is out!

by Pedro Ruivo

Hi, I'm proud to announce the Alpha4 release of Infinispan 7.0.0. More info in http://blog.infinispan.org/2014/05/infinispan-700alpha4-is-out.html Regards, Pedro

10 years, 10 months

1
0
0 / 0

How to terminate Infinispan instance in the distributed mode?

by Liguangpeng (Roc, IPTechnologyResearchDept&HW)

Hello Infinispan experts, I want to create a cluster of Infinispan which consist of multiple nodes. Then I expect to control the number of instances, so I want some nodes to quid gracefully. After reading the documents, I try cache.stop() to do so. But It seems not work, my application embedded with Infinispan does not terminated. Following is my sample code and result. Please point my mistake if I have. If this is not proper list, please tell me the right one. Thank you very much. Sample code: public static void main(String[] args) { test0(); } public static void test0() { EmbeddedCacheManager manager = new DefaultCacheManager( GlobalConfigurationBuilder.defaultClusteredBuilder() .transport().addProperty("configurationFile", "jgroups-tcp-x.xml") .globalJmxStatistics().allowDuplicateDomains(true) .build(), new ConfigurationBuilder() .clustering() .cacheMode(CacheMode.DIST_ASYNC) .hash().numOwners(1) .build() ); Cache<String, String> myCache = manager.getCache("mycache"); System.out.println("Cache instance started!"); myCache.stop(); System.out.println("Cache instance stopped!"); } Result: Cache instance started! Cache instance stopped! I expected the program terminates here, but it doesn't. Best Regards, Roc Lee

10 years, 10 months

2
2
0 / 0

[Search] Handling of mutual dependency with Infinispan

by Sanne Grinovero

Now that finally Infinispan moved to build (and require) Java7, I'm preparing to upgrade the Lucene Directory to Apache Lucene 4.8. Sometimes it's trivial, some others we're out of luck and this is one of such situations: the new Lucene code expects some new methods to create and validate a CRC32 checksum signature of the Directory segments. Not too annoying - I can handle the coding - but it highlights an old problem which is coming back. Currently Infinispan is still using Hibernate Search 4.5, and provides a Lucene Directory for both Lucene versions 3 and 4. The current build provides the LuceneV4 support as an extension of the V3 source module; this is a hack we introduced a year ago to make sure we'd eventually be able to upgrade to Lucene4 and I was hoping now to finally remove this fishy workaround as I initially expected it to be a temporary measure. But in practice such an upgrade of today would have been impossible: Infinispan also depends on Hibernate Search. Having two different modules in Infinispan is what enables us today to start an update to a new version of Lucene. I'm wondering if we should move the Lucene Directory code into Hibernate Search; this also has licensing implications as that's using ASL2 currently. And that's probably only moving the problem one step down, as Infinispan Query still depends on Hibernate Search (engine) and the Lucene Directory would still depend on Infinispan Core. I'm not having a solution in mind; obviously we wouldn't have such a problem if each of our projects *always* guaranteed a clean migration path via default methods and deprecated methods, but this is a rule which is occasionally broken: when it happens, the only thing I can think of is that one of the two projects needs to release a tag which has some broken components. For example, Infinispan to release occasionally without the Query engine. Sanne

10 years, 10 months

2
1
0 / 0

Infinispan REST CacheStore -> OOM

by Sanne Grinovero

Hi all, I'm unable to run the Infinispan testsuite because of OOM exceptions hapening in the testsuite of Infinispan REST CacheStore. Anyone else has seen the same problem? Cheers, Sanne

10 years, 10 months

1
0
0 / 0

New ISPN github sub-repositories for OData server and ispn-cakery

by Tomas Sykora

Hello all, Mircea, Galder, Sanne, Dan, I have created 2 new projects in the scope of my diploma thesis (http://tsykora-tech.blogspot.cz/2014/02/introducing-infinispan-odata-serv...): infinispan-odata-server & infinispan-cakery I'd like to integrate them "under upstream" and continue development there. Does our policy allow to create new sub-projects / sub-folders for me and grant push rights? I'd like to migrate them from my private repo under Infinispan. Just like we have: https://github.com/infinispan/infinispan-forge, https://github.com/infinispan/Infinispan-book or https://github.com/infinispan/infinispan-site-check It would make me extraordinary happy if I can obtain: https://github.com/infinispan/infinispan-odata-server and https://github.com/infinispan/infinispan-cakery sub-projects with pushing rights so I can start doing more work on it and more publicly. Thank you very much for any response! Tom

10 years, 10 months

3
2
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-dev May 2014