[infinispan-dev] Welcome to Gustavo
Bilgin Ibryam
bibryam at gmail.com
Sun May 18 04:53:53 EDT 2014
Welcome Gustavo.
It is great to be colleagues again.
On 15 May 2014 14:29, <infinispan-dev-request at lists.jboss.org> wrote:
> Send infinispan-dev mailing list submissions to
> infinispan-dev at lists.jboss.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> or, via email, send a message with subject or body 'help' to
> infinispan-dev-request at lists.jboss.org
>
> You can reach the person managing the list at
> infinispan-dev-owner at lists.jboss.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of infinispan-dev digest..."
>
>
> Today's Topics:
>
> 1. Re: [!] Reorganization of dependencies & release process
> (Sanne Grinovero)
> 2. Re: Configuration XSD missing, Infinispan not parsing v.6
> configuration files ? (Pedro Ruivo)
> 3. Re: Configuration XSD missing, Infinispan not parsing v.6
> configuration files ? (Sanne Grinovero)
> 4. Re: Clustered Listener (William Burns)
> 5. Welcome to Gustavo (Sanne Grinovero)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 14 May 2014 13:45:04 +0100
> From: Sanne Grinovero <sanne at infinispan.org>
> Subject: Re: [infinispan-dev] [!] Reorganization of dependencies &
> release process
> To: infinispan -Dev List <infinispan-dev at lists.jboss.org>
> Cc: Hardy Ferentschik <hardy at hibernate.org>
> Message-ID:
> <
> CAFm4XO1Dev09T+fyVw6OrxV40hGE9-MR3BUVw1gJsXuTnJsppw at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On 14 May 2014 13:19, Adrian Nistor <anistor at redhat.com> wrote:
> > +1 for moving Infinispan lucene directory out
> >
> > But why move Query components out? And which ones did you have in mind?
>
> Because it depends on the Directory, but also on Hibernate Search, so
> it "mandates" a specific version of Apache Lucene.
> By moving these out of the core release, we can make Infinispan (core)
> releases independently from specific Lucene versions.
>
> Lucene lately is being quite aggressive in changes, and so doing we
> can have a single point of surgery at a time: the Directory first, tag
> it. Search, tag it.
> Then Infinispan Query and Infinispan full releases. Note how each
> component has the freedom to choose to *not* update Lucene or *not*
> update Infinispan core, if it needs to make unrelated fixes available
> early on.
>
> So I think it's necessary to move all Query components out too, seems
> like the only way out. A more open question is if other components
> would benefit from a similar model? I think so, although the reasons
> are less urgent.
>
> Sanne
>
> >
> > On 05/14/2014 12:50 AM, Sanne Grinovero wrote:
> >> 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/hibernate-dev.2014-05-13-13.24.log.html
> >> _______________________________________________
> >> infinispan-dev mailing list
> >> infinispan-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >
> > _______________________________________________
> > infinispan-dev mailing list
> > infinispan-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 14 May 2014 14:00:17 +0100
> From: Pedro Ruivo <pedro at infinispan.org>
> Subject: Re: [infinispan-dev] Configuration XSD missing, Infinispan
> not parsing v.6 configuration files ?
> To: infinispan-dev at lists.jboss.org
> Message-ID: <537368E1.6020206 at infinispan.org>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Hi Sanne,
>
> I have added the 7.0 schemas to infinispan.org/schemas.
>
> About the 6.0 parsing, yes I think it was supposed to be not parsed :P I
> think I saw some warning about this change but I can't find it (so maybe
> I was dreaming). So, agree with you. we need an upgrade guide (however,
> the documentation already uses the new style)
>
> Cheers,
> Pedro
>
> On 05/14/2014 01:32 PM, Sanne Grinovero wrote:
> > On 14 May 2014 09:58, Pedro Ruivo <pedro at infinispan.org> wrote:
> >> yes, the release process put the schema here:
> >> http://docs.jboss.org/infinispan/schemas/
> >
> > Thanks, I'll use that. But shouldn't we have it at the URL I posted too??
> >
> > And is it really expected that we don't parse old-style configuration
> files?
> > That's quite annoying for users. If it's the intended plan, I'm not
> > against it but we'd need some clear warning and also some guidance for
> > an upgrade.
> > (BTW great job on the documentation updates)
> >
> > Cheers,
> > Sanne
> >
> >>
> >> Pedro
> >>
> >> On 05/14/2014 07:50 AM, Tristan Tarrant wrote:
> >>> Isn't the deployment of XSDs part of the release process ?
> >>>
> >>> Tristan
> >>>
> >>> On 14/05/2014 01:36, Sanne Grinovero wrote:
> >>>> 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
> >>>> _______________________________________________
> >>>> infinispan-dev mailing list
> >>>> infinispan-dev at lists.jboss.org
> >>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >>>>
> >>>
> >>> _______________________________________________
> >>> infinispan-dev mailing list
> >>> infinispan-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >>>
> >> _______________________________________________
> >> infinispan-dev mailing list
> >> infinispan-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> > _______________________________________________
> > infinispan-dev mailing list
> > infinispan-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >
>
>
> ------------------------------
>
> Message: 3
> Date: Wed, 14 May 2014 16:16:12 +0100
> From: Sanne Grinovero <sanne at infinispan.org>
> Subject: Re: [infinispan-dev] Configuration XSD missing, Infinispan
> not parsing v.6 configuration files ?
> To: infinispan -Dev List <infinispan-dev at lists.jboss.org>
> Message-ID:
> <
> CAFm4XO2NncDr6z9KSiRH70bNK_gmMMDw2HSD9CM+1NJ3Z6p2Hw at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On 14 May 2014 14:00, Pedro Ruivo <pedro at infinispan.org> wrote:
> > Hi Sanne,
> >
> > I have added the 7.0 schemas to infinispan.org/schemas.
>
> Thanks!
>
> >
> > About the 6.0 parsing, yes I think it was supposed to be not parsed :P I
> > think I saw some warning about this change but I can't find it (so maybe
> > I was dreaming). So, agree with you. we need an upgrade guide (however,
> > the documentation already uses the new style)
>
> Yes the docs are very nice. I guess my problem is just that it's an
> unexpected issue; I somehow guess it from the stacktrace but I don't
> think everyone will be as familiar with the kind of error message.
> I'll open an issue to improve the error; if ever someone will
> volunteer to also write a couple of lines on how to migrate, we could
> link the page from the error message.
>
> >
> > Cheers,
> > Pedro
> >
> > On 05/14/2014 01:32 PM, Sanne Grinovero wrote:
> >> On 14 May 2014 09:58, Pedro Ruivo <pedro at infinispan.org> wrote:
> >>> yes, the release process put the schema here:
> >>> http://docs.jboss.org/infinispan/schemas/
> >>
> >> Thanks, I'll use that. But shouldn't we have it at the URL I posted
> too??
> >>
> >> And is it really expected that we don't parse old-style configuration
> files?
> >> That's quite annoying for users. If it's the intended plan, I'm not
> >> against it but we'd need some clear warning and also some guidance for
> >> an upgrade.
> >> (BTW great job on the documentation updates)
> >>
> >> Cheers,
> >> Sanne
> >>
> >>>
> >>> Pedro
> >>>
> >>> On 05/14/2014 07:50 AM, Tristan Tarrant wrote:
> >>>> Isn't the deployment of XSDs part of the release process ?
> >>>>
> >>>> Tristan
> >>>>
> >>>> On 14/05/2014 01:36, Sanne Grinovero wrote:
> >>>>> 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
> >>>>> _______________________________________________
> >>>>> infinispan-dev mailing list
> >>>>> infinispan-dev at lists.jboss.org
> >>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >>>>>
> >>>>
> >>>> _______________________________________________
> >>>> infinispan-dev mailing list
> >>>> infinispan-dev at lists.jboss.org
> >>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >>>>
> >>> _______________________________________________
> >>> infinispan-dev mailing list
> >>> infinispan-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >> _______________________________________________
> >> infinispan-dev mailing list
> >> infinispan-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >>
> > _______________________________________________
> > infinispan-dev mailing list
> > infinispan-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> ------------------------------
>
> Message: 4
> Date: Thu, 15 May 2014 09:08:38 -0400
> From: William Burns <mudokonman at gmail.com>
> Subject: Re: [infinispan-dev] Clustered Listener
> To: infinispan -Dev List <infinispan-dev at lists.jboss.org>
> Message-ID:
> <CA+YCuUOsJ4ugVtg=8n=
> eZO0P5+sYxWgKC_paeh9vZLH_TY7-rg at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On Tue, May 13, 2014 at 9:10 AM, Pierre Sutra <pierre.sutra at unine.ch>
> wrote:
> > 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.
>
> Are you talking about non clustered listeners? It seems unlikely you
> would need so many cluster listeners. Cluster listeners should allow
> you to only install a small amount of them, usually you would have
> only additional ones if you have a Filter applied limiting what
> key/values are returned.
>
> > 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.
>
> Is the KeyFilter or KeyValueFilter not sufficient for this?
>
> void addListener(Object listener, KeyFilter<? super K> filter);
>
> <C> void addListener(Object listener, KeyValueFilter<? super K, ?
> super V> filter, Converter<? super K, ? super V, C> converter);
>
> Also to note if you are doing any kind of translation of the value to
> another value it is recommended to do that via the supplied Converter.
> This can give good performance as the conversion is done on the
> target node and not all in 1 node and also you can reduce the payload
> if the resultant value has a serialized form that is smaller than the
> original value.
>
> > 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 ?
>
> These should be covered with the 2 overloads as I mentioned above.
> This should be the most performant way as the filter is replicated to
> the node upon installation so a 1 time cost. But if a key/value pair
> doesn't pass the filter the event is not sent to the node where the
> listener is installed.
>
> > 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.
>
> This isn't a re-installation. This is used to propgate the
> RemoteClusterListener to the other nodes, so that when a new event is
> generated it can see that and subsequently send it back to the node
> where the listener is installed. There is also a second check in
> there in case if a new node joins in the middle.
>
> > Many thanks in advance.
>
> No problem, glad you guys are testing out this feature already :)
>
> >
> > Best,
> > Pierre Sutra
> >
> > [1]
> >
> https://github.com/infinispan/infinispan/wiki/Clustered-listeners#handling-topology-changes
> >
> > _______________________________________________
> > infinispan-dev mailing list
> > infinispan-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> ------------------------------
>
> Message: 5
> Date: Thu, 15 May 2014 14:29:17 +0100
> From: Sanne Grinovero <sanne at infinispan.org>
> Subject: [infinispan-dev] Welcome to Gustavo
> To: infinispan -Dev List <infinispan-dev at lists.jboss.org>
> Message-ID:
> <CAFm4XO19aw3Uadiq0L0mimqgqZiOaTyWFr-G_=
> 5KSKEd3DEQxw at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> 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
>
>
> ------------------------------
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> End of infinispan-dev Digest, Vol 62, Issue 12
> **********************************************
>
--
Bilgin Ibryam
Apache Camel & Apache OFBiz committer
Blog: ofbizian.com
Twitter: @bibryam <https://twitter.com/bibryam>
Author of Instant Apache Camel Message Routing
http://www.amazon.com/dp/1783283475
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20140518/df2e447b/attachment-0001.html
More information about the infinispan-dev
mailing list