<div dir="ltr"><br><div class="gmail_extra">Welcome Gustavo.<br></div><div class="gmail_extra">It is great to be colleagues again.<br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On 15 May 2014 14:29, <span dir="ltr"><<a href="mailto:infinispan-dev-request@lists.jboss.org" target="_blank">infinispan-dev-request@lists.jboss.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Send infinispan-dev mailing list submissions to<br>
<a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:infinispan-dev-request@lists.jboss.org">infinispan-dev-request@lists.jboss.org</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:infinispan-dev-owner@lists.jboss.org">infinispan-dev-owner@lists.jboss.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of infinispan-dev digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Re: [!] Reorganization of dependencies & release process<br>
(Sanne Grinovero)<br>
2. Re: Configuration XSD missing, Infinispan not parsing v.6<br>
configuration files ? (Pedro Ruivo)<br>
3. Re: Configuration XSD missing, Infinispan not parsing v.6<br>
configuration files ? (Sanne Grinovero)<br>
4. Re: Clustered Listener (William Burns)<br>
5. Welcome to Gustavo (Sanne Grinovero)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Wed, 14 May 2014 13:45:04 +0100<br>
From: Sanne Grinovero <<a href="mailto:sanne@infinispan.org">sanne@infinispan.org</a>><br>
Subject: Re: [infinispan-dev] [!] Reorganization of dependencies &<br>
release process<br>
To: infinispan -Dev List <<a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a>><br>
Cc: Hardy Ferentschik <<a href="mailto:hardy@hibernate.org">hardy@hibernate.org</a>><br>
Message-ID:<br>
<<a href="mailto:CAFm4XO1Dev09T%2BfyVw6OrxV40hGE9-MR3BUVw1gJsXuTnJsppw@mail.gmail.com">CAFm4XO1Dev09T+fyVw6OrxV40hGE9-MR3BUVw1gJsXuTnJsppw@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
On 14 May 2014 13:19, Adrian Nistor <<a href="mailto:anistor@redhat.com">anistor@redhat.com</a>> wrote:<br>
> +1 for moving Infinispan lucene directory out<br>
><br>
> But why move Query components out? And which ones did you have in mind?<br>
<br>
Because it depends on the Directory, but also on Hibernate Search, so<br>
it "mandates" a specific version of Apache Lucene.<br>
By moving these out of the core release, we can make Infinispan (core)<br>
releases independently from specific Lucene versions.<br>
<br>
Lucene lately is being quite aggressive in changes, and so doing we<br>
can have a single point of surgery at a time: the Directory first, tag<br>
it. Search, tag it.<br>
Then Infinispan Query and Infinispan full releases. Note how each<br>
component has the freedom to choose to *not* update Lucene or *not*<br>
update Infinispan core, if it needs to make unrelated fixes available<br>
early on.<br>
<br>
So I think it's necessary to move all Query components out too, seems<br>
like the only way out. A more open question is if other components<br>
would benefit from a similar model? I think so, although the reasons<br>
are less urgent.<br>
<br>
Sanne<br>
<br>
><br>
> On 05/14/2014 12:50 AM, Sanne Grinovero wrote:<br>
>> This is a reboot of the thread previously started on both the<br>
>> infinispan-dev and the hibernate-dev mailing list as "Handling of<br>
>> mutual dependency with Infinispan" [1].<br>
>> We discussed further during the Hibernate fortnightly meeting [2], and<br>
>> came to the conclusion that we need Infinispan to change how some<br>
>> repositories are organised and how the release is assembled.<br>
>><br>
>> # The problem<br>
>><br>
>> To restate the issue, as you might painfully remember, every time<br>
>> there is a need for a Lucene update or a Search update we need to sync<br>
>> up for a complex dance of releases in both projects to accommodate for<br>
>> a small-step iterative process to handle the circular dependency.<br>
>> This problem is not too bad today as since a year we're releasing the<br>
>> Lucene Directory in an unusual - and very unmaintainable - temporary<br>
>> solution to be compatible with two different major versions of Apache<br>
>> Lucene; namely what Infinispan Query needs and what Hibernate Search<br>
>> needs are different modules.<br>
>> But the party is over, and I want to finally drop support for Lucene 3<br>
>> and cleanup the unusual and unmaintainable build mess targeting a<br>
>> single Lucene version only.<br>
>> As soon as we converge to building a single version however - we're<br>
>> back to the complex problem we had when we supported a single version<br>
>> which is handling of a circular dependency - just that the problem has<br>
>> worsened lately the Lucene project has been more active and more<br>
>> inclined than what it used to be to break both internal and public<br>
>> APIs.<br>
>><br>
>> In short, we have a circular dependency between Hibernate Search and<br>
>> Infinispan which we've been able to handle via hacks and some luck,<br>
>> but it imposes a serious threat to development flexibility, and the<br>
>> locked-in release process is not desirable either.<br>
>><br>
>> # The solution<br>
>><br>
>> we think in conclusion there's a single "proper" way out, and it also<br>
>> happens to provide some very interesting side effects in terms of<br>
>> maintenance overhead for everyone: Infinispan Core needs to release<br>
>> independently from the non-core modules.<br>
>> This would have the Lucene Directory depend on a released tag of<br>
>> infinispan-core, and be able to be released independently.<br>
>> Minor situations with benefit:<br>
>> - we often don't make any change in the Lucene Directory, still we<br>
>> need to release it.<br>
>> - when I actually need a release of it, I'm currently begging for a<br>
>> quick release of Infinispan: very costly<br>
>> The Big Ones:<br>
>> - we can manage the Lucene Directory to provide support for different<br>
>> versions of Lucene without necessarily breaking other modules<br>
>> - we can release quickly what's needed to move Search ahead in terms<br>
>> of Lucene versions without needing to make the Infinispan Query module<br>
>> compatible at the same time (in case you haven't followed this area:<br>
>> this seems to be my main activity rather than making valuable stuff).<br>
>><br>
>> The goal is of course to linearise the dependencies; it seems to also<br>
>> simplify some of our tasks which is a welcome side-effect. I expect it<br>
>> also to make the project less scary for new contributors.<br>
>><br>
>> # How does it impact users<br>
>><br>
>> ## Maven users<br>
>> modules will continue to be modules.. I guess nobody will notice,<br>
>> other than we might have a different versioning scheme, but we help<br>
>> people out via the Infinispan BOM.<br>
>><br>
>> ## Distribution users<br>
>> There should be no difference, other than (as well) some jars might<br>
>> not be aligned in terms of version. But that's probably even less of a<br>
>> problem, as I expect distribution users to just put what they get on<br>
>> their classpath.<br>
>><br>
>> # How it impacts us<br>
>><br>
>> 1) I'll move the Lucene Directory project to an different repository;<br>
>> same for the Query related components.<br>
>> I think you should/could consider the same for other components, based<br>
>> on ad-hoc considerations of the trade offs, but I'd expect ultimately<br>
>> to see a more frequent and "core only" release.<br>
>><br>
>> 2) We'll have different kinds of releases: the "core only" and the<br>
>> "full releases".<br>
>> I think we'll also see components being released independently, but<br>
>> these are either Maven-only or meant for preparation of other<br>
>> components, or preparation for a "full release".<br>
>><br>
>> 3) Tests (!)<br>
>> Such a move should in no way relax the regression-safety of<br>
>> infinispan-core: we need to still consider it unacceptable for a core<br>
>> change to break one of the modules moving out of the main tree.<br>
>> Personally I think I've pushed many tests about problems found in the<br>
>> "query modules" as unit tests in core, so that should be relatively<br>
>> safe, but it also happened that someone would "tune" these.<br>
>> I realise it's not practical to expect people to run tests of<br>
>> downstream modules, so we'll have to automate most of these tasks in<br>
>> CI.<br>
>> Careful on perception: if today there are three levels of defence<br>
>> against a regression (the author, the reviewer and CI all running the<br>
>> suite for each change), in such an organisation you have only one. So<br>
>> ignoring a CI failure as a "probable hiccup" could be much more<br>
>> dangerous than usual.<br>
>><br>
>> # When<br>
>><br>
>> Doing this _might_ be a blocker for any Lucene update; so since one<br>
>> just happened I'll probably have no urgent need for a couple of weeks<br>
>> at least.<br>
>> But we shouldn't be in a position in which an update could not be<br>
>> possible, so I hope we'll agree to implement this sooner rather than<br>
>> later, so we won't have to do it during an emergency.<br>
>><br>
>> Also while this might sound a bit crazy at first, I see many<br>
>> flexibility benefits which can't hurt now that the project is getting<br>
>> larger and more complex to release.<br>
>> Not least, having a micro release of "Infinispan essentials" would be<br>
>> very welcome in terms of lowing the initial barrier; this was proposed<br>
>> at various meetings and highly endorsed by many but just never<br>
>> happened.<br>
>><br>
>> Any comment please? I hope I covered it all, and sorry for that :D<br>
>><br>
>> Cheers,<br>
>> Sanne<br>
>><br>
>><br>
>> 1 - <a href="http://lists.jboss.org/pipermail/hibernate-dev/2014-May/011419.html" target="_blank">http://lists.jboss.org/pipermail/hibernate-dev/2014-May/011419.html</a><br>
>> 2 - <a href="http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/hibernate-dev.2014-05-13-13.24.log.html" target="_blank">http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/hibernate-dev.2014-05-13-13.24.log.html</a><br>
>> _______________________________________________<br>
>> infinispan-dev mailing list<br>
>> <a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
>> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
><br>
> _______________________________________________<br>
> infinispan-dev mailing list<br>
> <a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
<br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Wed, 14 May 2014 14:00:17 +0100<br>
From: Pedro Ruivo <<a href="mailto:pedro@infinispan.org">pedro@infinispan.org</a>><br>
Subject: Re: [infinispan-dev] Configuration XSD missing, Infinispan<br>
not parsing v.6 configuration files ?<br>
To: <a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
Message-ID: <<a href="mailto:537368E1.6020206@infinispan.org">537368E1.6020206@infinispan.org</a>><br>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed<br>
<br>
Hi Sanne,<br>
<br>
I have added the 7.0 schemas to <a href="http://infinispan.org/schemas" target="_blank">infinispan.org/schemas</a>.<br>
<br>
About the 6.0 parsing, yes I think it was supposed to be not parsed :P I<br>
think I saw some warning about this change but I can't find it (so maybe<br>
I was dreaming). So, agree with you. we need an upgrade guide (however,<br>
the documentation already uses the new style)<br>
<br>
Cheers,<br>
Pedro<br>
<br>
On 05/14/2014 01:32 PM, Sanne Grinovero wrote:<br>
> On 14 May 2014 09:58, Pedro Ruivo <<a href="mailto:pedro@infinispan.org">pedro@infinispan.org</a>> wrote:<br>
>> yes, the release process put the schema here:<br>
>> <a href="http://docs.jboss.org/infinispan/schemas/" target="_blank">http://docs.jboss.org/infinispan/schemas/</a><br>
><br>
> Thanks, I'll use that. But shouldn't we have it at the URL I posted too??<br>
><br>
> And is it really expected that we don't parse old-style configuration files?<br>
> That's quite annoying for users. If it's the intended plan, I'm not<br>
> against it but we'd need some clear warning and also some guidance for<br>
> an upgrade.<br>
> (BTW great job on the documentation updates)<br>
><br>
> Cheers,<br>
> Sanne<br>
><br>
>><br>
>> Pedro<br>
>><br>
>> On 05/14/2014 07:50 AM, Tristan Tarrant wrote:<br>
>>> Isn't the deployment of XSDs part of the release process ?<br>
>>><br>
>>> Tristan<br>
>>><br>
>>> On 14/05/2014 01:36, Sanne Grinovero wrote:<br>
>>>> The testing configuration files seem to point to this URL:<br>
>>>> <a href="http://www.infinispan.org/schemas/infinispan-config-7.0.xsd" target="_blank">http://www.infinispan.org/schemas/infinispan-config-7.0.xsd</a><br>
>>>><br>
>>>> But I'm getting a 404 when attempting to find it.<br>
>>>><br>
>>>> It would be very helpfull to make this available, as it seems<br>
>>>> Infinispan 7.0.0.Alpha4 is unable to read the old configuration format<br>
>>>> :-(<br>
>>>><br>
>>>> Is that expected?<br>
>>>><br>
>>>> Message: Unexpected element '{urn:infinispan:config:6.0}infinispan'<br>
>>>> at org.infinispan.configuration.parsing.ParserRegistry.parse(ParserRegistry.java:100)<br>
>>>> at org.infinispan.test.fwk.TestCacheManagerFactory.fromStream(TestCacheManagerFactory.java:106)<br>
>>>> at org.infinispan.test.fwk.TestCacheManagerFactory.fromXml(TestCacheManagerFactory.java:97)<br>
>>>> at org.infinispan.test.fwk.TestCacheManagerFactory.fromXml(TestCacheManagerFactory.java:91)<br>
>>>> at org.infinispan.manager.CacheManagerXmlConfigurationTest.testBatchingIsEnabled(CacheManagerXmlConfigurationTest.java:126)<br>
>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)<br>
>>>> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)<br>
>>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)<br>
>>>> at java.lang.reflect.Method.invoke(Method.java:606)<br>
>>>> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)<br>
>>>> at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)<br>
>>>> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)<br>
>>>> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)<br>
>>>> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)<br>
>>>> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)<br>
>>>> at org.testng.TestRunner.privateRun(TestRunner.java:767)<br>
>>>> at org.testng.TestRunner.run(TestRunner.java:617)<br>
>>>> at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)<br>
>>>> at org.testng.SuiteRunner.access$000(SuiteRunner.java:37)<br>
>>>> at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:368)<br>
>>>> at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64)<br>
>>>> at java.util.concurrent.FutureTask.run(FutureTask.java:262)<br>
>>>> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)<br>
>>>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)<br>
>>>> at java.lang.Thread.run(Thread.java:744)<br>
>>>> Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[5,41]<br>
>>>> Message: Unexpected element '{urn:infinispan:config:6.0}infinispan'<br>
>>>> at org.infinispan.configuration.parsing.ParserRegistry.parseElement(ParserRegistry.java:137)<br>
>>>> at org.infinispan.configuration.parsing.ParserRegistry.parse(ParserRegistry.java:121)<br>
>>>> at org.infinispan.configuration.parsing.ParserRegistry.parse(ParserRegistry.java:108)<br>
>>>> at org.infinispan.configuration.parsing.ParserRegistry.parse(ParserRegistry.java:95)<br>
>>>> ... 24 more<br>
>>>> _______________________________________________<br>
>>>> infinispan-dev mailing list<br>
>>>> <a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
>>>> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
>>>><br>
>>><br>
>>> _______________________________________________<br>
>>> infinispan-dev mailing list<br>
>>> <a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
>>> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
>>><br>
>> _______________________________________________<br>
>> infinispan-dev mailing list<br>
>> <a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
>> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
> _______________________________________________<br>
> infinispan-dev mailing list<br>
> <a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
><br>
<br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Wed, 14 May 2014 16:16:12 +0100<br>
From: Sanne Grinovero <<a href="mailto:sanne@infinispan.org">sanne@infinispan.org</a>><br>
Subject: Re: [infinispan-dev] Configuration XSD missing, Infinispan<br>
not parsing v.6 configuration files ?<br>
To: infinispan -Dev List <<a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a>><br>
Message-ID:<br>
<<a href="mailto:CAFm4XO2NncDr6z9KSiRH70bNK_gmMMDw2HSD9CM%2B1NJ3Z6p2Hw@mail.gmail.com">CAFm4XO2NncDr6z9KSiRH70bNK_gmMMDw2HSD9CM+1NJ3Z6p2Hw@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
On 14 May 2014 14:00, Pedro Ruivo <<a href="mailto:pedro@infinispan.org">pedro@infinispan.org</a>> wrote:<br>
> Hi Sanne,<br>
><br>
> I have added the 7.0 schemas to <a href="http://infinispan.org/schemas" target="_blank">infinispan.org/schemas</a>.<br>
<br>
Thanks!<br>
<br>
><br>
> About the 6.0 parsing, yes I think it was supposed to be not parsed :P I<br>
> think I saw some warning about this change but I can't find it (so maybe<br>
> I was dreaming). So, agree with you. we need an upgrade guide (however,<br>
> the documentation already uses the new style)<br>
<br>
Yes the docs are very nice. I guess my problem is just that it's an<br>
unexpected issue; I somehow guess it from the stacktrace but I don't<br>
think everyone will be as familiar with the kind of error message.<br>
I'll open an issue to improve the error; if ever someone will<br>
volunteer to also write a couple of lines on how to migrate, we could<br>
link the page from the error message.<br>
<br>
><br>
> Cheers,<br>
> Pedro<br>
><br>
> On 05/14/2014 01:32 PM, Sanne Grinovero wrote:<br>
>> On 14 May 2014 09:58, Pedro Ruivo <<a href="mailto:pedro@infinispan.org">pedro@infinispan.org</a>> wrote:<br>
>>> yes, the release process put the schema here:<br>
>>> <a href="http://docs.jboss.org/infinispan/schemas/" target="_blank">http://docs.jboss.org/infinispan/schemas/</a><br>
>><br>
>> Thanks, I'll use that. But shouldn't we have it at the URL I posted too??<br>
>><br>
>> And is it really expected that we don't parse old-style configuration files?<br>
>> That's quite annoying for users. If it's the intended plan, I'm not<br>
>> against it but we'd need some clear warning and also some guidance for<br>
>> an upgrade.<br>
>> (BTW great job on the documentation updates)<br>
>><br>
>> Cheers,<br>
>> Sanne<br>
>><br>
>>><br>
>>> Pedro<br>
>>><br>
>>> On 05/14/2014 07:50 AM, Tristan Tarrant wrote:<br>
>>>> Isn't the deployment of XSDs part of the release process ?<br>
>>>><br>
>>>> Tristan<br>
>>>><br>
>>>> On 14/05/2014 01:36, Sanne Grinovero wrote:<br>
>>>>> The testing configuration files seem to point to this URL:<br>
>>>>> <a href="http://www.infinispan.org/schemas/infinispan-config-7.0.xsd" target="_blank">http://www.infinispan.org/schemas/infinispan-config-7.0.xsd</a><br>
>>>>><br>
>>>>> But I'm getting a 404 when attempting to find it.<br>
>>>>><br>
>>>>> It would be very helpfull to make this available, as it seems<br>
>>>>> Infinispan 7.0.0.Alpha4 is unable to read the old configuration format<br>
>>>>> :-(<br>
>>>>><br>
>>>>> Is that expected?<br>
>>>>><br>
>>>>> Message: Unexpected element '{urn:infinispan:config:6.0}infinispan'<br>
>>>>> at org.infinispan.configuration.parsing.ParserRegistry.parse(ParserRegistry.java:100)<br>
>>>>> at org.infinispan.test.fwk.TestCacheManagerFactory.fromStream(TestCacheManagerFactory.java:106)<br>
>>>>> at org.infinispan.test.fwk.TestCacheManagerFactory.fromXml(TestCacheManagerFactory.java:97)<br>
>>>>> at org.infinispan.test.fwk.TestCacheManagerFactory.fromXml(TestCacheManagerFactory.java:91)<br>
>>>>> at org.infinispan.manager.CacheManagerXmlConfigurationTest.testBatchingIsEnabled(CacheManagerXmlConfigurationTest.java:126)<br>
>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)<br>
>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)<br>
>>>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)<br>
>>>>> at java.lang.reflect.Method.invoke(Method.java:606)<br>
>>>>> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)<br>
>>>>> at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)<br>
>>>>> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)<br>
>>>>> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)<br>
>>>>> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)<br>
>>>>> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)<br>
>>>>> at org.testng.TestRunner.privateRun(TestRunner.java:767)<br>
>>>>> at org.testng.TestRunner.run(TestRunner.java:617)<br>
>>>>> at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)<br>
>>>>> at org.testng.SuiteRunner.access$000(SuiteRunner.java:37)<br>
>>>>> at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:368)<br>
>>>>> at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64)<br>
>>>>> at java.util.concurrent.FutureTask.run(FutureTask.java:262)<br>
>>>>> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)<br>
>>>>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)<br>
>>>>> at java.lang.Thread.run(Thread.java:744)<br>
>>>>> Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[5,41]<br>
>>>>> Message: Unexpected element '{urn:infinispan:config:6.0}infinispan'<br>
>>>>> at org.infinispan.configuration.parsing.ParserRegistry.parseElement(ParserRegistry.java:137)<br>
>>>>> at org.infinispan.configuration.parsing.ParserRegistry.parse(ParserRegistry.java:121)<br>
>>>>> at org.infinispan.configuration.parsing.ParserRegistry.parse(ParserRegistry.java:108)<br>
>>>>> at org.infinispan.configuration.parsing.ParserRegistry.parse(ParserRegistry.java:95)<br>
>>>>> ... 24 more<br>
>>>>> _______________________________________________<br>
>>>>> infinispan-dev mailing list<br>
>>>>> <a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
>>>>> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
>>>>><br>
>>>><br>
>>>> _______________________________________________<br>
>>>> infinispan-dev mailing list<br>
>>>> <a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
>>>> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
>>>><br>
>>> _______________________________________________<br>
>>> infinispan-dev mailing list<br>
>>> <a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
>>> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
>> _______________________________________________<br>
>> infinispan-dev mailing list<br>
>> <a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
>> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
>><br>
> _______________________________________________<br>
> infinispan-dev mailing list<br>
> <a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
<br>
<br>
------------------------------<br>
<br>
Message: 4<br>
Date: Thu, 15 May 2014 09:08:38 -0400<br>
From: William Burns <<a href="mailto:mudokonman@gmail.com">mudokonman@gmail.com</a>><br>
Subject: Re: [infinispan-dev] Clustered Listener<br>
To: infinispan -Dev List <<a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a>><br>
Message-ID:<br>
<CA+YCuUOsJ4ugVtg=8n=<a href="mailto:eZO0P5%2BsYxWgKC_paeh9vZLH_TY7-rg@mail.gmail.com">eZO0P5+sYxWgKC_paeh9vZLH_TY7-rg@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
On Tue, May 13, 2014 at 9:10 AM, Pierre Sutra <<a href="mailto:pierre.sutra@unine.ch">pierre.sutra@unine.ch</a>> wrote:<br>
> Hello,<br>
><br>
> As part of the LEADS project, we have been using recently the clustered<br>
> listeners API. In our use case, the application is employing a few<br>
> thousands listeners, constantly installing and un-installing them.<br>
<br>
Are you talking about non clustered listeners? It seems unlikely you<br>
would need so many cluster listeners. Cluster listeners should allow<br>
you to only install a small amount of them, usually you would have<br>
only additional ones if you have a Filter applied limiting what<br>
key/values are returned.<br>
<br>
> The<br>
> overall picture is that things work smoothly up to a few hundreds<br>
> listeners, but above the cost is high due to the full replication<br>
> schema. To sidestep this issue, we have added a mechanism that allows<br>
> listening only to a single key.<br>
<br>
Is the KeyFilter or KeyValueFilter not sufficient for this?<br>
<br>
void addListener(Object listener, KeyFilter<? super K> filter);<br>
<br>
<C> void addListener(Object listener, KeyValueFilter<? super K, ?<br>
super V> filter, Converter<? super K, ? super V, C> converter);<br>
<br>
Also to note if you are doing any kind of translation of the value to<br>
another value it is recommended to do that via the supplied Converter.<br>
This can give good performance as the conversion is done on the<br>
target node and not all in 1 node and also you can reduce the payload<br>
if the resultant value has a serialized form that is smaller than the<br>
original value.<br>
<br>
> In such a case, the listener is solely<br>
> installed at the key owners. This greatly helps the scalability of the<br>
> mechanism at the cost of fault-tolerance since, in the current state of<br>
> the implementation, listeners are not forwarded to new data owners.<br>
> Since as a next step [1] it is planned to handle topology change, do you<br>
> plan also to support key (or key range) specific listener ?<br>
<br>
These should be covered with the 2 overloads as I mentioned above.<br>
This should be the most performant way as the filter is replicated to<br>
the node upon installation so a 1 time cost. But if a key/value pair<br>
doesn't pass the filter the event is not sent to the node where the<br>
listener is installed.<br>
<br>
> Besides,<br>
> regarding this last point and the current state of the implementation, I<br>
> would have like to know what is the purpose of the re-installation of<br>
> the cluster listener in case of a view change in the addedListener()<br>
> method of the CacheNotifierImpl class.<br>
<br>
This isn't a re-installation. This is used to propgate the<br>
RemoteClusterListener to the other nodes, so that when a new event is<br>
generated it can see that and subsequently send it back to the node<br>
where the listener is installed. There is also a second check in<br>
there in case if a new node joins in the middle.<br>
<br>
> Many thanks in advance.<br>
<br>
No problem, glad you guys are testing out this feature already :)<br>
<br>
><br>
> Best,<br>
> Pierre Sutra<br>
><br>
> [1]<br>
> <a href="https://github.com/infinispan/infinispan/wiki/Clustered-listeners#handling-topology-changes" target="_blank">https://github.com/infinispan/infinispan/wiki/Clustered-listeners#handling-topology-changes</a><br>
><br>
> _______________________________________________<br>
> infinispan-dev mailing list<br>
> <a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
<br>
<br>
------------------------------<br>
<br>
Message: 5<br>
Date: Thu, 15 May 2014 14:29:17 +0100<br>
From: Sanne Grinovero <<a href="mailto:sanne@infinispan.org">sanne@infinispan.org</a>><br>
Subject: [infinispan-dev] Welcome to Gustavo<br>
To: infinispan -Dev List <<a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a>><br>
Message-ID:<br>
<CAFm4XO19aw3Uadiq0L0mimqgqZiOaTyWFr-G_=<a href="mailto:5KSKEd3DEQxw@mail.gmail.com">5KSKEd3DEQxw@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
Hi all,<br>
today we finally have Gustavo joining us as a full time engineer on Infinispan.<br>
<br>
He worked with Tristan and myself in Italy before we came to Red Hat,<br>
and was already a Lucene expert back then. He then joined Red Hat as a<br>
consultant but that didn't last too long: he was too good and<br>
customers wanted him to travel an unreasonable amount.<br>
<br>
So he has been lost for a couple of years, but wisely spent them to<br>
deepen his skills in devops, more of Lucene but now in larger scale<br>
and distributed environments: a bit of JGroups, Infinispan and<br>
Hibernate Search and even some Scala, but also experience with<br>
MongoDB, Hadoop, Elastic Search and Solr so I'm thrilled to have this<br>
great blend of competences now available full time to improve the<br>
Search experience of Infinispan users.<br>
<br>
Welcome!<br>
<br>
He's gustavonalle on both IRC and GitHub.<br>
<br>
Sanne<br>
<br>
<br>
------------------------------<br>
<br>
_______________________________________________<br>
infinispan-dev mailing list<br>
<a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
<br>
End of infinispan-dev Digest, Vol 62, Issue 12<br>
**********************************************<br>
</blockquote></div><br><br clear="all"><br>-- <br><div dir="ltr">Bilgin Ibryam<br><br>Apache Camel & Apache OFBiz committer<br>
Blog: <a href="http://ofbizian.com" target="_blank">ofbizian.com</a><br>Twitter: <a href="https://twitter.com/bibryam" target="_blank">@bibryam</a><br><br>Author of Instant Apache Camel Message Routing <br><a href="http://www.amazon.com/dp/1783283475" target="_blank">http://www.amazon.com/dp/1783283475</a><br>
<span><font color="#888888"></font></span></div>
</div></div>