From anistor at redhat.com Wed Feb 1 02:12:59 2017 From: anistor at redhat.com (Adrian Nistor) Date: Wed, 1 Feb 2017 09:12:59 +0200 Subject: [infinispan-dev] CI failures Message-ID: <0dfc86c6-7dc9-2284-efdd-95b0961298ad@redhat.com> All builds are failing now due to this exception: java.lang.RuntimeException: "WFLYCTL0158: Operation handler failed: java.util.MissingResourceException: Can't find resource for bundle java.util.PropertyResourceBundle, key datagrid-infinispan.cache-container.sites-view" at org.jboss.as.subsystem.test.SubsystemTestDelegate.validateDescriptionProviders(SubsystemTestDelegate.java:581) at org.jboss.as.subsystem.test.SubsystemTestDelegate.access$500(SubsystemTestDelegate.java:118) One such failure here http://ci.infinispan.org/viewLog.html?buildId=48995&tab=buildResultsDiv&buildTypeId=Infinispan_MasterHotspotJdk8 I suspect the culprit to be https://github.com/infinispan/infinispan/pull/4769/ From ttarrant at redhat.com Wed Feb 1 02:31:16 2017 From: ttarrant at redhat.com (Tristan Tarrant) Date: Wed, 1 Feb 2017 08:31:16 +0100 Subject: [infinispan-dev] CI failures In-Reply-To: <0dfc86c6-7dc9-2284-efdd-95b0961298ad@redhat.com> References: <0dfc86c6-7dc9-2284-efdd-95b0961298ad@redhat.com> Message-ID: <66600413-aaac-4cdb-d76e-f28f244601f0@redhat.com> I have pushed a fix for this just now: https://github.com/infinispan/infinispan/commit/f317f8ae5173b34cfbb3205270db56da8fa5e262 Tristan On 01/02/17 08:12, Adrian Nistor wrote: > All builds are failing now due to this exception: > > java.lang.RuntimeException: "WFLYCTL0158: Operation handler failed: > java.util.MissingResourceException: Can't find resource for bundle > java.util.PropertyResourceBundle, key > datagrid-infinispan.cache-container.sites-view" at > org.jboss.as.subsystem.test.SubsystemTestDelegate.validateDescriptionProviders(SubsystemTestDelegate.java:581) > at > org.jboss.as.subsystem.test.SubsystemTestDelegate.access$500(SubsystemTestDelegate.java:118) > > One such failure here > http://ci.infinispan.org/viewLog.html?buildId=48995&tab=buildResultsDiv&buildTypeId=Infinispan_MasterHotspotJdk8 > > I suspect the culprit to be > https://github.com/infinispan/infinispan/pull/4769/ > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev > -- Tristan Tarrant Infinispan Lead JBoss, a division of Red Hat From anistor at redhat.com Wed Feb 1 06:54:37 2017 From: anistor at redhat.com (Adrian Nistor) Date: Wed, 1 Feb 2017 13:54:37 +0200 Subject: [infinispan-dev] CI failures In-Reply-To: <66600413-aaac-4cdb-d76e-f28f244601f0@redhat.com> References: <0dfc86c6-7dc9-2284-efdd-95b0961298ad@redhat.com> <66600413-aaac-4cdb-d76e-f28f244601f0@redhat.com> Message-ID: <0cfcf661-1ff5-5a0b-1b95-0e02b6280257@redhat.com> Thanks! On 02/01/2017 09:31 AM, Tristan Tarrant wrote: > I have pushed a fix for this just now: > > > https://github.com/infinispan/infinispan/commit/f317f8ae5173b34cfbb3205270db56da8fa5e262 > > Tristan > > On 01/02/17 08:12, Adrian Nistor wrote: >> All builds are failing now due to this exception: >> >> java.lang.RuntimeException: "WFLYCTL0158: Operation handler failed: >> java.util.MissingResourceException: Can't find resource for bundle >> java.util.PropertyResourceBundle, key >> datagrid-infinispan.cache-container.sites-view" at >> org.jboss.as.subsystem.test.SubsystemTestDelegate.validateDescriptionProviders(SubsystemTestDelegate.java:581) >> at >> org.jboss.as.subsystem.test.SubsystemTestDelegate.access$500(SubsystemTestDelegate.java:118) >> >> One such failure here >> http://ci.infinispan.org/viewLog.html?buildId=48995&tab=buildResultsDiv&buildTypeId=Infinispan_MasterHotspotJdk8 >> >> I suspect the culprit to be >> https://github.com/infinispan/infinispan/pull/4769/ >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> From galder at redhat.com Thu Feb 2 11:40:47 2017 From: galder at redhat.com (=?utf-8?Q?Galder_Zamarre=C3=B1o?=) Date: Thu, 2 Feb 2017 17:40:47 +0100 Subject: [infinispan-dev] REPL async semantics in the context of Hibernate 2LC In-Reply-To: References: <9AF3DDDD-22BE-489B-AC42-6810EE651E72@redhat.com> Message-ID: Hahaha, yeah, changed a while back but keeps catching me everytime :) Makes sense, the change came in as a result of having a single node owner of a key, and hence being able to apply changes in the right order. I'll add a bit more details to the 2L cache docu so that this is made clearer. Cheers, -- Galder Zamarre?o Infinispan, Red Hat > On 26 Jan 2017, at 14:30, Radim Vansa wrote: > > Hi Galder, > > I think that this was changed in Infinispan version 5.3 or so :) The > reason for this is that updates even in async cache are applied in the > same order on all owners. If you'd update local node A first to X, and > then asynchronously update the other node B, there could be a concurrent > update to Y on the other node B, and then the cluster would likely end > up with A having Y and B having X, without anything eventually resolving > this. Some locking has to be involved, too, and the algorithm in 5.3 > actually did not allow the values to diverge, but caused a deadlock. > > In 2LC, this can be eliminated in some cases, though - e.g. if we do > putIfAbsents with the same value, it's safe to apply the value locally > and sent the update asynchronously to the other node. For removals, it's > safe, too. Therefore, I have recently replaced distribution & locking > interceptors with 'optimized' version [1][2]. > > While I am strong adversary of the *_ASYNC modes in general, I think > that the consistent order of updates should be preserved there. And if > you do an async put to dist cache, you can't be sure that following read > will return the value either (and repl is just read-optimized+failure > resilient case of dist). > > Radim > > [1] > https://github.com/hibernate/hibernate-orm/blob/master/hibernate-infinispan/src/main/java/org/hibernate/cache/infinispan/access/UnorderedDistributionInterceptor.java > [2] > https://github.com/hibernate/hibernate-orm/blob/master/hibernate-infinispan/src/main/java/org/hibernate/cache/infinispan/access/LockingInterceptor.java > > On 01/26/2017 01:24 PM, Galder Zamarre?o wrote: >> Hi all, >> >> Forgive me if we've discussed this before (I vaguely remember...), but the current async semantics always through me off a bit, let me explain: >> >> I've been working on/off on Hibernate 2LC tutorial that demonstrates how to run 2LC on embedded, Wildfly and Spring set ups, and for each of them, explains how it all works in local vs clustered mode. >> >> One of the sections involves working with queries, updating an entity that's part of the query, and seeing how that query gets re-executed from the db. When an entity is updated, that entity's update timestamp gets updated in a cache, which in a cluster environment is configured with repl async. >> >> If you have two nodes A and B, it was expected that if you updated the entity in node A, you'd want to wait a tiny bit to run the query in node B so that the timestamp update would propagate to node B. >> >> However, recent async semantics work in such way that if you updated the entity in node A and wanted to execute the query in node A, you still might want to add a little delay... >> >> The reason for that is that the logic changes based on whether the ownership of entity type key in the update timestamp cache is in node A or node B. If the owner is node A, the cache is updated directly by the main thread. So you can execute a query on node A immediately after the update and it'll be fine. >> >> However, if the owner is node B, even if the update was done in node A, node A will only be updated asynchronously. So, if after calling an update on node A, you do a query on node A, in this scenario you'd get outdated results for a small period of time. [1] >> >> So, my question here is: can we do anything to make this more predictable from a users perspective? Or is it just not worth doing it? Or is it just a side effect that we must be aware off? >> >> Cheers, >> >> [1] https://gist.github.com/galderz/676f689884969658b01a7695f08dd7a2 >> -- >> Galder Zamarre?o >> Infinispan, Red Hat >> >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > > -- > Radim Vansa > JBoss Performance Team > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev From rory.odonnell at oracle.com Fri Feb 3 16:12:47 2017 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Fri, 3 Feb 2017 21:12:47 +0000 Subject: [infinispan-dev] JDK 9 EA Build 155 is available on java.net Message-ID: Hi Galder, *JDK 9 Early Access* b155 is available on java.net There have been a number of fixes to bugs reported by Open Source projects since the last availability email : * b155 - JDK-8167273 : Calendar.getDisplayNames inconsistent with DateFormatSymbols * b154 - JDK-8157611 : field visiblePackages is null for the unnamed module producing NPE when accessed * b153 - JDK-8163449 : Allow per protocol setting for URLConnection defaultUseCaches * b152 - JDK-8172158 : Annotation processor not run with -source <= 8 Dalibor and I are presenting at FOSDEM this weekend, we would love to meet you there! * JDK 9 Outreach - The Awesome Parts Rgds,Rory -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20170203/15f5e445/attachment.html From galder at redhat.com Mon Feb 6 10:34:49 2017 From: galder at redhat.com (=?utf-8?Q?Galder_Zamarre=C3=B1o?=) Date: Mon, 6 Feb 2017 16:34:49 +0100 Subject: [infinispan-dev] Weekly meeting notes Message-ID: <6B9A83BC-F203-455C-BF9D-58AF58CBC31D@redhat.com> Hi all, We've just had our weekly meeting, you can read what we've been up to here: http://transcripts.jboss.org/meeting/irc.freenode.org/infinispan/2017/infinispan.2017-02-06-15.06.html Cheers, -- Galder Zamarre?o Infinispan, Red Hat From galder at redhat.com Wed Feb 8 05:25:09 2017 From: galder at redhat.com (=?utf-8?Q?Galder_Zamarre=C3=B1o?=) Date: Wed, 8 Feb 2017 11:25:09 +0100 Subject: [infinispan-dev] Reverting ISPN-7426 because of hangs Message-ID: <84040069-BF26-41AD-B988-9E162EFDA90C@redhat.com> Hi all, I've sent a PR to revert ISPN-7426 since it hangs our OSGI tests endlessly [1]. Seems like Hibernate entitymanager in 5.2.x, which is used by our JPA store, is not very OSGI friendly [2]. In the mean time, I've stopped all PR builds since they're all hanged. Cheers, [1] https://github.com/infinispan/infinispan/pull/4836 [2] https://issues.jboss.org/browse/ISPN-7426 -- Galder Zamarre?o Infinispan, Red Hat From sanne at infinispan.org Wed Feb 8 06:18:15 2017 From: sanne at infinispan.org (Sanne Grinovero) Date: Wed, 8 Feb 2017 11:18:15 +0000 Subject: [infinispan-dev] Reverting ISPN-7426 because of hangs In-Reply-To: <84040069-BF26-41AD-B988-9E162EFDA90C@redhat.com> References: <84040069-BF26-41AD-B988-9E162EFDA90C@redhat.com> Message-ID: Hi Galder, we need that upgrade. I didn't know of the OSGi problem, that seems trivial to fix.. next time just ask me? BTW I'd have noticed myself if only it was possible to run the Infinispan testsuite locally w/o it having so many failures.. Thanks, Sanne On 8 February 2017 at 10:25, Galder Zamarre?o wrote: > Hi all, > > I've sent a PR to revert ISPN-7426 since it hangs our OSGI tests endlessly [1]. > > Seems like Hibernate entitymanager in 5.2.x, which is used by our JPA store, is not very OSGI friendly [2]. > > In the mean time, I've stopped all PR builds since they're all hanged. > > Cheers, > > [1] https://github.com/infinispan/infinispan/pull/4836 > [2] https://issues.jboss.org/browse/ISPN-7426 > -- > Galder Zamarre?o > Infinispan, Red Hat > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev From galder at redhat.com Wed Feb 8 06:22:22 2017 From: galder at redhat.com (=?utf-8?Q?Galder_Zamarre=C3=B1o?=) Date: Wed, 8 Feb 2017 12:22:22 +0100 Subject: [infinispan-dev] Reverting ISPN-7426 because of hangs In-Reply-To: References: <84040069-BF26-41AD-B988-9E162EFDA90C@redhat.com> Message-ID: We need builds to run too. We can't have commits that bring the build to a halt in such way that the build can't finish. Cheers, -- Galder Zamarre?o Infinispan, Red Hat > On 8 Feb 2017, at 12:18, Sanne Grinovero wrote: > > Hi Galder, > we need that upgrade. I didn't know of the OSGi problem, that seems > trivial to fix.. next time just ask me? > > BTW I'd have noticed myself if only it was possible to run the > Infinispan testsuite locally w/o it having so many failures.. > > Thanks, > Sanne > > On 8 February 2017 at 10:25, Galder Zamarre?o wrote: >> Hi all, >> >> I've sent a PR to revert ISPN-7426 since it hangs our OSGI tests endlessly [1]. >> >> Seems like Hibernate entitymanager in 5.2.x, which is used by our JPA store, is not very OSGI friendly [2]. >> >> In the mean time, I've stopped all PR builds since they're all hanged. >> >> Cheers, >> >> [1] https://github.com/infinispan/infinispan/pull/4836 >> [2] https://issues.jboss.org/browse/ISPN-7426 >> -- >> Galder Zamarre?o >> Infinispan, Red Hat >> >> >> _______________________________________________ >> 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 From sanne at hibernate.org Wed Feb 8 06:32:42 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Wed, 8 Feb 2017 11:32:42 +0000 Subject: [infinispan-dev] Reverting ISPN-7426 because of hangs In-Reply-To: References: <84040069-BF26-41AD-B988-9E162EFDA90C@redhat.com> Message-ID: I totally agree. This shouldn't have been merged in the first place, but now that it's there and not that I know of the problem, let me have a quick look as I think I can fix it. If not, +1 to revert. Thanks On 8 February 2017 at 11:22, Galder Zamarre?o wrote: > We need builds to run too. We can't have commits that bring the build to a halt in such way that the build can't finish. > > Cheers, > -- > Galder Zamarre?o > Infinispan, Red Hat > >> On 8 Feb 2017, at 12:18, Sanne Grinovero wrote: >> >> Hi Galder, >> we need that upgrade. I didn't know of the OSGi problem, that seems >> trivial to fix.. next time just ask me? >> >> BTW I'd have noticed myself if only it was possible to run the >> Infinispan testsuite locally w/o it having so many failures.. >> >> Thanks, >> Sanne >> >> On 8 February 2017 at 10:25, Galder Zamarre?o wrote: >>> Hi all, >>> >>> I've sent a PR to revert ISPN-7426 since it hangs our OSGI tests endlessly [1]. >>> >>> Seems like Hibernate entitymanager in 5.2.x, which is used by our JPA store, is not very OSGI friendly [2]. >>> >>> In the mean time, I've stopped all PR builds since they're all hanged. >>> >>> Cheers, >>> >>> [1] https://github.com/infinispan/infinispan/pull/4836 >>> [2] https://issues.jboss.org/browse/ISPN-7426 >>> -- >>> Galder Zamarre?o >>> Infinispan, Red Hat >>> >>> >>> _______________________________________________ >>> 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 From sanne at infinispan.org Wed Feb 8 08:44:35 2017 From: sanne at infinispan.org (Sanne Grinovero) Date: Wed, 8 Feb 2017 13:44:35 +0000 Subject: [infinispan-dev] Reverting ISPN-7426 because of hangs In-Reply-To: References: <84040069-BF26-41AD-B988-9E162EFDA90C@redhat.com> Message-ID: I've sent a fix PR. Thanks for highlighting it! Sanne On 8 February 2017 at 11:32, Sanne Grinovero wrote: > I totally agree. This shouldn't have been merged in the first place, > but now that it's there and not that I know of the problem, let me > have a quick look as I think I can fix it. > > If not, +1 to revert. > > Thanks > > On 8 February 2017 at 11:22, Galder Zamarre?o wrote: >> We need builds to run too. We can't have commits that bring the build to a halt in such way that the build can't finish. >> >> Cheers, >> -- >> Galder Zamarre?o >> Infinispan, Red Hat >> >>> On 8 Feb 2017, at 12:18, Sanne Grinovero wrote: >>> >>> Hi Galder, >>> we need that upgrade. I didn't know of the OSGi problem, that seems >>> trivial to fix.. next time just ask me? >>> >>> BTW I'd have noticed myself if only it was possible to run the >>> Infinispan testsuite locally w/o it having so many failures.. >>> >>> Thanks, >>> Sanne >>> >>> On 8 February 2017 at 10:25, Galder Zamarre?o wrote: >>>> Hi all, >>>> >>>> I've sent a PR to revert ISPN-7426 since it hangs our OSGI tests endlessly [1]. >>>> >>>> Seems like Hibernate entitymanager in 5.2.x, which is used by our JPA store, is not very OSGI friendly [2]. >>>> >>>> In the mean time, I've stopped all PR builds since they're all hanged. >>>> >>>> Cheers, >>>> >>>> [1] https://github.com/infinispan/infinispan/pull/4836 >>>> [2] https://issues.jboss.org/browse/ISPN-7426 >>>> -- >>>> Galder Zamarre?o >>>> Infinispan, Red Hat >>>> >>>> >>>> _______________________________________________ >>>> 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 From ttarrant at redhat.com Fri Feb 10 15:29:38 2017 From: ttarrant at redhat.com (Tristan Tarrant) Date: Fri, 10 Feb 2017 21:29:38 +0100 Subject: [infinispan-dev] Infinispan 9.0.0.CR1 Message-ID: <27f7163b-f749-ffe9-f690-d26018817269@redhat.com> Hi everybody, Infinispan 9.0.0.CR1 has just been released. Read all about it in the announcement [1]. Tristan [1] http://blog.infinispan.org/2017/02/infinispan-900cr1.html -- Tristan Tarrant Infinispan Lead JBoss, a division of Red Hat From ttarrant at redhat.com Mon Feb 13 08:42:40 2017 From: ttarrant at redhat.com (Tristan Tarrant) Date: Mon, 13 Feb 2017 14:42:40 +0100 Subject: [infinispan-dev] My weekly report Message-ID: Hi guys, I won't be able to attend this week's IRC meeting, so here's my update: ISPN-7444 Configuration templates should not turn into concrete caches This was a side-effect of my work on ISPN-7066 (default cache inheritance) which was causing the Hot Rod server to start templates as is if they were concrete caches. ISPN-7442 Server configurations should use embedded defaults when possible Server always had defaults hard-coded in the configuration resource descriptors. I've changed it so that it uses whatever defaults the corresponding embedded configuration element uses ISPN-7445 Simplify default server configurations Removed a ton of useless "example" configuration attributes from the shipped configs, since most of them were duplicating "defaults" (wrong ones at that) and an adverse impact on performance ISPN-7446 Make the mode attribute on clustered caches optional and default to SYNC SYNC caches are what a user normally wants, so the "mode" attribute, which was previously mandatory, is now optional and it defaults to SYNC. This means that is all that is needed to get good defaults. I also did some CI surgery/cleanup, especially trying to help Galder and Sanne identify and solve the OSGi failures. I released 9.0.0.CR1 and I fixed the website news feed since Google deprecated the feeds API. This week I want to go through docs, examples, javadocs and the website to ensure that everything is in order for when we get to the final release. Tristan -- Tristan Tarrant Infinispan Lead JBoss, a division of Red Hat From dan.berindei at gmail.com Mon Feb 13 11:10:43 2017 From: dan.berindei at gmail.com (Dan Berindei) Date: Mon, 13 Feb 2017 18:10:43 +0200 Subject: [infinispan-dev] My weekly report In-Reply-To: References: Message-ID: Here is the log for the full meeting: http://transcripts.jboss.org/meeting/irc.freenode.org/infinispan/2017/infinispan.2017-02-13-15.03.log.html Cheers Dan On Mon, Feb 13, 2017 at 3:42 PM, Tristan Tarrant wrote: > Hi guys, > I won't be able to attend this week's IRC meeting, so here's my update: > > ISPN-7444 Configuration templates should not turn into concrete caches > This was a side-effect of my work on ISPN-7066 (default cache > inheritance) which was causing the Hot Rod server to start templates as > is if they were concrete caches. > > ISPN-7442 Server configurations should use embedded defaults when possible > Server always had defaults hard-coded in the configuration resource > descriptors. I've changed it so that it uses whatever defaults the > corresponding embedded configuration element uses > > ISPN-7445 Simplify default server configurations > Removed a ton of useless "example" configuration attributes from the > shipped configs, since most of them were duplicating "defaults" (wrong > ones at that) and an adverse impact on performance > > ISPN-7446 Make the mode attribute on clustered caches optional and > default to SYNC > SYNC caches are what a user normally wants, so the "mode" attribute, > which was previously mandatory, is now optional and it defaults to SYNC. > This means that is all that is > needed to get good defaults. > > I also did some CI surgery/cleanup, especially trying to help Galder and > Sanne identify and solve the OSGi failures. > > I released 9.0.0.CR1 and I fixed the website news feed since Google > deprecated the feeds API. > > This week I want to go through docs, examples, javadocs and the website > to ensure that everything is in order for when we get to the final release. > > Tristan > -- > Tristan Tarrant > Infinispan Lead > JBoss, a division of Red Hat > _______________________________________________ > infinispan-dev mailing list > infinispan-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev From dan.berindei at gmail.com Tue Feb 14 05:57:18 2017 From: dan.berindei at gmail.com (Dan Berindei) Date: Tue, 14 Feb 2017 12:57:18 +0200 Subject: [infinispan-dev] State transfer-related terms In-Reply-To: <095d786e-1fa7-761c-48f7-2653e6a67b65@redhat.com> References: <095d786e-1fa7-761c-48f7-2653e6a67b65@redhat.com> Message-ID: Oops, I thought I had replied to this... On Thu, Jan 19, 2017 at 6:11 PM, Radim Vansa wrote: > Hi, > > I've started (again) working on ISPN-5021 [1], and I'd like to get some > common agreement on few terms. So below I summarize my understanding (or > misunderstanding) of these, please state you opinion, thinking a bit > more generally. > > State transfer: whole process beginning with some ST-related event = > node being detected to crash/sending join or leave request, and ending > when this event is processed. When another event happens, the current ST > can either be finished or canceled and then *another* ST can begin. > State transfer is a cluster-wide process, though it cannot be started > and ended absolutely simultaneously. > > Rebalance: one phase of ST, when the data transfer occurs. > I see this exactly the opposite way: state transfer is the actual transfer of the data, and the rebalance is the whole process of adding a "pending" consistent hash, starting the state transfer, confirming the transfer of state, and finally replacing the "current" consistent hash with the pending one. > Data rehash: this is a bit painful point: we have DataRehashEvent where > the name suggest that it is related rather to rebalance, but currently > it fires when CacheTopology.getPendingCH() == null (that means when ST > is complete), and the event itself also looks more like it should be > fired at the end of state transfer. If we have something more to do > after the rebalance, I am not sure how useful is firing that just > because all data has been transferred (but for example before old data > has been wiped out). Should I add another StateTransferEvent event (and > appropriate listeners)? That would break the compatibility with tightly > related implementations... > The problem I was trying to solve with the "rebalance" name in 5.2 is that before we had two different concepts: 1. State transfer applied only to replicated caches, and it meant transferring state from the coordinator to a joiner. 2. Rehashing meant computing a new consistent hash based on the JGroups view, receiving state from old owners based on the consistent hash of the old JGroups view, and removing state no longer owned in the new consistent hash. The coordinator didn't have a special role. Rebalancing was meant to be an extension of rehashing to cover both distributed and replicated caches (now with replicated caches also being able to receive state from multiple members in parallel). Some of the components (StateTransferManager) and events (DataRehashEvent) kept their names, however. > WDYT? > > Radim > > [1] https://issues.jboss.org/browse/ISPN-5021 > > > -- > Radim Vansa > JBoss Performance Team > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev From galder at redhat.com Wed Feb 15 05:28:56 2017 From: galder at redhat.com (=?utf-8?Q?Galder_Zamarre=C3=B1o?=) Date: Wed, 15 Feb 2017 11:28:56 +0100 Subject: [infinispan-dev] GetKeyValueCommand NPE with CR1 in Hibernate 2LC - ISPN-7029 Message-ID: Hey Radim, Your changes in ISPN-7029 are causing issues with Hibernate 2LC. In particular [2]. Name.equals() always returns false, so it'll never be found in the context. So entry is null. Moreover, if EntryLookup.lookupEntry javadoc (and some implementations) can and do return null. Are you expecting that somehow that method will never return null? I'll create a JIRA to track all issues arising from Hibernate 2LC in a minute, but wanted to get your thoughts firts. Cheers, [1] https://issues.jboss.org/browse/ISPN-7029 [2] https://github.com/hibernate/hibernate-orm/blob/master/hibernate-infinispan/src/test/java/org/hibernate/test/cache/infinispan/CacheKeysFactoryTest.java#L58 -- Galder Zamarre?o Infinispan, Red Hat From galder at redhat.com Wed Feb 15 05:34:34 2017 From: galder at redhat.com (=?utf-8?Q?Galder_Zamarre=C3=B1o?=) Date: Wed, 15 Feb 2017 11:34:34 +0100 Subject: [infinispan-dev] GetKeyValueCommand NPE with CR1 in Hibernate 2LC - ISPN-7029 In-Reply-To: References: Message-ID: <8E5BB4B0-1672-4209-8413-79073C4A21B0@redhat.com> Umbrella JIRA: https://issues.jboss.org/browse/ISPN-7475 For this specific issue: https://issues.jboss.org/browse/ISPN-7476 Cheers, -- Galder Zamarre?o Infinispan, Red Hat > On 15 Feb 2017, at 11:28, Galder Zamarre?o wrote: > > Hey Radim, > > Your changes in ISPN-7029 are causing issues with Hibernate 2LC. > > In particular [2]. Name.equals() always returns false, so it'll never be found in the context. So entry is null. > > Moreover, if EntryLookup.lookupEntry javadoc (and some implementations) can and do return null. Are you expecting that somehow that method will never return null? > > I'll create a JIRA to track all issues arising from Hibernate 2LC in a minute, but wanted to get your thoughts firts. > > Cheers, > > [1] https://issues.jboss.org/browse/ISPN-7029 > [2] https://github.com/hibernate/hibernate-orm/blob/master/hibernate-infinispan/src/test/java/org/hibernate/test/cache/infinispan/CacheKeysFactoryTest.java#L58 > -- > Galder Zamarre?o > Infinispan, Red Hat > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev From rvansa at redhat.com Wed Feb 15 06:21:39 2017 From: rvansa at redhat.com (Radim Vansa) Date: Wed, 15 Feb 2017 12:21:39 +0100 Subject: [infinispan-dev] GetKeyValueCommand NPE with CR1 in Hibernate 2LC - ISPN-7029 In-Reply-To: References: Message-ID: On 02/15/2017 11:28 AM, Galder Zamarre?o wrote: > Hey Radim, > > Your changes in ISPN-7029 are causing issues with Hibernate 2LC. > > In particular [2]. Name.equals() always returns false, so it'll never be found in the context. So entry is null. That's obviously a bug in the 2LC testsuite, isn't it? Object used as @EmbeddedId needs to have the equals correctly defined. How else would you compare ids? I wonder how could that work in the past. > > Moreover, if EntryLookup.lookupEntry javadoc (and some implementations) can and do return null. Are you expecting that somehow that method will never return null? With ISPN-7029 in, the entry should be wrapped in the context after EntryWrappingInterceptor if the key is in readCH, otherwise it should be null. In case that xDistributionInterceptor finds out that it needs to work on that value despite not being able to read it (e.g. in case that it's in writeCH during unfinished rebalance), it should wrap NullCacheEntry.getInstance() using EntryFactory. wrapExternalEntry. More info about the logic is in o.i.c.EntryFactory javadoc [3]. Radim [3] https://github.com/infinispan/infinispan/blob/master/core/src/main/java/org/infinispan/container/EntryFactory.java > > I'll create a JIRA to track all issues arising from Hibernate 2LC in a minute, but wanted to get your thoughts firts. > > Cheers, > > [1] https://issues.jboss.org/browse/ISPN-7029 > [2] https://github.com/hibernate/hibernate-orm/blob/master/hibernate-infinispan/src/test/java/org/hibernate/test/cache/infinispan/CacheKeysFactoryTest.java#L58 > -- > Galder Zamarre?o > Infinispan, Red Hat > -- Radim Vansa JBoss Performance Team From slaskawi at redhat.com Wed Feb 15 08:21:10 2017 From: slaskawi at redhat.com (Sebastian Laskawiec) Date: Wed, 15 Feb 2017 13:21:10 +0000 Subject: [infinispan-dev] Spring Boot Starters 1.0.0.Beta1 release Message-ID: Hey! I'm happy to announce Spring Boot Starters 1.0.0.Beta1 release. You may find more information about the changelog here [1]. You may grab it while it's hot from [2] (as soon as the sync completes). Thanks, Sebastian [1] https://github.com/infinispan/infinispan-spring-boot/releases/tag/1.0.0.Beta1 [2] https://repository.jboss.org/nexus/content/repositories/public-jboss/org/infinispan/infinispan-spring-boot-starter/1.0.0.Beta1/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20170215/58db6ce4/attachment.html From galder at redhat.com Wed Feb 15 12:07:40 2017 From: galder at redhat.com (=?utf-8?Q?Galder_Zamarre=C3=B1o?=) Date: Wed, 15 Feb 2017 18:07:40 +0100 Subject: [infinispan-dev] GetKeyValueCommand NPE with CR1 in Hibernate 2LC - ISPN-7029 In-Reply-To: References: Message-ID: <6F4EF3D8-2509-4209-9CD1-A3D65F195681@redhat.com> -- Galder Zamarre?o Infinispan, Red Hat > On 15 Feb 2017, at 12:21, Radim Vansa wrote: > > On 02/15/2017 11:28 AM, Galder Zamarre?o wrote: >> Hey Radim, >> >> Your changes in ISPN-7029 are causing issues with Hibernate 2LC. >> >> In particular [2]. Name.equals() always returns false, so it'll never be found in the context. So entry is null. > > That's obviously a bug in the 2LC testsuite, isn't it? LOL, is it? You added the class and the javadoc clearly states that this entity defines equals incorrectly. You must have added it for a reason? https://github.com/hibernate/hibernate-orm/blob/master/hibernate-infinispan/src/test/java/org/hibernate/test/cache/infinispan/functional/entities/Name.java In any case, an object with an incorrect equals impl should not result in an NPE within Infinispan :| > Object used as @EmbeddedId needs to have the equals correctly defined. How else would you compare ids? I wonder how could that work in the past. ROFL... it's your baby so you tell me ;) > >> >> Moreover, if EntryLookup.lookupEntry javadoc (and some implementations) can and do return null. Are you expecting that somehow that method will never return null? > > With ISPN-7029 in, the entry should be wrapped in the context after EntryWrappingInterceptor if the key is in readCH, otherwise it should be null. In case that xDistributionInterceptor finds out that it needs to work on that value despite not being able to read it (e.g. in case that it's in writeCH during unfinished rebalance), it should wrap NullCacheEntry.getInstance() using EntryFactory. wrapExternalEntry. More info about the logic is in o.i.c.EntryFactory javadoc [3]. Not sure I understand what you're trying to imply above... so, is lookupEntry() allowed to return null or not? To be more specific, SingleKeyNonTxInvocationContext.lookupEntry() can return null, so GetKeyValueCommand should be able to handle it? Or should SingleKeyNonTxInvocationContext.lookupEntry return NullCacheEntry.getInstance instead of null? To provide more specifics, SingleKeyNonTxInvocationContext has NullCacheEntry.getInstance in cacheEntry variable when it's returning null. Should it maybe return NullCacheEntry.getInstance instead of null from lookupEntry() ? Cheers, > > Radim > > [3] https://github.com/infinispan/infinispan/blob/master/core/src/main/java/org/infinispan/container/EntryFactory.java > >> >> I'll create a JIRA to track all issues arising from Hibernate 2LC in a minute, but wanted to get your thoughts firts. >> >> Cheers, >> >> [1] https://issues.jboss.org/browse/ISPN-7029 >> [2] https://github.com/hibernate/hibernate-orm/blob/master/hibernate-infinispan/src/test/java/org/hibernate/test/cache/infinispan/CacheKeysFactoryTest.java#L58 >> -- >> Galder Zamarre?o >> Infinispan, Red Hat >> > > > -- > Radim Vansa > JBoss Performance Team From galder at redhat.com Wed Feb 15 12:19:05 2017 From: galder at redhat.com (=?utf-8?Q?Galder_Zamarre=C3=B1o?=) Date: Wed, 15 Feb 2017 18:19:05 +0100 Subject: [infinispan-dev] GetKeyValueCommand NPE with CR1 in Hibernate 2LC - ISPN-7029 In-Reply-To: <6F4EF3D8-2509-4209-9CD1-A3D65F195681@redhat.com> References: <6F4EF3D8-2509-4209-9CD1-A3D65F195681@redhat.com> Message-ID: <70AFE511-46BE-48D2-9736-5C80DADDCA73@redhat.com> p.s. I'm yet to verify whether such a misbehaving key produce such NPE in Infinispan... could be the case that this is all caused by my integration efforts in 2LC... Cheers, -- Galder Zamarre?o Infinispan, Red Hat > On 15 Feb 2017, at 18:07, Galder Zamarre?o wrote: > > > -- > Galder Zamarre?o > Infinispan, Red Hat > >> On 15 Feb 2017, at 12:21, Radim Vansa wrote: >> >> On 02/15/2017 11:28 AM, Galder Zamarre?o wrote: >>> Hey Radim, >>> >>> Your changes in ISPN-7029 are causing issues with Hibernate 2LC. >>> >>> In particular [2]. Name.equals() always returns false, so it'll never be found in the context. So entry is null. >> >> That's obviously a bug in the 2LC testsuite, isn't it? > > LOL, is it? You added the class and the javadoc clearly states that this entity defines equals incorrectly. You must have added it for a reason? > > https://github.com/hibernate/hibernate-orm/blob/master/hibernate-infinispan/src/test/java/org/hibernate/test/cache/infinispan/functional/entities/Name.java > > In any case, an object with an incorrect equals impl should not result in an NPE within Infinispan :| > >> Object used as @EmbeddedId needs to have the equals correctly defined. How else would you compare ids? I wonder how could that work in the past. > > ROFL... it's your baby so you tell me ;) > >> >>> >>> Moreover, if EntryLookup.lookupEntry javadoc (and some implementations) can and do return null. Are you expecting that somehow that method will never return null? >> >> With ISPN-7029 in, the entry should be wrapped in the context after EntryWrappingInterceptor if the key is in readCH, otherwise it should be null. In case that xDistributionInterceptor finds out that it needs to work on that value despite not being able to read it (e.g. in case that it's in writeCH during unfinished rebalance), it should wrap NullCacheEntry.getInstance() using EntryFactory. wrapExternalEntry. More info about the logic is in o.i.c.EntryFactory javadoc [3]. > > Not sure I understand what you're trying to imply above... so, is lookupEntry() allowed to return null or not? > > To be more specific, SingleKeyNonTxInvocationContext.lookupEntry() can return null, so GetKeyValueCommand should be able to handle it? Or should SingleKeyNonTxInvocationContext.lookupEntry return NullCacheEntry.getInstance instead of null? > > To provide more specifics, SingleKeyNonTxInvocationContext has NullCacheEntry.getInstance in cacheEntry variable when it's returning null. Should it maybe return NullCacheEntry.getInstance instead of null from lookupEntry() ? > > Cheers, > >> >> Radim >> >> [3] https://github.com/infinispan/infinispan/blob/master/core/src/main/java/org/infinispan/container/EntryFactory.java >> >>> >>> I'll create a JIRA to track all issues arising from Hibernate 2LC in a minute, but wanted to get your thoughts firts. >>> >>> Cheers, >>> >>> [1] https://issues.jboss.org/browse/ISPN-7029 >>> [2] https://github.com/hibernate/hibernate-orm/blob/master/hibernate-infinispan/src/test/java/org/hibernate/test/cache/infinispan/CacheKeysFactoryTest.java#L58 >>> -- >>> Galder Zamarre?o >>> Infinispan, Red Hat >>> >> >> >> -- >> Radim Vansa >> JBoss Performance Team > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev From rvansa at redhat.com Thu Feb 16 04:44:23 2017 From: rvansa at redhat.com (Radim Vansa) Date: Thu, 16 Feb 2017 10:44:23 +0100 Subject: [infinispan-dev] GetKeyValueCommand NPE with CR1 in Hibernate 2LC - ISPN-7029 In-Reply-To: <6F4EF3D8-2509-4209-9CD1-A3D65F195681@redhat.com> References: <6F4EF3D8-2509-4209-9CD1-A3D65F195681@redhat.com> Message-ID: On 02/15/2017 06:07 PM, Galder Zamarre?o wrote: > -- > Galder Zamarre?o > Infinispan, Red Hat > >> On 15 Feb 2017, at 12:21, Radim Vansa wrote: >> >> On 02/15/2017 11:28 AM, Galder Zamarre?o wrote: >>> Hey Radim, >>> >>> Your changes in ISPN-7029 are causing issues with Hibernate 2LC. >>> >>> In particular [2]. Name.equals() always returns false, so it'll never be found in the context. So entry is null. >> That's obviously a bug in the 2LC testsuite, isn't it? > LOL, is it? You added the class and the javadoc clearly states that this entity defines equals incorrectly. You must have added it for a reason? > > https://github.com/hibernate/hibernate-orm/blob/master/hibernate-infinispan/src/test/java/org/hibernate/test/cache/infinispan/functional/entities/Name.java > > In any case, an object with an incorrect equals impl should not result in an NPE within Infinispan :| > >> Object used as @EmbeddedId needs to have the equals correctly defined. How else would you compare ids? I wonder how could that work in the past. > ROFL... it's your baby so you tell me ;) Okay, okay - I haven't checked the javadoc, so I just assumed that it's an oversight :) > >>> Moreover, if EntryLookup.lookupEntry javadoc (and some implementations) can and do return null. Are you expecting that somehow that method will never return null? >> With ISPN-7029 in, the entry should be wrapped in the context after EntryWrappingInterceptor if the key is in readCH, otherwise it should be null. In case that xDistributionInterceptor finds out that it needs to work on that value despite not being able to read it (e.g. in case that it's in writeCH during unfinished rebalance), it should wrap NullCacheEntry.getInstance() using EntryFactory. wrapExternalEntry. More info about the logic is in o.i.c.EntryFactory javadoc [3]. > Not sure I understand what you're trying to imply above... so, is lookupEntry() allowed to return null or not? It is allowed to return null, but: 1. If the node is an owner according to readCH, the entry must be wrapped into context in EWI (possibly as NullCacheEntry). 2. The code can reach the GKVC.perform() iff this node is an owner of given key. The problem here is that I've assumed that if the entry was wrapped, it can be fetched. With incorrectly defined equals, as we see here, this does not hold. So we can a) check if the entry is null and throw more explanatory exception - more code in perform() b) do the lookup after wrapping and throw there - unnecessary map lookup for such annoying problem c) ostrich approach I think that b) in assert could do, otherwise I'd suggest c) Radim > > To be more specific, SingleKeyNonTxInvocationContext.lookupEntry() can return null, so GetKeyValueCommand should be able to handle it? Or should SingleKeyNonTxInvocationContext.lookupEntry return NullCacheEntry.getInstance instead of null? > > To provide more specifics, SingleKeyNonTxInvocationContext has NullCacheEntry.getInstance in cacheEntry variable when it's returning null. Should it maybe return NullCacheEntry.getInstance instead of null from lookupEntry() ? > > Cheers, > >> Radim >> >> [3] https://github.com/infinispan/infinispan/blob/master/core/src/main/java/org/infinispan/container/EntryFactory.java >> >>> I'll create a JIRA to track all issues arising from Hibernate 2LC in a minute, but wanted to get your thoughts firts. >>> >>> Cheers, >>> >>> [1] https://issues.jboss.org/browse/ISPN-7029 >>> [2] https://github.com/hibernate/hibernate-orm/blob/master/hibernate-infinispan/src/test/java/org/hibernate/test/cache/infinispan/CacheKeysFactoryTest.java#L58 >>> -- >>> Galder Zamarre?o >>> Infinispan, Red Hat >>> >> >> -- >> Radim Vansa >> JBoss Performance Team -- Radim Vansa JBoss Performance Team From galder at redhat.com Thu Feb 16 05:58:05 2017 From: galder at redhat.com (=?utf-8?Q?Galder_Zamarre=C3=B1o?=) Date: Thu, 16 Feb 2017 11:58:05 +0100 Subject: [infinispan-dev] Backwards compatibility issues with Infinispan 9.x and Hibernate 2LC Message-ID: <3C1761C3-87FF-4616-BA59-909471EF72FD@redhat.com> Hi all, As I've mentioned, I'm working on trying to integrate Hibernate 2LC (5.x branch at the moment) with Infinispan 9. To start with, I tried to see if I could just run Hibernate 2LC 5.x, compiled with Infinispan 8, with an Infinispan 9 runtime. The first problem here was to do with changes to PrioritizedMethodMetadata [1]. However, that above is the least of our problems... once I tried to compile with Infinispan 9, there are a lot of compilation errors. Here's a list of what I've found out so far, based on the work in [2] which includes compilation errors and runtime issues I've discovered: 1. Plenty of interceptors have been moved from org.infinispan.interceptors.base and org.infinispan.interceptors packages to org.infinispan.interceptors.impl package. 2. ModuleCommandFactory.fromStream now passes a cache name in ByteString instead of String. 3. DataWriteCommand.setMetadata() method is gone. The reason for this is that FlagAffectedCommand does no longer extend MetadataAwareCommand. 4. Interceptors cannot invoke invokeNextInterceptor() any more in parent, the method has been renamed to invokeNext() (in different class, AsyncInterceptor) 5. A lot of interceptors now take flags as long instead of Set which results in compilation error. 6. BaseRpcInterceptor subclasses are now force abstract protected method getLog() to be implemented, again a compilation error. 7. CallInterceptor no longer contains visit... methods, so all interceptors extending it need to extend CommandInterceptor and be placed just before CallInterceptor. 7.1. As a result of that, interceptor positioning calls need to be changed. 8. AdvancedCache.filterEntries() is gone, so need to find an alternative way to do the same. 9. WriteCommand.getAffectedKeys() returns Collection instead of Set now. 10. org.infinispan.filter.NullValueConverter is gone. I removed that as part of marshalling changes since it was not used anywhere within Infinispan repo, but Hibernate 2LC actually uses it. 11. BeginInvalidationCommand and EndInvalidationCommand write directly the lockOwner via `output.writeObject(lockOwner)`, but this causes problem when the lockOwner is a CommandInvocationId since there's no externalizer for it any more. The reason for not having an externalizer is that CommandInvocationId is written via static CommandInvocationId.writeTo() calls. 12. org.infinispan.commands.module.ExtendedModuleCommandFactory is gone. 13. ReplicableCommand.setParameters() method is gone. 14. BaseRpcCommand constructor takes a ByteString instead of String. 15. ReplicableCommand implementations need to implement writeTo() and readFrom() methods. 16. (test) BlockingInterceptor no longer can be added via AdvancedCache.addInterceptor() call because it does not extend CommandInterceptor any more. 17. (test) org.infinispan.util.concurrent.ConcurrentHashSet has been moved. 18. (test) TestingEntityCacheKey must be made extend ExternalPojo so that it can be externally marshalled. 19. (test) 2lc-test-tcp.xml contains attributes that are no longer found by JGroups 4.x and throws errors. The question here is whether we should work towards making Infinispan 9 backwards compatible with Infinispan 8 as far as Hibernate 2LC integration is concerned. In theory, Infinispan 9 should be integrated with Hibernate 6.x onwards, but as always, Wildfly might have different opinions... @Paul? If we need to do something, the time to do it is now, before 9.Final. Cheers, p.s. A lot of tests still failing, so the work in [2] is nowhere near finished. [1] https://gist.github.com/galderz/e26ea9d4838a965500906a6df87e064a [2] https://github.com/galderz/hibernate-orm/commit/5e36a021db4eaad75d835d321282eee6c62cc7c6 -- Galder Zamarre?o Infinispan, Red Hat From sanne at hibernate.org Thu Feb 16 06:28:37 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Thu, 16 Feb 2017 11:28:37 +0000 Subject: [infinispan-dev] Backwards compatibility issues with Infinispan 9.x and Hibernate 2LC In-Reply-To: <3C1761C3-87FF-4616-BA59-909471EF72FD@redhat.com> References: <3C1761C3-87FF-4616-BA59-909471EF72FD@redhat.com> Message-ID: Have fun with the rewriting! ;) More seriously, it might be worth to have a second module for Hibernate ORM 5.x to address Infinispan 9? At least in depth testing, stressing and performance aspect won't be left to the last minute integration step. Also, would it be worth to move such code to Infinispan? In such cases neither repository is ideal, but I'd tend to prefer to integrate with the one which has the more stable and well defined integration point. Historically that has been Hibernate, so hosting this code closer to Infinispan and then merely integrate with Hibernate would have been useful. Alternatively, let's see if we can embrace JCache all-in. The architecture I had discussed with Alex Snaps for the Hibernate /JCache integration would allow for "vendor specific extensions" to bypass the spec on some specific points as needed. On 16 Feb 2017 11:00, "Galder Zamarre?o" wrote: > Hi all, > > As I've mentioned, I'm working on trying to integrate Hibernate 2LC (5.x > branch at the moment) with Infinispan 9. > > To start with, I tried to see if I could just run Hibernate 2LC 5.x, > compiled with Infinispan 8, with an Infinispan 9 runtime. The first problem > here was to do with changes to PrioritizedMethodMetadata [1]. > > However, that above is the least of our problems... once I tried to > compile with Infinispan 9, there are a lot of compilation errors. > > Here's a list of what I've found out so far, based on the work in [2] > which includes compilation errors and runtime issues I've discovered: > > 1. Plenty of interceptors have been moved from org.infinispan.interceptors.base > and org.infinispan.interceptors packages to org.infinispan.interceptors.impl > package. > > 2. ModuleCommandFactory.fromStream now passes a cache name in ByteString > instead of String. > > 3. DataWriteCommand.setMetadata() method is gone. The reason for this is > that FlagAffectedCommand does no longer extend MetadataAwareCommand. > > 4. Interceptors cannot invoke invokeNextInterceptor() any more in parent, > the method has been renamed to invokeNext() (in different class, > AsyncInterceptor) > > 5. A lot of interceptors now take flags as long instead of Set which > results in compilation error. > > 6. BaseRpcInterceptor subclasses are now force abstract protected method > getLog() to be implemented, again a compilation error. > > 7. CallInterceptor no longer contains visit... methods, so all > interceptors extending it need to extend CommandInterceptor and be placed > just before CallInterceptor. > > 7.1. As a result of that, interceptor positioning calls need to be changed. > > 8. AdvancedCache.filterEntries() is gone, so need to find an alternative > way to do the same. > > 9. WriteCommand.getAffectedKeys() returns Collection instead of Set now. > > 10. org.infinispan.filter.NullValueConverter is gone. I removed that as > part of marshalling changes since it was not used anywhere within > Infinispan repo, but Hibernate 2LC actually uses it. > > 11. BeginInvalidationCommand and EndInvalidationCommand write directly the > lockOwner via `output.writeObject(lockOwner)`, but this causes problem > when the lockOwner is a CommandInvocationId since there's no externalizer > for it any more. The reason for not having an externalizer is that > CommandInvocationId is written via static CommandInvocationId.writeTo() > calls. > > 12. org.infinispan.commands.module.ExtendedModuleCommandFactory is gone. > > 13. ReplicableCommand.setParameters() method is gone. > > 14. BaseRpcCommand constructor takes a ByteString instead of String. > > 15. ReplicableCommand implementations need to implement writeTo() and > readFrom() methods. > > 16. (test) BlockingInterceptor no longer can be added via > AdvancedCache.addInterceptor() call because it does not extend > CommandInterceptor any more. > > 17. (test) org.infinispan.util.concurrent.ConcurrentHashSet has been > moved. > > 18. (test) TestingEntityCacheKey must be made extend ExternalPojo so that > it can be externally marshalled. > > 19. (test) 2lc-test-tcp.xml contains attributes that are no longer found > by JGroups 4.x and throws errors. > > The question here is whether we should work towards making Infinispan 9 > backwards compatible with Infinispan 8 as far as Hibernate 2LC integration > is concerned. > > In theory, Infinispan 9 should be integrated with Hibernate 6.x onwards, > but as always, Wildfly might have different opinions... @Paul? > > If we need to do something, the time to do it is now, before 9.Final. > > Cheers, > > p.s. A lot of tests still failing, so the work in [2] is nowhere near > finished. > > [1] https://gist.github.com/galderz/e26ea9d4838a965500906a6df87e064a > [2] https://github.com/galderz/hibernate-orm/commit/ > 5e36a021db4eaad75d835d321282eee6c62cc7c6 > -- > Galder Zamarre?o > Infinispan, Red Hat > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20170216/bb13cc6b/attachment.html From rvansa at redhat.com Thu Feb 16 08:51:27 2017 From: rvansa at redhat.com (Radim Vansa) Date: Thu, 16 Feb 2017 14:51:27 +0100 Subject: [infinispan-dev] GetKeyValueCommand NPE with CR1 in Hibernate 2LC - ISPN-7029 In-Reply-To: References: <6F4EF3D8-2509-4209-9CD1-A3D65F195681@redhat.com> Message-ID: <1945232e-3fa5-deba-5b63-b309a8e80b76@redhat.com> On 02/16/2017 10:44 AM, Radim Vansa wrote: > On 02/15/2017 06:07 PM, Galder Zamarre?o wrote: >> -- >> Galder Zamarre?o >> Infinispan, Red Hat >> >>> On 15 Feb 2017, at 12:21, Radim Vansa wrote: >>> >>> On 02/15/2017 11:28 AM, Galder Zamarre?o wrote: >>>> Hey Radim, >>>> >>>> Your changes in ISPN-7029 are causing issues with Hibernate 2LC. >>>> >>>> In particular [2]. Name.equals() always returns false, so it'll never be found in the context. So entry is null. >>> That's obviously a bug in the 2LC testsuite, isn't it? >> LOL, is it? You added the class and the javadoc clearly states that this entity defines equals incorrectly. You must have added it for a reason? >> >> https://github.com/hibernate/hibernate-orm/blob/master/hibernate-infinispan/src/test/java/org/hibernate/test/cache/infinispan/functional/entities/Name.java >> >> In any case, an object with an incorrect equals impl should not result in an NPE within Infinispan :| >> >>> Object used as @EmbeddedId needs to have the equals correctly defined. How else would you compare ids? I wonder how could that work in the past. >> ROFL... it's your baby so you tell me ;) > Okay, okay - I haven't checked the javadoc, so I just assumed that it's > an oversight :) The reason it worked before was that both DC and EntryLookup used keyEquivalence for all the comparisons, and 2LC was providing TypeEquivalence there. In 9.0 (master) the keyEquivalence was dropped. For some reason DataContainerConfigurationBuilder.keyEquivalence is not marked as deprecated, I'll file a PR for that. R. > >>>> Moreover, if EntryLookup.lookupEntry javadoc (and some implementations) can and do return null. Are you expecting that somehow that method will never return null? >>> With ISPN-7029 in, the entry should be wrapped in the context after EntryWrappingInterceptor if the key is in readCH, otherwise it should be null. In case that xDistributionInterceptor finds out that it needs to work on that value despite not being able to read it (e.g. in case that it's in writeCH during unfinished rebalance), it should wrap NullCacheEntry.getInstance() using EntryFactory. wrapExternalEntry. More info about the logic is in o.i.c.EntryFactory javadoc [3]. >> Not sure I understand what you're trying to imply above... so, is lookupEntry() allowed to return null or not? > It is allowed to return null, but: > > 1. If the node is an owner according to readCH, the entry must be > wrapped into context in EWI (possibly as NullCacheEntry). > 2. The code can reach the GKVC.perform() iff this node is an owner of > given key. > > The problem here is that I've assumed that if the entry was wrapped, it > can be fetched. With incorrectly defined equals, as we see here, this > does not hold. So we can > > a) check if the entry is null and throw more explanatory exception - > more code in perform() > b) do the lookup after wrapping and throw there - unnecessary map lookup > for such annoying problem > c) ostrich approach > > I think that b) in assert could do, otherwise I'd suggest c) > > Radim > >> To be more specific, SingleKeyNonTxInvocationContext.lookupEntry() can return null, so GetKeyValueCommand should be able to handle it? Or should SingleKeyNonTxInvocationContext.lookupEntry return NullCacheEntry.getInstance instead of null? >> >> To provide more specifics, SingleKeyNonTxInvocationContext has NullCacheEntry.getInstance in cacheEntry variable when it's returning null. Should it maybe return NullCacheEntry.getInstance instead of null from lookupEntry() ? >> >> Cheers, >> >>> Radim >>> >>> [3] https://github.com/infinispan/infinispan/blob/master/core/src/main/java/org/infinispan/container/EntryFactory.java >>> >>>> I'll create a JIRA to track all issues arising from Hibernate 2LC in a minute, but wanted to get your thoughts firts. >>>> >>>> Cheers, >>>> >>>> [1] https://issues.jboss.org/browse/ISPN-7029 >>>> [2] https://github.com/hibernate/hibernate-orm/blob/master/hibernate-infinispan/src/test/java/org/hibernate/test/cache/infinispan/CacheKeysFactoryTest.java#L58 >>>> -- >>>> Galder Zamarre?o >>>> Infinispan, Red Hat >>>> >>> -- >>> Radim Vansa >>> JBoss Performance Team > -- Radim Vansa JBoss Performance Team From mudokonman at gmail.com Thu Feb 16 08:53:56 2017 From: mudokonman at gmail.com (William Burns) Date: Thu, 16 Feb 2017 13:53:56 +0000 Subject: [infinispan-dev] GetKeyValueCommand NPE with CR1 in Hibernate 2LC - ISPN-7029 In-Reply-To: <1945232e-3fa5-deba-5b63-b309a8e80b76@redhat.com> References: <6F4EF3D8-2509-4209-9CD1-A3D65F195681@redhat.com> <1945232e-3fa5-deba-5b63-b309a8e80b76@redhat.com> Message-ID: On Thu, Feb 16, 2017 at 8:51 AM Radim Vansa wrote: > On 02/16/2017 10:44 AM, Radim Vansa wrote: > > On 02/15/2017 06:07 PM, Galder Zamarre?o wrote: > >> -- > >> Galder Zamarre?o > >> Infinispan, Red Hat > >> > >>> On 15 Feb 2017, at 12:21, Radim Vansa wrote: > >>> > >>> On 02/15/2017 11:28 AM, Galder Zamarre?o wrote: > >>>> Hey Radim, > >>>> > >>>> Your changes in ISPN-7029 are causing issues with Hibernate 2LC. > >>>> > >>>> In particular [2]. Name.equals() always returns false, so it'll never > be found in the context. So entry is null. > >>> That's obviously a bug in the 2LC testsuite, isn't it? > >> LOL, is it? You added the class and the javadoc clearly states that > this entity defines equals incorrectly. You must have added it for a reason? > >> > >> > https://github.com/hibernate/hibernate-orm/blob/master/hibernate-infinispan/src/test/java/org/hibernate/test/cache/infinispan/functional/entities/Name.java > >> > >> In any case, an object with an incorrect equals impl should not result > in an NPE within Infinispan :| > >> > >>> Object used as @EmbeddedId needs to have the equals correctly defined. > How else would you compare ids? I wonder how could that work in the past. > >> ROFL... it's your baby so you tell me ;) > > Okay, okay - I haven't checked the javadoc, so I just assumed that it's > > an oversight :) > > The reason it worked before was that both DC and EntryLookup used > keyEquivalence for all the comparisons, and 2LC was providing > TypeEquivalence there. In 9.0 (master) the keyEquivalence was dropped. > For some reason DataContainerConfigurationBuilder.keyEquivalence is not > marked as deprecated, I'll file a PR for that. > The entire DataContainerConfiguration and Builder classes are deprecated as well as Equivalence :) > > R. > > > > >>>> Moreover, if EntryLookup.lookupEntry javadoc (and some > implementations) can and do return null. Are you expecting that somehow > that method will never return null? > >>> With ISPN-7029 in, the entry should be wrapped in the context after > EntryWrappingInterceptor if the key is in readCH, otherwise it should be > null. In case that xDistributionInterceptor finds out that it needs to work > on that value despite not being able to read it (e.g. in case that it's in > writeCH during unfinished rebalance), it should wrap > NullCacheEntry.getInstance() using EntryFactory. wrapExternalEntry. More > info about the logic is in o.i.c.EntryFactory javadoc [3]. > >> Not sure I understand what you're trying to imply above... so, is > lookupEntry() allowed to return null or not? > > It is allowed to return null, but: > > > > 1. If the node is an owner according to readCH, the entry must be > > wrapped into context in EWI (possibly as NullCacheEntry). > > 2. The code can reach the GKVC.perform() iff this node is an owner of > > given key. > > > > The problem here is that I've assumed that if the entry was wrapped, it > > can be fetched. With incorrectly defined equals, as we see here, this > > does not hold. So we can > > > > a) check if the entry is null and throw more explanatory exception - > > more code in perform() > > b) do the lookup after wrapping and throw there - unnecessary map lookup > > for such annoying problem > > c) ostrich approach > > > > I think that b) in assert could do, otherwise I'd suggest c) > > > > Radim > > > >> To be more specific, SingleKeyNonTxInvocationContext.lookupEntry() can > return null, so GetKeyValueCommand should be able to handle it? Or should > SingleKeyNonTxInvocationContext.lookupEntry return > NullCacheEntry.getInstance instead of null? > >> > >> To provide more specifics, SingleKeyNonTxInvocationContext has > NullCacheEntry.getInstance in cacheEntry variable when it's returning null. > Should it maybe return NullCacheEntry.getInstance instead of null from > lookupEntry() ? > >> > >> Cheers, > >> > >>> Radim > >>> > >>> [3] > https://github.com/infinispan/infinispan/blob/master/core/src/main/java/org/infinispan/container/EntryFactory.java > >>> > >>>> I'll create a JIRA to track all issues arising from Hibernate 2LC in > a minute, but wanted to get your thoughts firts. > >>>> > >>>> Cheers, > >>>> > >>>> [1] https://issues.jboss.org/browse/ISPN-7029 > >>>> [2] > https://github.com/hibernate/hibernate-orm/blob/master/hibernate-infinispan/src/test/java/org/hibernate/test/cache/infinispan/CacheKeysFactoryTest.java#L58 > >>>> -- > >>>> Galder Zamarre?o > >>>> Infinispan, Red Hat > >>>> > >>> -- > >>> Radim Vansa > >>> JBoss Performance Team > > > > > -- > Radim Vansa > JBoss Performance Team > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20170216/deea6380/attachment.html From rvansa at redhat.com Thu Feb 16 09:43:01 2017 From: rvansa at redhat.com (Radim Vansa) Date: Thu, 16 Feb 2017 15:43:01 +0100 Subject: [infinispan-dev] GetKeyValueCommand NPE with CR1 in Hibernate 2LC - ISPN-7029 In-Reply-To: References: <6F4EF3D8-2509-4209-9CD1-A3D65F195681@redhat.com> <1945232e-3fa5-deba-5b63-b309a8e80b76@redhat.com> Message-ID: <6933643a-837a-efd2-d4cd-d760dd5dbab5@redhat.com> On 02/16/2017 02:53 PM, William Burns wrote: > > > On Thu, Feb 16, 2017 at 8:51 AM Radim Vansa > wrote: > > On 02/16/2017 10:44 AM, Radim Vansa wrote: > > On 02/15/2017 06:07 PM, Galder Zamarre?o wrote: > >> -- > >> Galder Zamarre?o > >> Infinispan, Red Hat > >> > >>> On 15 Feb 2017, at 12:21, Radim Vansa > wrote: > >>> > >>> On 02/15/2017 11:28 AM, Galder Zamarre?o wrote: > >>>> Hey Radim, > >>>> > >>>> Your changes in ISPN-7029 are causing issues with Hibernate 2LC. > >>>> > >>>> In particular [2]. Name.equals() always returns false, so > it'll never be found in the context. So entry is null. > >>> That's obviously a bug in the 2LC testsuite, isn't it? > >> LOL, is it? You added the class and the javadoc clearly states > that this entity defines equals incorrectly. You must have added > it for a reason? > >> > >> > https://github.com/hibernate/hibernate-orm/blob/master/hibernate-infinispan/src/test/java/org/hibernate/test/cache/infinispan/functional/entities/Name.java > >> > >> In any case, an object with an incorrect equals impl should not > result in an NPE within Infinispan :| > >> > >>> Object used as @EmbeddedId needs to have the equals correctly > defined. How else would you compare ids? I wonder how could that > work in the past. > >> ROFL... it's your baby so you tell me ;) > > Okay, okay - I haven't checked the javadoc, so I just assumed > that it's > > an oversight :) > > The reason it worked before was that both DC and EntryLookup used > keyEquivalence for all the comparisons, and 2LC was providing > TypeEquivalence there. In 9.0 (master) the keyEquivalence was dropped. > For some reason DataContainerConfigurationBuilder.keyEquivalence > is not > marked as deprecated, I'll file a PR for that. > > > The entire DataContainerConfiguration and Builder classes are > deprecated as well as Equivalence :) It is, but with @Deprecated (with capital D) in javadoc it did not show up properly in IntelliJ. I've fixed those [1]. IMO a warning message/exception when an user tries to set up equivalence other than AnyEquivalence would be even better, silently ignoring that could lead to obscure problems (when the equivalence definition in the object and equivalence function differs only in minority of cases). R. [1] https://github.com/infinispan/infinispan/pull/4865 > > R. > > > > >>>> Moreover, if EntryLookup.lookupEntry javadoc (and some > implementations) can and do return null. Are you expecting that > somehow that method will never return null? > >>> With ISPN-7029 in, the entry should be wrapped in the context > after EntryWrappingInterceptor if the key is in readCH, otherwise > it should be null. In case that xDistributionInterceptor finds out > that it needs to work on that value despite not being able to read > it (e.g. in case that it's in writeCH during unfinished > rebalance), it should wrap NullCacheEntry.getInstance() using > EntryFactory. wrapExternalEntry. More info about the logic is in > o.i.c.EntryFactory javadoc [3]. > >> Not sure I understand what you're trying to imply above... so, > is lookupEntry() allowed to return null or not? > > It is allowed to return null, but: > > > > 1. If the node is an owner according to readCH, the entry must be > > wrapped into context in EWI (possibly as NullCacheEntry). > > 2. The code can reach the GKVC.perform() iff this node is an > owner of > > given key. > > > > The problem here is that I've assumed that if the entry was > wrapped, it > > can be fetched. With incorrectly defined equals, as we see here, > this > > does not hold. So we can > > > > a) check if the entry is null and throw more explanatory exception - > > more code in perform() > > b) do the lookup after wrapping and throw there - unnecessary > map lookup > > for such annoying problem > > c) ostrich approach > > > > I think that b) in assert could do, otherwise I'd suggest c) > > > > Radim > > > >> To be more specific, > SingleKeyNonTxInvocationContext.lookupEntry() can return null, so > GetKeyValueCommand should be able to handle it? Or should > SingleKeyNonTxInvocationContext.lookupEntry return > NullCacheEntry.getInstance instead of null? > >> > >> To provide more specifics, SingleKeyNonTxInvocationContext has > NullCacheEntry.getInstance in cacheEntry variable when it's > returning null. Should it maybe return NullCacheEntry.getInstance > instead of null from lookupEntry() ? > >> > >> Cheers, > >> > >>> Radim > >>> > >>> [3] > https://github.com/infinispan/infinispan/blob/master/core/src/main/java/org/infinispan/container/EntryFactory.java > >>> > >>>> I'll create a JIRA to track all issues arising from Hibernate > 2LC in a minute, but wanted to get your thoughts firts. > >>>> > >>>> Cheers, > >>>> > >>>> [1] https://issues.jboss.org/browse/ISPN-7029 > >>>> [2] > https://github.com/hibernate/hibernate-orm/blob/master/hibernate-infinispan/src/test/java/org/hibernate/test/cache/infinispan/CacheKeysFactoryTest.java#L58 > >>>> -- > >>>> Galder Zamarre?o > >>>> Infinispan, Red Hat > >>>> > >>> -- > >>> Radim Vansa > > >>> JBoss Performance Team > > > > > -- > Radim Vansa > > JBoss Performance Team > > _______________________________________________ > 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 -- Radim Vansa JBoss Performance Team From galder at redhat.com Thu Feb 16 11:41:20 2017 From: galder at redhat.com (=?utf-8?Q?Galder_Zamarre=C3=B1o?=) Date: Thu, 16 Feb 2017 17:41:20 +0100 Subject: [infinispan-dev] Backwards compatibility issues with Infinispan 9.x and Hibernate 2LC In-Reply-To: References: <3C1761C3-87FF-4616-BA59-909471EF72FD@redhat.com> Message-ID: -- Galder Zamarre?o Infinispan, Red Hat > On 16 Feb 2017, at 12:28, Sanne Grinovero wrote: > > Have fun with the rewriting! > ;) Thx ;) > > More seriously, it might be worth to have a second module for Hibernate ORM 5.x to address Infinispan 9? > At least in depth testing, stressing and performance aspect won't be left to the last minute integration step. Hmmmmm, and what do we do with Infinispan 10? Have yet another module? Not sure that model scales well... > > Also, would it be worth to move such code to Infinispan? In such cases neither repository is ideal, but I'd tend to prefer to integrate with the one which has the more stable and well defined integration point. Moving the code to Infinispan might be a good idea. Given how complex the integration has become (for good reasons: ease of use (no tx, all strategies) and perf), this might be a good idea. The benefit here is that if we'd update Infinispan within Wildfly, the 2LC provider shipped would be updated. The major Hibernate version shipped in Wildfly is normally tied based on EE requirements, whereas Infinispan versions can more freely be upgraded, so I can't see the opposite problem happen that easily: the potential problem of having Infinispan 9.0.x having to work with both Hibernate 5 and 6... An important thing would be to make sure we don't put barriers that makes consumption by user harder. > Historically that has been Hibernate, so hosting this code closer to Infinispan and then merely integrate with Hibernate would have been useful. > > Alternatively, let's see if we can embrace JCache all-in. The architecture I had discussed with Alex Snaps for the Hibernate /JCache integration would allow for "vendor specific extensions" to bypass the spec on some specific points as needed. Not sure if I've seen the details of such architecture, but given JCache's stable API, maybe Hibernate should maybe just ship this provider, and any other providers be provided by the implementations themselves (as opposed to be included in Hibernate) Cheers, > > > On 16 Feb 2017 11:00, "Galder Zamarre?o" wrote: > Hi all, > > As I've mentioned, I'm working on trying to integrate Hibernate 2LC (5.x branch at the moment) with Infinispan 9. > > To start with, I tried to see if I could just run Hibernate 2LC 5.x, compiled with Infinispan 8, with an Infinispan 9 runtime. The first problem here was to do with changes to PrioritizedMethodMetadata [1]. > > However, that above is the least of our problems... once I tried to compile with Infinispan 9, there are a lot of compilation errors. > > Here's a list of what I've found out so far, based on the work in [2] which includes compilation errors and runtime issues I've discovered: > > 1. Plenty of interceptors have been moved from org.infinispan.interceptors.base and org.infinispan.interceptors packages to org.infinispan.interceptors.impl package. > > 2. ModuleCommandFactory.fromStream now passes a cache name in ByteString instead of String. > > 3. DataWriteCommand.setMetadata() method is gone. The reason for this is that FlagAffectedCommand does no longer extend MetadataAwareCommand. > > 4. Interceptors cannot invoke invokeNextInterceptor() any more in parent, the method has been renamed to invokeNext() (in different class, AsyncInterceptor) > > 5. A lot of interceptors now take flags as long instead of Set which results in compilation error. > > 6. BaseRpcInterceptor subclasses are now force abstract protected method getLog() to be implemented, again a compilation error. > > 7. CallInterceptor no longer contains visit... methods, so all interceptors extending it need to extend CommandInterceptor and be placed just before CallInterceptor. > > 7.1. As a result of that, interceptor positioning calls need to be changed. > > 8. AdvancedCache.filterEntries() is gone, so need to find an alternative way to do the same. > > 9. WriteCommand.getAffectedKeys() returns Collection instead of Set now. > > 10. org.infinispan.filter.NullValueConverter is gone. I removed that as part of marshalling changes since it was not used anywhere within Infinispan repo, but Hibernate 2LC actually uses it. > > 11. BeginInvalidationCommand and EndInvalidationCommand write directly the lockOwner via `output.writeObject(lockOwner)`, but this causes problem when the lockOwner is a CommandInvocationId since there's no externalizer for it any more. The reason for not having an externalizer is that CommandInvocationId is written via static CommandInvocationId.writeTo() calls. > > 12. org.infinispan.commands.module.ExtendedModuleCommandFactory is gone. > > 13. ReplicableCommand.setParameters() method is gone. > > 14. BaseRpcCommand constructor takes a ByteString instead of String. > > 15. ReplicableCommand implementations need to implement writeTo() and readFrom() methods. > > 16. (test) BlockingInterceptor no longer can be added via AdvancedCache.addInterceptor() call because it does not extend CommandInterceptor any more. > > 17. (test) org.infinispan.util.concurrent.ConcurrentHashSet has been moved. > > 18. (test) TestingEntityCacheKey must be made extend ExternalPojo so that it can be externally marshalled. > > 19. (test) 2lc-test-tcp.xml contains attributes that are no longer found by JGroups 4.x and throws errors. > > The question here is whether we should work towards making Infinispan 9 backwards compatible with Infinispan 8 as far as Hibernate 2LC integration is concerned. > > In theory, Infinispan 9 should be integrated with Hibernate 6.x onwards, but as always, Wildfly might have different opinions... @Paul? > > If we need to do something, the time to do it is now, before 9.Final. > > Cheers, > > p.s. A lot of tests still failing, so the work in [2] is nowhere near finished. > > [1] https://gist.github.com/galderz/e26ea9d4838a965500906a6df87e064a > [2] https://github.com/galderz/hibernate-orm/commit/5e36a021db4eaad75d835d321282eee6c62cc7c6 > -- > Galder Zamarre?o > Infinispan, Red Hat > > > _______________________________________________ > 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 From rvansa at redhat.com Fri Feb 17 03:28:38 2017 From: rvansa at redhat.com (Radim Vansa) Date: Fri, 17 Feb 2017 09:28:38 +0100 Subject: [infinispan-dev] Backwards compatibility issues with Infinispan 9.x and Hibernate 2LC In-Reply-To: References: <3C1761C3-87FF-4616-BA59-909471EF72FD@redhat.com> Message-ID: On 02/16/2017 05:41 PM, Galder Zamarre?o wrote: > -- > Galder Zamarre?o > Infinispan, Red Hat > >> On 16 Feb 2017, at 12:28, Sanne Grinovero wrote: >> >> Have fun with the rewriting! >> ;) > Thx ;) > >> More seriously, it might be worth to have a second module for Hibernate ORM 5.x to address Infinispan 9? >> At least in depth testing, stressing and performance aspect won't be left to the last minute integration step. > Hmmmmm, and what do we do with Infinispan 10? Have yet another module? Not sure that model scales well... 2LC uses Infinispan very extensively, and we can't keep backwards compatibility at that scale forever. Especially when this involves moving to async interceptor stack. > >> Also, would it be worth to move such code to Infinispan? In such cases neither repository is ideal, but I'd tend to prefer to integrate with the one which has the more stable and well defined integration point. > Moving the code to Infinispan might be a good idea. Given how complex the integration has become (for good reasons: ease of use (no tx, all strategies) and perf), this might be a good idea. The benefit here is that if we'd update Infinispan within Wildfly, the 2LC provider shipped would be updated. I was already thinking about pushing some functionality from 2LC to Infinispan, since I see the same problems as I've dealt with in 2LC being solved in other projects (e.g. Keycloak) and users in the forums (most recently [1]. However, I don't think that exposing just a cache mode (or modifying the current invalidation mode behaviour) is sufficient - I think that we need different API to be distilled from 2LC SPI. The problems that pop up are rather complex and require extensive testing up to the point that I would recommend deprecating invalidation modes when this gets implemented. If you look on the history of JBoss Cache/Infinispan, we have forgotten too many edge cases, resulting in low reliability. [1] https://developer.jboss.org/message/968821?et=watches.email.thread#968821 > > The major Hibernate version shipped in Wildfly is normally tied based on EE requirements, whereas Infinispan versions can more freely be upgraded, so I can't see the opposite problem happen that easily: the potential problem of having Infinispan 9.0.x having to work with both Hibernate 5 and 6... The reason WF 10+ integrates with Infinispan 8 while Hibernate 5.0 was compiled against Infinispan 7 is that we wanted to avoid supporting both 7 and 8 branches in the long term, while Hibernate 5.0 could not move to Infinispan 8 which was not released soon enough. I don't see why should Hibernate 5 ever work with Infinispan 9. Especially since Hibernate 6 will likely change some core concepts in hibernate-infinispan integration [2]. [2] https://hibernate.atlassian.net/browse/HHH-11356 > > An important thing would be to make sure we don't put barriers that makes consumption by user harder. > >> Historically that has been Hibernate, so hosting this code closer to Infinispan and then merely integrate with Hibernate would have been useful. >> >> Alternatively, let's see if we can embrace JCache all-in. The architecture I had discussed with Alex Snaps for the Hibernate /JCache integration would allow for "vendor specific extensions" to bypass the spec on some specific points as needed. Sanne, could you share details? > Not sure if I've seen the details of such architecture, but given JCache's stable API, maybe Hibernate should maybe just ship this provider, and any other providers be provided by the implementations themselves (as opposed to be included in Hibernate) I wonder if you could get JCache-facing implementation to be as fast as vendor specific, and if it would be reliable regardless of implementation. Current implementation seems to assume replicated cache, storing expirable locks that work as tombstones. Few notes: * Regrettably some quirks of ORM API (such as not calling afterUpdate/unlockItem after transaction rollback) cause these to stay somewhat longer than necessary, but this is something that can be fixed. * I am unsure if the algorithm would work perfectly with reads that use different LockMode; and generally there's no stress test in the testsuite. * The implementation uses loop of get/putIfAbsent/replace which could be replaced by EntryProcessors to achieve guaranteed max 2 RPC roundtrip of each operation. Infinispan should reimplement JCache's EntryProcessors to use the functional API. We'd need vendor specific extensions for effective marshalling. * We would need above mentioned vendor specific extensions to simulate PFERs with their fire&forget semantics. * 2LC can use operations where the order of updates is not important (it can be resolved in-situ), therefore strict ordering which we require for regular replicated caches is not required. * With JCache, you can't parallelize operations within transaction either as JCache does not have async ops (currently not utilized by Infinispan/by ORM either). Please don't try to mention running each operation as a task in a threadpool. * Some operations (after TX commit) are fine to run asynchronously [1] - similar to the fire&forget, reducing the latency. I admit that invalidation-mode in 2LC implementation is rather overcomplicated as it stores the lock-like structures in a separate cache (pending-puts), and has to provide custom RPCs for modifying this information on the remote side. I hope that in 9.x we'll expose a way to make tombstones non-evictable and we could get rid of the invalidation mode completely, as it does not provide any advantage to replicated mode and increases the complexity - being able to have eviction configured is IMO the last thing that holds it there (actually, some users might prefer to have the entries that are putFromLoaded available only locally, not occupying the cache on other nodes, but this is easy to simulate on repl cache, too). Radim [1] Galder, could you please review and merge https://github.com/hibernate/hibernate-orm/pull/1734 ? I completely forgot that it's still hanging in the PR queue. > Cheers, > >> >> On 16 Feb 2017 11:00, "Galder Zamarre?o" wrote: >> Hi all, >> >> As I've mentioned, I'm working on trying to integrate Hibernate 2LC (5.x branch at the moment) with Infinispan 9. >> >> To start with, I tried to see if I could just run Hibernate 2LC 5.x, compiled with Infinispan 8, with an Infinispan 9 runtime. The first problem here was to do with changes to PrioritizedMethodMetadata [1]. >> >> However, that above is the least of our problems... once I tried to compile with Infinispan 9, there are a lot of compilation errors. >> >> Here's a list of what I've found out so far, based on the work in [2] which includes compilation errors and runtime issues I've discovered: >> >> 1. Plenty of interceptors have been moved from org.infinispan.interceptors.base and org.infinispan.interceptors packages to org.infinispan.interceptors.impl package. >> >> 2. ModuleCommandFactory.fromStream now passes a cache name in ByteString instead of String. >> >> 3. DataWriteCommand.setMetadata() method is gone. The reason for this is that FlagAffectedCommand does no longer extend MetadataAwareCommand. >> >> 4. Interceptors cannot invoke invokeNextInterceptor() any more in parent, the method has been renamed to invokeNext() (in different class, AsyncInterceptor) >> >> 5. A lot of interceptors now take flags as long instead of Set which results in compilation error. >> >> 6. BaseRpcInterceptor subclasses are now force abstract protected method getLog() to be implemented, again a compilation error. >> >> 7. CallInterceptor no longer contains visit... methods, so all interceptors extending it need to extend CommandInterceptor and be placed just before CallInterceptor. >> >> 7.1. As a result of that, interceptor positioning calls need to be changed. >> >> 8. AdvancedCache.filterEntries() is gone, so need to find an alternative way to do the same. >> >> 9. WriteCommand.getAffectedKeys() returns Collection instead of Set now. >> >> 10. org.infinispan.filter.NullValueConverter is gone. I removed that as part of marshalling changes since it was not used anywhere within Infinispan repo, but Hibernate 2LC actually uses it. >> >> 11. BeginInvalidationCommand and EndInvalidationCommand write directly the lockOwner via `output.writeObject(lockOwner)`, but this causes problem when the lockOwner is a CommandInvocationId since there's no externalizer for it any more. The reason for not having an externalizer is that CommandInvocationId is written via static CommandInvocationId.writeTo() calls. >> >> 12. org.infinispan.commands.module.ExtendedModuleCommandFactory is gone. >> >> 13. ReplicableCommand.setParameters() method is gone. >> >> 14. BaseRpcCommand constructor takes a ByteString instead of String. >> >> 15. ReplicableCommand implementations need to implement writeTo() and readFrom() methods. >> >> 16. (test) BlockingInterceptor no longer can be added via AdvancedCache.addInterceptor() call because it does not extend CommandInterceptor any more. >> >> 17. (test) org.infinispan.util.concurrent.ConcurrentHashSet has been moved. >> >> 18. (test) TestingEntityCacheKey must be made extend ExternalPojo so that it can be externally marshalled. >> >> 19. (test) 2lc-test-tcp.xml contains attributes that are no longer found by JGroups 4.x and throws errors. >> >> The question here is whether we should work towards making Infinispan 9 backwards compatible with Infinispan 8 as far as Hibernate 2LC integration is concerned. >> >> In theory, Infinispan 9 should be integrated with Hibernate 6.x onwards, but as always, Wildfly might have different opinions... @Paul? >> >> If we need to do something, the time to do it is now, before 9.Final. >> >> Cheers, >> >> p.s. A lot of tests still failing, so the work in [2] is nowhere near finished. >> >> [1] https://gist.github.com/galderz/e26ea9d4838a965500906a6df87e064a >> [2] https://github.com/galderz/hibernate-orm/commit/5e36a021db4eaad75d835d321282eee6c62cc7c6 >> -- >> Galder Zamarre?o >> Infinispan, Red Hat >> >> >> _______________________________________________ >> 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 -- Radim Vansa JBoss Performance Team From slaskawi at redhat.com Fri Feb 17 08:40:29 2017 From: slaskawi at redhat.com (Sebastian Laskawiec) Date: Fri, 17 Feb 2017 13:40:29 +0000 Subject: [infinispan-dev] Backwards compatibility issues with Infinispan 9.x and Hibernate 2LC In-Reply-To: References: <3C1761C3-87FF-4616-BA59-909471EF72FD@redhat.com> Message-ID: And how about changing slightly our approach and implement a stable, dedicated APIs on both Hibernate and Infinispan side. This way the Hibernate 2LC module would simply glue those two together and should be fairly simple. We could document such APIs and somewhat "freeze" them allowing only adding new methods but never changing or removing old ones. On Thu, Feb 16, 2017 at 12:31 PM Sanne Grinovero wrote: > Have fun with the rewriting! > ;) > > More seriously, it might be worth to have a second module for Hibernate > ORM 5.x to address Infinispan 9? > At least in depth testing, stressing and performance aspect won't be left > to the last minute integration step. > > Also, would it be worth to move such code to Infinispan? In such cases > neither repository is ideal, but I'd tend to prefer to integrate with the > one which has the more stable and well defined integration point. > Historically that has been Hibernate, so hosting this code closer to > Infinispan and then merely integrate with Hibernate would have been useful. > > Alternatively, let's see if we can embrace JCache all-in. The architecture > I had discussed with Alex Snaps for the Hibernate /JCache integration would > allow for "vendor specific extensions" to bypass the spec on some specific > points as needed. > > > On 16 Feb 2017 11:00, "Galder Zamarre?o" wrote: > > Hi all, > > As I've mentioned, I'm working on trying to integrate Hibernate 2LC (5.x > branch at the moment) with Infinispan 9. > > To start with, I tried to see if I could just run Hibernate 2LC 5.x, > compiled with Infinispan 8, with an Infinispan 9 runtime. The first problem > here was to do with changes to PrioritizedMethodMetadata [1]. > > However, that above is the least of our problems... once I tried to > compile with Infinispan 9, there are a lot of compilation errors. > > Here's a list of what I've found out so far, based on the work in [2] > which includes compilation errors and runtime issues I've discovered: > > 1. Plenty of interceptors have been moved from > org.infinispan.interceptors.base and org.infinispan.interceptors packages > to org.infinispan.interceptors.impl package. > > 2. ModuleCommandFactory.fromStream now passes a cache name in ByteString > instead of String. > > 3. DataWriteCommand.setMetadata() method is gone. The reason for this is > that FlagAffectedCommand does no longer extend MetadataAwareCommand. > > 4. Interceptors cannot invoke invokeNextInterceptor() any more in parent, > the method has been renamed to invokeNext() (in different class, > AsyncInterceptor) > > 5. A lot of interceptors now take flags as long instead of Set which > results in compilation error. > > 6. BaseRpcInterceptor subclasses are now force abstract protected method > getLog() to be implemented, again a compilation error. > > 7. CallInterceptor no longer contains visit... methods, so all > interceptors extending it need to extend CommandInterceptor and be placed > just before CallInterceptor. > > 7.1. As a result of that, interceptor positioning calls need to be changed. > > 8. AdvancedCache.filterEntries() is gone, so need to find an alternative > way to do the same. > > 9. WriteCommand.getAffectedKeys() returns Collection instead of Set now. > > 10. org.infinispan.filter.NullValueConverter is gone. I removed that as > part of marshalling changes since it was not used anywhere within > Infinispan repo, but Hibernate 2LC actually uses it. > > 11. BeginInvalidationCommand and EndInvalidationCommand write directly the > lockOwner via `output.writeObject(lockOwner)`, but this causes problem when > the lockOwner is a CommandInvocationId since there's no externalizer for it > any more. The reason for not having an externalizer is that > CommandInvocationId is written via static CommandInvocationId.writeTo() > calls. > > 12. org.infinispan.commands.module.ExtendedModuleCommandFactory is gone. > > 13. ReplicableCommand.setParameters() method is gone. > > 14. BaseRpcCommand constructor takes a ByteString instead of String. > > 15. ReplicableCommand implementations need to implement writeTo() and > readFrom() methods. > > 16. (test) BlockingInterceptor no longer can be added via > AdvancedCache.addInterceptor() call because it does not extend > CommandInterceptor any more. > > 17. (test) org.infinispan.util.concurrent.ConcurrentHashSet has been moved. > > 18. (test) TestingEntityCacheKey must be made extend ExternalPojo so that > it can be externally marshalled. > > 19. (test) 2lc-test-tcp.xml contains attributes that are no longer found > by JGroups 4.x and throws errors. > > The question here is whether we should work towards making Infinispan 9 > backwards compatible with Infinispan 8 as far as Hibernate 2LC integration > is concerned. > > In theory, Infinispan 9 should be integrated with Hibernate 6.x onwards, > but as always, Wildfly might have different opinions... @Paul? > > If we need to do something, the time to do it is now, before 9.Final. > > Cheers, > > p.s. A lot of tests still failing, so the work in [2] is nowhere near > finished. > > [1] https://gist.github.com/galderz/e26ea9d4838a965500906a6df87e064a > [2] > https://github.com/galderz/hibernate-orm/commit/5e36a021db4eaad75d835d321282eee6c62cc7c6 > -- > Galder Zamarre?o > Infinispan, Red Hat > > > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20170217/3ca284ff/attachment-0001.html From galder at redhat.com Mon Feb 20 09:52:08 2017 From: galder at redhat.com (=?utf-8?Q?Galder_Zamarre=C3=B1o?=) Date: Mon, 20 Feb 2017 15:52:08 +0100 Subject: [infinispan-dev] GetKeyValueCommand NPE with CR1 in Hibernate 2LC - ISPN-7029 In-Reply-To: References: <6F4EF3D8-2509-4209-9CD1-A3D65F195681@redhat.com> Message-ID: <12BF89EA-E18A-4116-B9B8-43B13CAF7BE1@redhat.com> I've just verified the problem and the NPE can be reproduced with Infinispan alone. More replies below: -- Galder Zamarre?o Infinispan, Red Hat > On 16 Feb 2017, at 10:44, Radim Vansa wrote: > > On 02/15/2017 06:07 PM, Galder Zamarre?o wrote: >> -- >> Galder Zamarre?o >> Infinispan, Red Hat >> >>> On 15 Feb 2017, at 12:21, Radim Vansa wrote: >>> >>> On 02/15/2017 11:28 AM, Galder Zamarre?o wrote: >>>> Hey Radim, >>>> >>>> Your changes in ISPN-7029 are causing issues with Hibernate 2LC. >>>> >>>> In particular [2]. Name.equals() always returns false, so it'll never be found in the context. So entry is null. >>> That's obviously a bug in the 2LC testsuite, isn't it? >> LOL, is it? You added the class and the javadoc clearly states that this entity defines equals incorrectly. You must have added it for a reason? >> >> https://github.com/hibernate/hibernate-orm/blob/master/hibernate-infinispan/src/test/java/org/hibernate/test/cache/infinispan/functional/entities/Name.java >> >> In any case, an object with an incorrect equals impl should not result in an NPE within Infinispan :| >> >>> Object used as @EmbeddedId needs to have the equals correctly defined. How else would you compare ids? I wonder how could that work in the past. >> ROFL... it's your baby so you tell me ;) > > Okay, okay - I haven't checked the javadoc, so I just assumed that it's an oversight :) > >> >>>> Moreover, if EntryLookup.lookupEntry javadoc (and some implementations) can and do return null. Are you expecting that somehow that method will never return null? >>> With ISPN-7029 in, the entry should be wrapped in the context after EntryWrappingInterceptor if the key is in readCH, otherwise it should be null. In case that xDistributionInterceptor finds out that it needs to work on that value despite not being able to read it (e.g. in case that it's in writeCH during unfinished rebalance), it should wrap NullCacheEntry.getInstance() using EntryFactory. wrapExternalEntry. More info about the logic is in o.i.c.EntryFactory javadoc [3]. >> Not sure I understand what you're trying to imply above... so, is lookupEntry() allowed to return null or not? > > It is allowed to return null, but: > > 1. If the node is an owner according to readCH, the entry must be wrapped into context in EWI (possibly as NullCacheEntry). > 2. The code can reach the GKVC.perform() iff this node is an owner of given key. > > The problem here is that I've assumed that if the entry was wrapped, it can be fetched. With incorrectly defined equals, as we see here, this does not hold. So we can > > a) check if the entry is null and throw more explanatory exception - more code in perform() > b) do the lookup after wrapping and throw there - unnecessary map lookup for such annoying problem > c) ostrich approach > > I think that b) in assert could do, otherwise I'd suggest c) Hmmmmm, what about not throwing an exception at all? IOW, e.g. in SingleKeyNonTxInvocationContext.lookupEntry(), if the key is not equals to the one cached, but the cached one is NullCacheEntry, couldn't it return that instead of null? What I'm trying to achieve here is that if the equals is not correctly implemented, the get() returns null, rather than throwing an exception. We'd also need to verify whether other context implementations could deal with it. Wouldn't that be better :\ ? I can see the point of throwing an exception (other than NPE of course), but it feels a little abrupt... particularly since seems like previously we've just returned null in such situations. Cheers, > > Radim > >> >> To be more specific, SingleKeyNonTxInvocationContext.lookupEntry() can return null, so GetKeyValueCommand should be able to handle it? Or should SingleKeyNonTxInvocationContext.lookupEntry return NullCacheEntry.getInstance instead of null? >> >> To provide more specifics, SingleKeyNonTxInvocationContext has NullCacheEntry.getInstance in cacheEntry variable when it's returning null. Should it maybe return NullCacheEntry.getInstance instead of null from lookupEntry() ? >> >> Cheers, >> >>> Radim >>> >>> [3] https://github.com/infinispan/infinispan/blob/master/core/src/main/java/org/infinispan/container/EntryFactory.java >>> >>>> I'll create a JIRA to track all issues arising from Hibernate 2LC in a minute, but wanted to get your thoughts firts. >>>> >>>> Cheers, >>>> >>>> [1] https://issues.jboss.org/browse/ISPN-7029 >>>> [2] https://github.com/hibernate/hibernate-orm/blob/master/hibernate-infinispan/src/test/java/org/hibernate/test/cache/infinispan/CacheKeysFactoryTest.java#L58 >>>> -- >>>> Galder Zamarre?o >>>> Infinispan, Red Hat >>>> >>> >>> -- >>> Radim Vansa >>> JBoss Performance Team > > > -- > Radim Vansa > JBoss Performance Team > From ttarrant at redhat.com Mon Feb 20 11:06:51 2017 From: ttarrant at redhat.com (Tristan Tarrant) Date: Mon, 20 Feb 2017 17:06:51 +0100 Subject: [infinispan-dev] Major version cleaning Message-ID: <98a58d71-7daf-35c7-8e54-85735217a2d7@redhat.com> Hi guys, we discussed about this a little bit in the past and this morning on IRC. Here are some proposed removals: - Remove the async transactional modes, as they are quite pointless - Remove batching: users should use transactions - Remove the tree module: it doesn't work properly, and uses batching Please cast your votes Tristan -- Tristan Tarrant Infinispan Lead JBoss, a division of Red Hat From bban at redhat.com Mon Feb 20 11:12:47 2017 From: bban at redhat.com (Bela Ban) Date: Mon, 20 Feb 2017 17:12:47 +0100 Subject: [infinispan-dev] Major version cleaning In-Reply-To: <98a58d71-7daf-35c7-8e54-85735217a2d7@redhat.com> References: <98a58d71-7daf-35c7-8e54-85735217a2d7@redhat.com> Message-ID: <16911ebf-a3c2-ab04-a615-03a19730aa13@redhat.com> On 20/02/17 17:06, Tristan Tarrant wrote: > Hi guys, we discussed about this a little bit in the past and this > morning on IRC. Here are some proposed removals: > > - Remove the async transactional modes, as they are quite pointless > - Remove batching: users should use transactions How do you make a bunch of modifications and send them asynchronously if both batching *and* async TXs are getting removed? So if someone wants to apply a unit of work *atomically* (either all modifications within that unit of work are applied, or none), what alternatives exist? > - Remove the tree module: it doesn't work properly, and uses batching > > Please cast your votes > > Tristan > -- Bela Ban, JGroups lead (http://www.jgroups.org) From rvansa at redhat.com Mon Feb 20 11:22:06 2017 From: rvansa at redhat.com (Radim Vansa) Date: Mon, 20 Feb 2017 17:22:06 +0100 Subject: [infinispan-dev] GetKeyValueCommand NPE with CR1 in Hibernate 2LC - ISPN-7029 In-Reply-To: <12BF89EA-E18A-4116-B9B8-43B13CAF7BE1@redhat.com> References: <6F4EF3D8-2509-4209-9CD1-A3D65F195681@redhat.com> <12BF89EA-E18A-4116-B9B8-43B13CAF7BE1@redhat.com> Message-ID: <324cb4ad-8e90-a83e-f98a-9b11852bbb7b@redhat.com> On 02/20/2017 03:52 PM, Galder Zamarre?o wrote: > I've just verified the problem and the NPE can be reproduced with Infinispan alone. > > More replies below: > > -- > Galder Zamarre?o > Infinispan, Red Hat > >> On 16 Feb 2017, at 10:44, Radim Vansa wrote: >> >> On 02/15/2017 06:07 PM, Galder Zamarre?o wrote: >>> -- >>> Galder Zamarre?o >>> Infinispan, Red Hat >>> >>>> On 15 Feb 2017, at 12:21, Radim Vansa wrote: >>>> >>>> On 02/15/2017 11:28 AM, Galder Zamarre?o wrote: >>>>> Hey Radim, >>>>> >>>>> Your changes in ISPN-7029 are causing issues with Hibernate 2LC. >>>>> >>>>> In particular [2]. Name.equals() always returns false, so it'll never be found in the context. So entry is null. >>>> That's obviously a bug in the 2LC testsuite, isn't it? >>> LOL, is it? You added the class and the javadoc clearly states that this entity defines equals incorrectly. You must have added it for a reason? >>> >>> https://github.com/hibernate/hibernate-orm/blob/master/hibernate-infinispan/src/test/java/org/hibernate/test/cache/infinispan/functional/entities/Name.java >>> >>> In any case, an object with an incorrect equals impl should not result in an NPE within Infinispan :| >>> >>>> Object used as @EmbeddedId needs to have the equals correctly defined. How else would you compare ids? I wonder how could that work in the past. >>> ROFL... it's your baby so you tell me ;) >> Okay, okay - I haven't checked the javadoc, so I just assumed that it's an oversight :) >> >>>>> Moreover, if EntryLookup.lookupEntry javadoc (and some implementations) can and do return null. Are you expecting that somehow that method will never return null? >>>> With ISPN-7029 in, the entry should be wrapped in the context after EntryWrappingInterceptor if the key is in readCH, otherwise it should be null. In case that xDistributionInterceptor finds out that it needs to work on that value despite not being able to read it (e.g. in case that it's in writeCH during unfinished rebalance), it should wrap NullCacheEntry.getInstance() using EntryFactory. wrapExternalEntry. More info about the logic is in o.i.c.EntryFactory javadoc [3]. >>> Not sure I understand what you're trying to imply above... so, is lookupEntry() allowed to return null or not? >> It is allowed to return null, but: >> >> 1. If the node is an owner according to readCH, the entry must be wrapped into context in EWI (possibly as NullCacheEntry). >> 2. The code can reach the GKVC.perform() iff this node is an owner of given key. >> >> The problem here is that I've assumed that if the entry was wrapped, it can be fetched. With incorrectly defined equals, as we see here, this does not hold. So we can >> >> a) check if the entry is null and throw more explanatory exception - more code in perform() >> b) do the lookup after wrapping and throw there - unnecessary map lookup for such annoying problem >> c) ostrich approach >> >> I think that b) in assert could do, otherwise I'd suggest c) > Hmmmmm, what about not throwing an exception at all? > > IOW, e.g. in SingleKeyNonTxInvocationContext.lookupEntry(), if the key is not equals to the one cached, but the cached one is NullCacheEntry, couldn't it return that instead of null? What I'm trying to achieve here is that if the equals is not correctly implemented, the get() returns null, rather than throwing an exception. > > We'd also need to verify whether other context implementations could deal with it. > > Wouldn't that be better :\ ? I can see the point of throwing an exception (other than NPE of course), but it feels a little abrupt... particularly since seems like previously we've just returned null in such situations. You're right that Cache.get(x) should ideally return null. InvocationContext.lookupEntry() returning NullCacheEntry and null has a different meaning, though: * NullCacheEntry means that we are supposed to be able to read that entry (according to readCH) but we haven't found that in DC. This is used for example in CacheLoaderInterceptor, where we skip entries that aren't in the context as opposed to recomputing the hash of the key. * null means that this entry cannot be read on this node because the segment this key belongs to is not in readCH, and therefore the command shouldn't get past distribution interceptor. I don't mind changing the 'design' as long as it follows some simple rules. I don't see how returning NCE for *any* key could be incorporated into the rules, and how should that behave on multi-key contexts. In all but distribution mode, during read the key must be always wrapped for read, because there's either no readCH (local) or replicated CH (repl/invalidation). But in invalidation/local mode we can't handle that in distribution interceptor as this is not present. I would really prefer to see this handled in EntryWrappingInterceptor/EntryWrappingFactory rather than in each command - in #4564 [2] I wanted to narrow the possible situations to be handled in perform(), and other pieces (e.g. return handlers - see dataReadReturnHandler, that will throw NPE as well in TX RR right now). Note that some commands do the check ATM (e.g. functional commands) - I think that those are leftovers and should be gone. I was about to suggest adding if (!key.equals(key)) return null; to all EWI.visitXXX methods as proper implemenations of equals should do the if (other == this) return true; anyway as a shortcut, so such check shouldn't affect performance. However, this is not as simple with functional commands which should operate on the null entry (on some node), we have to run these, and you can't even ignore the value, you need some entry in there. I hate not finding my socks in the drawer where I definitely put those. This just breaks too many things :-( Btw., it seems that SingleTxContextInvocationContext [1] will fail when the entry is loaded from cache store - this is the place where you could put the entry into invocation context twice. So the use case was somewhat broken before, too. [1] https://github.com/infinispan/infinispan/blob/master/core/src/main/java/org/infinispan/context/SingleKeyNonTxInvocationContext.java#L114 [2] https://github.com/infinispan/infinispan/pull/4564 > > Cheers, > >> Radim >> >>> To be more specific, SingleKeyNonTxInvocationContext.lookupEntry() can return null, so GetKeyValueCommand should be able to handle it? Or should SingleKeyNonTxInvocationContext.lookupEntry return NullCacheEntry.getInstance instead of null? >>> >>> To provide more specifics, SingleKeyNonTxInvocationContext has NullCacheEntry.getInstance in cacheEntry variable when it's returning null. Should it maybe return NullCacheEntry.getInstance instead of null from lookupEntry() ? >>> >>> Cheers, >>> >>>> Radim >>>> >>>> [3] https://github.com/infinispan/infinispan/blob/master/core/src/main/java/org/infinispan/container/EntryFactory.java >>>> >>>>> I'll create a JIRA to track all issues arising from Hibernate 2LC in a minute, but wanted to get your thoughts firts. >>>>> >>>>> Cheers, >>>>> >>>>> [1] https://issues.jboss.org/browse/ISPN-7029 >>>>> [2] https://github.com/hibernate/hibernate-orm/blob/master/hibernate-infinispan/src/test/java/org/hibernate/test/cache/infinispan/CacheKeysFactoryTest.java#L58 >>>>> -- >>>>> Galder Zamarre?o >>>>> Infinispan, Red Hat >>>>> >>>> -- >>>> Radim Vansa >>>> JBoss Performance Team >> >> -- >> Radim Vansa >> JBoss Performance Team >> -- Radim Vansa JBoss Performance Team From pedro at infinispan.org Mon Feb 20 11:48:30 2017 From: pedro at infinispan.org (Pedro Ruivo) Date: Mon, 20 Feb 2017 16:48:30 +0000 Subject: [infinispan-dev] Major version cleaning In-Reply-To: <16911ebf-a3c2-ab04-a615-03a19730aa13@redhat.com> References: <98a58d71-7daf-35c7-8e54-85735217a2d7@redhat.com> <16911ebf-a3c2-ab04-a615-03a19730aa13@redhat.com> Message-ID: <7c019da8-61b2-59d2-e671-aeca1f3fb7b6@infinispan.org> On 20-02-2017 16:12, Bela Ban wrote: > > > On 20/02/17 17:06, Tristan Tarrant wrote: >> Hi guys, we discussed about this a little bit in the past and this >> morning on IRC. Here are some proposed removals: >> >> - Remove the async transactional modes, as they are quite pointless >> - Remove batching: users should use transactions > > How do you make a bunch of modifications and send them asynchronously if > both batching *and* async TXs are getting removed? We are not removing features, we are removing broken code. Batching is using transactions and async transactions doesn't make sense since infinispan has to report to TransactionManager. Our current asyn-tx is broken in a way that is starts to commit and reports OK to the transaction manager. if you have a topology change or a conflict, you will end with inconsistent data. So, why do we keeping this code around? you can still move a transaction commit to another thread if you don't wanna wait for its commit: tm.begin() doWork() tx = tm.suspend() new_thread { tm.resume(tx) tm.commit() } The best thing I can think of is to keep the batching API and re-implement it to provide an endBatchAsync() that will do the above. > > So if someone wants to apply a unit of work *atomically* (either all > modifications within that unit of work are applied, or none), what > alternatives exist? > >> - Remove the tree module: it doesn't work properly, and uses batching >> >> Please cast your votes >> >> Tristan >> > From sanne at infinispan.org Mon Feb 20 13:02:14 2017 From: sanne at infinispan.org (Sanne Grinovero) Date: Mon, 20 Feb 2017 18:02:14 +0000 Subject: [infinispan-dev] Major version cleaning In-Reply-To: <7c019da8-61b2-59d2-e671-aeca1f3fb7b6@infinispan.org> References: <98a58d71-7daf-35c7-8e54-85735217a2d7@redhat.com> <16911ebf-a3c2-ab04-a615-03a19730aa13@redhat.com> <7c019da8-61b2-59d2-e671-aeca1f3fb7b6@infinispan.org> Message-ID: -1 to batch removal Frankly I've always been extremely negative about the fact that batches are built on top of transactions. It's easy to find several iterations of rants of mine on this mailing list, especially fierce debates with Mircea. So I'd welcome a separation of these features. Yet, removing batching seems very wrong. I disagree that people should use Transactions instead; for many use cases it's overkill, and for others - and this is the main pain point I always had with the current design - it might make sense to have a batch (or more than one) within a transaction. I have had practical problems with needing to "flush" a single batch within a transaction as the size of the combined elements was getting too large. That doesn't imply at all that I'm ready to commit. @Pedro: the fact that some code is broken today is not relevant, when there's need for such features. Like you suggest, it had bad premises (build it on TX) so we should address that, but not throw it all out. @Bela is making spot-on objections based on use cases, which need to be addressed in some way. The "atomical" operations still don't work right[1] in Infinispan and that's a big usability problem. +1 to remove async TX I actually like the concept but the API should be different.. might as well remove this for now. +1 to remove the Tree module I personally never used it as you all advised against, yet it's been often requested by users; sometimes explicitly and others not so explicit, yet people often have need which would be solved by a good Tree module. I understand the reasons you all want to remove it: it's buggy. But I believe the real reason is that it should have been built on top of a proper batch API, and using real MVCC. In that case it wouldn't have been buggy, nor too hard to maintain, and might have attracted way more interest as well. I'd remove it as a temporary measure: delete the bad stuff, but hopefully it could be reintroduced built on better principles in some future? Thanks, Sanne [1] - "right" as in user expectations and actual practical use, which is currently different than in the twisted definition of "right" that the team has been using as an excuse ;-) I'll also proof that it doesn't work right according to your own twisted specs, when I find the time to finish some tests.. On 20 February 2017 at 16:48, Pedro Ruivo wrote: > > > On 20-02-2017 16:12, Bela Ban wrote: >> >> >> On 20/02/17 17:06, Tristan Tarrant wrote: >>> Hi guys, we discussed about this a little bit in the past and this >>> morning on IRC. Here are some proposed removals: >>> >>> - Remove the async transactional modes, as they are quite pointless >>> - Remove batching: users should use transactions >> >> How do you make a bunch of modifications and send them asynchronously if >> both batching *and* async TXs are getting removed? > > We are not removing features, we are removing broken code. > > Batching is using transactions and async transactions doesn't make sense > since infinispan has to report to TransactionManager. > > Our current asyn-tx is broken in a way that is starts to commit and > reports OK to the transaction manager. if you have a topology change or > a conflict, you will end with inconsistent data. > > So, why do we keeping this code around? > > you can still move a transaction commit to another thread if you don't > wanna wait for its commit: > > tm.begin() > doWork() > tx = tm.suspend() > new_thread { > tm.resume(tx) > tm.commit() > } > > The best thing I can think of is to keep the batching API and > re-implement it to provide an endBatchAsync() that will do the above. > >> >> So if someone wants to apply a unit of work *atomically* (either all >> modifications within that unit of work are applied, or none), what >> alternatives exist? >> >>> - Remove the tree module: it doesn't work properly, and uses batching >>> >>> Please cast your votes >>> >>> Tristan >>> >> > _______________________________________________ > infinispan-dev mailing list > infinispan-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev From denis.kirpichenkov at gmail.com Mon Feb 20 13:22:29 2017 From: denis.kirpichenkov at gmail.com (Denis V. Kirpichenkov) Date: Mon, 20 Feb 2017 23:22:29 +0500 Subject: [infinispan-dev] Major version cleaning In-Reply-To: References: <98a58d71-7daf-35c7-8e54-85735217a2d7@redhat.com> <16911ebf-a3c2-ab04-a615-03a19730aa13@redhat.com> <7c019da8-61b2-59d2-e671-aeca1f3fb7b6@infinispan.org> Message-ID: <81d2c0a6-a7d5-2ef8-3f6b-a59ad6d03aaf@gmail.com> Hello. May I ask what's wrong with tree module? I work on a project which depends on this module heavily. I hope it is not a huge problem to reimplement tree module or at least some part of it if someone will tell me where to start :) -- Denis On 20.02.2017 23:02, Sanne Grinovero wrote: > -1 to batch removal > > Frankly I've always been extremely negative about the fact that > batches are built on top of transactions. It's easy to find several > iterations of rants of mine on this mailing list, especially fierce > debates with Mircea. So I'd welcome a separation of these features. > > Yet, removing batching seems very wrong. I disagree that people should > use Transactions instead; for many use cases it's overkill, and for > others - and this is the main pain point I always had with the current > design - it might make sense to have a batch (or more than one) within > a transaction. > I have had practical problems with needing to "flush" a single batch > within a transaction as the size of the combined elements was getting > too large. That doesn't imply at all that I'm ready to commit. > > @Pedro: the fact that some code is broken today is not relevant, when > there's need for such features. Like you suggest, it had bad premises > (build it on TX) so we should address that, but not throw it all out. > > @Bela is making spot-on objections based on use cases, which need to > be addressed in some way. The "atomical" operations still don't work > right[1] in Infinispan and that's a big usability problem. > > +1 to remove async TX > > I actually like the concept but the API should be different.. might as > well remove this for now. > > +1 to remove the Tree module > > I personally never used it as you all advised against, yet it's been > often requested by users; sometimes explicitly and others not so > explicit, yet people often have need which would be solved by a good > Tree module. > I understand the reasons you all want to remove it: it's buggy. But I > believe the real reason is that it should have been built on top of a > proper batch API, and using real MVCC. In that case it wouldn't have > been buggy, nor too hard to maintain, and might have attracted way > more interest as well. > I'd remove it as a temporary measure: delete the bad stuff, but > hopefully it could be reintroduced built on better principles in some > future? > > Thanks, > Sanne > > [1] - "right" as in user expectations and actual practical use, which > is currently different than in the twisted definition of "right" that > the team has been using as an excuse ;-) I'll also proof that it > doesn't work right according to your own twisted specs, when I find > the time to finish some tests.. > > > On 20 February 2017 at 16:48, Pedro Ruivo wrote: >> >> On 20-02-2017 16:12, Bela Ban wrote: >>> >>> On 20/02/17 17:06, Tristan Tarrant wrote: >>>> Hi guys, we discussed about this a little bit in the past and this >>>> morning on IRC. Here are some proposed removals: >>>> >>>> - Remove the async transactional modes, as they are quite pointless >>>> - Remove batching: users should use transactions >>> How do you make a bunch of modifications and send them asynchronously if >>> both batching *and* async TXs are getting removed? >> We are not removing features, we are removing broken code. >> >> Batching is using transactions and async transactions doesn't make sense >> since infinispan has to report to TransactionManager. >> >> Our current asyn-tx is broken in a way that is starts to commit and >> reports OK to the transaction manager. if you have a topology change or >> a conflict, you will end with inconsistent data. >> >> So, why do we keeping this code around? >> >> you can still move a transaction commit to another thread if you don't >> wanna wait for its commit: >> >> tm.begin() >> doWork() >> tx = tm.suspend() >> new_thread { >> tm.resume(tx) >> tm.commit() >> } >> >> The best thing I can think of is to keep the batching API and >> re-implement it to provide an endBatchAsync() that will do the above. >> >>> So if someone wants to apply a unit of work *atomically* (either all >>> modifications within that unit of work are applied, or none), what >>> alternatives exist? >>> >>>> - Remove the tree module: it doesn't work properly, and uses batching >>>> >>>> Please cast your votes >>>> >>>> Tristan >>>> >> _______________________________________________ >> 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 From ttarrant at redhat.com Mon Feb 20 15:11:27 2017 From: ttarrant at redhat.com (Tristan Tarrant) Date: Mon, 20 Feb 2017 21:11:27 +0100 Subject: [infinispan-dev] Major version cleaning In-Reply-To: References: <98a58d71-7daf-35c7-8e54-85735217a2d7@redhat.com> <16911ebf-a3c2-ab04-a615-03a19730aa13@redhat.com> <7c019da8-61b2-59d2-e671-aeca1f3fb7b6@infinispan.org> Message-ID: On 20/02/17 19:02, Sanne Grinovero wrote: > -1 to batch removal > > Frankly I've always been extremely negative about the fact that > batches are built on top of transactions. I think the discussion is pointless without clearing up what the expected semantics of a batch should be and what the expected advantages over individual invocations should be. A batch is just a glorified putAll which also supports removes. All write ops are queued locally and are then sent in groups to the respective owners. What you get is deferred invocations and 1 remote invocation per unique owner. What you don't get is atomicity and isolation. You should use transactions for that. Tristan -- Tristan Tarrant Infinispan Lead JBoss, a division of Red Hat From ttarrant at redhat.com Mon Feb 20 15:13:26 2017 From: ttarrant at redhat.com (Tristan Tarrant) Date: Mon, 20 Feb 2017 21:13:26 +0100 Subject: [infinispan-dev] Major version cleaning In-Reply-To: <81d2c0a6-a7d5-2ef8-3f6b-a59ad6d03aaf@gmail.com> References: <98a58d71-7daf-35c7-8e54-85735217a2d7@redhat.com> <16911ebf-a3c2-ab04-a615-03a19730aa13@redhat.com> <7c019da8-61b2-59d2-e671-aeca1f3fb7b6@infinispan.org> <81d2c0a6-a7d5-2ef8-3f6b-a59ad6d03aaf@gmail.com> Message-ID: <75019284-6b1d-3fa7-e82b-4154e2347fc6@redhat.com> It has always been regarded as buggy and unmaintained and more of a convenience for users coming from the old JBossCache. If you are willing to help out, we can list the most important issues. Tristan On 20/02/17 19:22, Denis V. Kirpichenkov wrote: > Hello. > > May I ask what's wrong with tree module? > > I work on a project which depends on this module heavily. I hope it is > not a huge problem to reimplement tree module or at least some part of > it if someone will tell me where to start :) > > -- > > Denis > > > On 20.02.2017 23:02, Sanne Grinovero wrote: >> -1 to batch removal >> >> Frankly I've always been extremely negative about the fact that >> batches are built on top of transactions. It's easy to find several >> iterations of rants of mine on this mailing list, especially fierce >> debates with Mircea. So I'd welcome a separation of these features. >> >> Yet, removing batching seems very wrong. I disagree that people should >> use Transactions instead; for many use cases it's overkill, and for >> others - and this is the main pain point I always had with the current >> design - it might make sense to have a batch (or more than one) within >> a transaction. >> I have had practical problems with needing to "flush" a single batch >> within a transaction as the size of the combined elements was getting >> too large. That doesn't imply at all that I'm ready to commit. >> >> @Pedro: the fact that some code is broken today is not relevant, when >> there's need for such features. Like you suggest, it had bad premises >> (build it on TX) so we should address that, but not throw it all out. >> >> @Bela is making spot-on objections based on use cases, which need to >> be addressed in some way. The "atomical" operations still don't work >> right[1] in Infinispan and that's a big usability problem. >> >> +1 to remove async TX >> >> I actually like the concept but the API should be different.. might as >> well remove this for now. >> >> +1 to remove the Tree module >> >> I personally never used it as you all advised against, yet it's been >> often requested by users; sometimes explicitly and others not so >> explicit, yet people often have need which would be solved by a good >> Tree module. >> I understand the reasons you all want to remove it: it's buggy. But I >> believe the real reason is that it should have been built on top of a >> proper batch API, and using real MVCC. In that case it wouldn't have >> been buggy, nor too hard to maintain, and might have attracted way >> more interest as well. >> I'd remove it as a temporary measure: delete the bad stuff, but >> hopefully it could be reintroduced built on better principles in some >> future? >> >> Thanks, >> Sanne >> >> [1] - "right" as in user expectations and actual practical use, which >> is currently different than in the twisted definition of "right" that >> the team has been using as an excuse ;-) I'll also proof that it >> doesn't work right according to your own twisted specs, when I find >> the time to finish some tests.. >> >> >> On 20 February 2017 at 16:48, Pedro Ruivo wrote: >>> >>> On 20-02-2017 16:12, Bela Ban wrote: >>>> >>>> On 20/02/17 17:06, Tristan Tarrant wrote: >>>>> Hi guys, we discussed about this a little bit in the past and this >>>>> morning on IRC. Here are some proposed removals: >>>>> >>>>> - Remove the async transactional modes, as they are quite pointless >>>>> - Remove batching: users should use transactions >>>> How do you make a bunch of modifications and send them asynchronously if >>>> both batching *and* async TXs are getting removed? >>> We are not removing features, we are removing broken code. >>> >>> Batching is using transactions and async transactions doesn't make sense >>> since infinispan has to report to TransactionManager. >>> >>> Our current asyn-tx is broken in a way that is starts to commit and >>> reports OK to the transaction manager. if you have a topology change or >>> a conflict, you will end with inconsistent data. >>> >>> So, why do we keeping this code around? >>> >>> you can still move a transaction commit to another thread if you don't >>> wanna wait for its commit: >>> >>> tm.begin() >>> doWork() >>> tx = tm.suspend() >>> new_thread { >>> tm.resume(tx) >>> tm.commit() >>> } >>> >>> The best thing I can think of is to keep the batching API and >>> re-implement it to provide an endBatchAsync() that will do the above. >>> >>>> So if someone wants to apply a unit of work *atomically* (either all >>>> modifications within that unit of work are applied, or none), what >>>> alternatives exist? >>>> >>>>> - Remove the tree module: it doesn't work properly, and uses batching >>>>> >>>>> Please cast your votes >>>>> >>>>> Tristan >>>>> >>> _______________________________________________ >>> 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 > -- Tristan Tarrant Infinispan Lead JBoss, a division of Red Hat From sanne at infinispan.org Mon Feb 20 17:11:37 2017 From: sanne at infinispan.org (Sanne Grinovero) Date: Mon, 20 Feb 2017 22:11:37 +0000 Subject: [infinispan-dev] Major version cleaning In-Reply-To: References: <98a58d71-7daf-35c7-8e54-85735217a2d7@redhat.com> <16911ebf-a3c2-ab04-a615-03a19730aa13@redhat.com> <7c019da8-61b2-59d2-e671-aeca1f3fb7b6@infinispan.org> Message-ID: On 20 February 2017 at 20:11, Tristan Tarrant wrote: > On 20/02/17 19:02, Sanne Grinovero wrote: >> -1 to batch removal >> >> Frankly I've always been extremely negative about the fact that >> batches are built on top of transactions. > > I think the discussion is pointless without clearing up what the > expected semantics of a batch should be and what the expected advantages > over individual invocations should be. > A batch is just a glorified putAll which also supports removes. All > write ops are queued locally and are then sent in groups to the > respective owners. What you get is deferred invocations and 1 remote > invocation per unique owner. What you don't get is atomicity and > isolation. You should use transactions for that. I get that. But the "glorified putAll which also supports removes" is important to have. > > Tristan > -- > Tristan Tarrant > Infinispan Lead > JBoss, a division of Red Hat > _______________________________________________ > infinispan-dev mailing list > infinispan-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev From denis.kirpichenkov at gmail.com Tue Feb 21 00:07:35 2017 From: denis.kirpichenkov at gmail.com (Denis V. Kirpichenkov) Date: Tue, 21 Feb 2017 10:07:35 +0500 Subject: [infinispan-dev] Major version cleaning In-Reply-To: <75019284-6b1d-3fa7-e82b-4154e2347fc6@redhat.com> References: <98a58d71-7daf-35c7-8e54-85735217a2d7@redhat.com> <16911ebf-a3c2-ab04-a615-03a19730aa13@redhat.com> <7c019da8-61b2-59d2-e671-aeca1f3fb7b6@infinispan.org> <81d2c0a6-a7d5-2ef8-3f6b-a59ad6d03aaf@gmail.com> <75019284-6b1d-3fa7-e82b-4154e2347fc6@redhat.com> Message-ID: <7a3f1a47-3080-118a-2206-70dbb106bad6@gmail.com> Tristan, yes, I'd like to help. And the list of issues with this module would be something to start with. Thanks. -- Denis On 21.02.2017 01:13, Tristan Tarrant wrote: > It has always been regarded as buggy and unmaintained and more of a > convenience for users coming from the old JBossCache. > If you are willing to help out, we can list the most important issues. > > Tristan > > On 20/02/17 19:22, Denis V. Kirpichenkov wrote: >> Hello. >> >> May I ask what's wrong with tree module? >> >> I work on a project which depends on this module heavily. I hope it is >> not a huge problem to reimplement tree module or at least some part of >> it if someone will tell me where to start :) >> >> -- >> >> Denis >> >> >> On 20.02.2017 23:02, Sanne Grinovero wrote: >>> -1 to batch removal >>> >>> Frankly I've always been extremely negative about the fact that >>> batches are built on top of transactions. It's easy to find several >>> iterations of rants of mine on this mailing list, especially fierce >>> debates with Mircea. So I'd welcome a separation of these features. >>> >>> Yet, removing batching seems very wrong. I disagree that people should >>> use Transactions instead; for many use cases it's overkill, and for >>> others - and this is the main pain point I always had with the current >>> design - it might make sense to have a batch (or more than one) within >>> a transaction. >>> I have had practical problems with needing to "flush" a single batch >>> within a transaction as the size of the combined elements was getting >>> too large. That doesn't imply at all that I'm ready to commit. >>> >>> @Pedro: the fact that some code is broken today is not relevant, when >>> there's need for such features. Like you suggest, it had bad premises >>> (build it on TX) so we should address that, but not throw it all out. >>> >>> @Bela is making spot-on objections based on use cases, which need to >>> be addressed in some way. The "atomical" operations still don't work >>> right[1] in Infinispan and that's a big usability problem. >>> >>> +1 to remove async TX >>> >>> I actually like the concept but the API should be different.. might as >>> well remove this for now. >>> >>> +1 to remove the Tree module >>> >>> I personally never used it as you all advised against, yet it's been >>> often requested by users; sometimes explicitly and others not so >>> explicit, yet people often have need which would be solved by a good >>> Tree module. >>> I understand the reasons you all want to remove it: it's buggy. But I >>> believe the real reason is that it should have been built on top of a >>> proper batch API, and using real MVCC. In that case it wouldn't have >>> been buggy, nor too hard to maintain, and might have attracted way >>> more interest as well. >>> I'd remove it as a temporary measure: delete the bad stuff, but >>> hopefully it could be reintroduced built on better principles in some >>> future? >>> >>> Thanks, >>> Sanne >>> >>> [1] - "right" as in user expectations and actual practical use, which >>> is currently different than in the twisted definition of "right" that >>> the team has been using as an excuse ;-) I'll also proof that it >>> doesn't work right according to your own twisted specs, when I find >>> the time to finish some tests.. >>> >>> >>> On 20 February 2017 at 16:48, Pedro Ruivo wrote: >>>> On 20-02-2017 16:12, Bela Ban wrote: >>>>> On 20/02/17 17:06, Tristan Tarrant wrote: >>>>>> Hi guys, we discussed about this a little bit in the past and this >>>>>> morning on IRC. Here are some proposed removals: >>>>>> >>>>>> - Remove the async transactional modes, as they are quite pointless >>>>>> - Remove batching: users should use transactions >>>>> How do you make a bunch of modifications and send them asynchronously if >>>>> both batching *and* async TXs are getting removed? >>>> We are not removing features, we are removing broken code. >>>> >>>> Batching is using transactions and async transactions doesn't make sense >>>> since infinispan has to report to TransactionManager. >>>> >>>> Our current asyn-tx is broken in a way that is starts to commit and >>>> reports OK to the transaction manager. if you have a topology change or >>>> a conflict, you will end with inconsistent data. >>>> >>>> So, why do we keeping this code around? >>>> >>>> you can still move a transaction commit to another thread if you don't >>>> wanna wait for its commit: >>>> >>>> tm.begin() >>>> doWork() >>>> tx = tm.suspend() >>>> new_thread { >>>> tm.resume(tx) >>>> tm.commit() >>>> } >>>> >>>> The best thing I can think of is to keep the batching API and >>>> re-implement it to provide an endBatchAsync() that will do the above. >>>> >>>>> So if someone wants to apply a unit of work *atomically* (either all >>>>> modifications within that unit of work are applied, or none), what >>>>> alternatives exist? >>>>> >>>>>> - Remove the tree module: it doesn't work properly, and uses batching >>>>>> >>>>>> Please cast your votes >>>>>> >>>>>> Tristan >>>>>> >>>> _______________________________________________ >>>> 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 >> From dan.berindei at gmail.com Tue Feb 21 02:37:26 2017 From: dan.berindei at gmail.com (Dan Berindei) Date: Tue, 21 Feb 2017 09:37:26 +0200 Subject: [infinispan-dev] Major version cleaning In-Reply-To: References: <98a58d71-7daf-35c7-8e54-85735217a2d7@redhat.com> <16911ebf-a3c2-ab04-a615-03a19730aa13@redhat.com> <7c019da8-61b2-59d2-e671-aeca1f3fb7b6@infinispan.org> Message-ID: On Mon, Feb 20, 2017 at 8:02 PM, Sanne Grinovero wrote: > -1 to batch removal > > Frankly I've always been extremely negative about the fact that > batches are built on top of transactions. It's easy to find several > iterations of rants of mine on this mailing list, especially fierce > debates with Mircea. So I'd welcome a separation of these features. > > Yet, removing batching seems very wrong. I disagree that people should > use Transactions instead; for many use cases it's overkill, and for > others - and this is the main pain point I always had with the current > design - it might make sense to have a batch (or more than one) within > a transaction. > I have had practical problems with needing to "flush" a single batch > within a transaction as the size of the combined elements was getting > too large. That doesn't imply at all that I'm ready to commit. > WDYM by "flush" here? I have a feeling this is nothing like our batching ever was... > @Pedro: the fact that some code is broken today is not relevant, when > there's need for such features. Like you suggest, it had bad premises > (build it on TX) so we should address that, but not throw it all out. > Infinispan never created nested batches: calling startBatch() when a batch was already associated with the current thread just incremented a refcount, and only the final endBatch() did any work. OTOH running a batch within a transaction always worked very much like suspending the current transaction, starting a new one, and committing it on endBatch(). So the only real difference between batching and using DummyTransactionManager is that batching is limited to one cache's operations, while DummyTransactionManager supports multiple resources. > @Bela is making spot-on objections based on use cases, which need to > be addressed in some way. The "atomical" operations still don't work > right[1] in Infinispan and that's a big usability problem. > Batching never was about sending updates asynchronously. We have putAllAsync() for that, which doesn't need transactions, and it's even slightly more efficient without transactions. And atomical operations have bugs, yes, but I'm not sure how implementing a new kind of batching that isn't based on transactions would help with that. > +1 to remove async TX > > I actually like the concept but the API should be different.. might as > well remove this for now. > > +1 to remove the Tree module > > I personally never used it as you all advised against, yet it's been > often requested by users; sometimes explicitly and others not so > explicit, yet people often have need which would be solved by a good > Tree module. > I understand the reasons you all want to remove it: it's buggy. But I > believe the real reason is that it should have been built on top of a > proper batch API, and using real MVCC. In that case it wouldn't have > been buggy, nor too hard to maintain, and might have attracted way > more interest as well. I think the fact that we haven't been able to build a "proper" batch API using real MVCC yet is a proof to the contrary... > I'd remove it as a temporary measure: delete the bad stuff, but > hopefully it could be reintroduced built on better principles in some > future? > > Thanks, > Sanne > > [1] - "right" as in user expectations and actual practical use, which > is currently different than in the twisted definition of "right" that > the team has been using as an excuse ;-) I'll also proof that it > doesn't work right according to your own twisted specs, when I find > the time to finish some tests.. > > > On 20 February 2017 at 16:48, Pedro Ruivo wrote: >> >> >> On 20-02-2017 16:12, Bela Ban wrote: >>> >>> >>> On 20/02/17 17:06, Tristan Tarrant wrote: >>>> Hi guys, we discussed about this a little bit in the past and this >>>> morning on IRC. Here are some proposed removals: >>>> >>>> - Remove the async transactional modes, as they are quite pointless >>>> - Remove batching: users should use transactions >>> >>> How do you make a bunch of modifications and send them asynchronously if >>> both batching *and* async TXs are getting removed? >> >> We are not removing features, we are removing broken code. >> >> Batching is using transactions and async transactions doesn't make sense >> since infinispan has to report to TransactionManager. >> >> Our current asyn-tx is broken in a way that is starts to commit and >> reports OK to the transaction manager. if you have a topology change or >> a conflict, you will end with inconsistent data. >> >> So, why do we keeping this code around? >> >> you can still move a transaction commit to another thread if you don't >> wanna wait for its commit: >> >> tm.begin() >> doWork() >> tx = tm.suspend() >> new_thread { >> tm.resume(tx) >> tm.commit() >> } >> >> The best thing I can think of is to keep the batching API and >> re-implement it to provide an endBatchAsync() that will do the above. >> >>> >>> So if someone wants to apply a unit of work *atomically* (either all >>> modifications within that unit of work are applied, or none), what >>> alternatives exist? >>> >>>> - Remove the tree module: it doesn't work properly, and uses batching >>>> >>>> Please cast your votes >>>> >>>> Tristan >>>> >>> >> _______________________________________________ >> 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 From dan.berindei at gmail.com Tue Feb 21 03:10:27 2017 From: dan.berindei at gmail.com (Dan Berindei) Date: Tue, 21 Feb 2017 10:10:27 +0200 Subject: [infinispan-dev] Major version cleaning In-Reply-To: <98a58d71-7daf-35c7-8e54-85735217a2d7@redhat.com> References: <98a58d71-7daf-35c7-8e54-85735217a2d7@redhat.com> Message-ID: +1 to remove the async transactional modes +1 to remove batching I'm ambivalent about the tree module. I think we should be able to get it on a better footing by using the transactions API, but I'm unsure about the amount of work needed. The biggest problem with the tree module and batching, as I see it, is that tree operations use FORCE_WRITE_LOCK a lot, but FORCE_WRITE_LOCK does not compose well. If the application starts a batch and reads a node's data/children normally, a FORCE_WRITE_LOCK read later will *not* mean the entry in the invocation context is the latest value in the cache, and tree operations will not behave atomically. We could force each tree read operation to use FORCE_WRITE_LOCK, but it would probably have a negative impact on performance. Currently we also allow the tree module to use optimistic locking, but that means concurrent updates either a) give inconsistent results, because the last write wins or b) throw WriteSkewException, which the application is likely not to handle properly. I don't think building the tree module on top of a non-transactional cache or the functional API is an option, because TreeCache explicitly supports batching via startAtomic()/endAtomic(). Of course, there are also more basic problems that would need to be solved, like the tree module apparently not working in distributed mode: http://stackoverflow.com/questions/29673123/infinispan-treecache-not-getting-distributed-properly Cheers Dan On Mon, Feb 20, 2017 at 6:06 PM, Tristan Tarrant wrote: > Hi guys, we discussed about this a little bit in the past and this > morning on IRC. Here are some proposed removals: > > - Remove the async transactional modes, as they are quite pointless > - Remove batching: users should use transactions > - Remove the tree module: it doesn't work properly, and uses batching > > Please cast your votes > > Tristan > -- > Tristan Tarrant > Infinispan Lead > JBoss, a division of Red Hat > _______________________________________________ > infinispan-dev mailing list > infinispan-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev From sanne at infinispan.org Tue Feb 21 03:39:06 2017 From: sanne at infinispan.org (Sanne Grinovero) Date: Tue, 21 Feb 2017 08:39:06 +0000 Subject: [infinispan-dev] Major version cleaning In-Reply-To: References: <98a58d71-7daf-35c7-8e54-85735217a2d7@redhat.com> <16911ebf-a3c2-ab04-a615-03a19730aa13@redhat.com> <7c019da8-61b2-59d2-e671-aeca1f3fb7b6@infinispan.org> Message-ID: On 21 February 2017 at 07:37, Dan Berindei wrote: > On Mon, Feb 20, 2017 at 8:02 PM, Sanne Grinovero wrote: >> -1 to batch removal >> >> Frankly I've always been extremely negative about the fact that >> batches are built on top of transactions. It's easy to find several >> iterations of rants of mine on this mailing list, especially fierce >> debates with Mircea. So I'd welcome a separation of these features. >> >> Yet, removing batching seems very wrong. I disagree that people should >> use Transactions instead; for many use cases it's overkill, and for >> others - and this is the main pain point I always had with the current >> design - it might make sense to have a batch (or more than one) within >> a transaction. >> I have had practical problems with needing to "flush" a single batch >> within a transaction as the size of the combined elements was getting >> too large. That doesn't imply at all that I'm ready to commit. >> > > WDYM by "flush" here? I have a feeling this is nothing like our > batching ever was... I'm just listing points about why incorporating the batch concept with transactions is not practical. I mean that when one has to write very large amounts of data, you need to break it up in smaller batches; *essentially* to flush the first batch before starting the second one. So that is unrelated with atomicity and consistency, as in practice one has to split one business operation into multiple batches. > >> @Pedro: the fact that some code is broken today is not relevant, when >> there's need for such features. Like you suggest, it had bad premises >> (build it on TX) so we should address that, but not throw it all out. >> > > Infinispan never created nested batches: I know. I'm not describing the current implementation, I'm describing use cases which are not addressed, or in which Infinispan is clumsy to use, to suggest improvements. And I'm not asking to have nested batches. Again, just pointing out practical problems with the current batch design. It should be possible to run an efficient batch of operations within a transaction. Or a sequence of batches, all within the same transaction. N.B. you could see that as a "nested batch" in the current twisted idea that a batch is a transaction - which is what I'm arguing against. > calling startBatch() when a > batch was already associated with the current thread just incremented > a refcount, and only the final endBatch() did any work. OTOH running a > batch within a transaction always worked very much like suspending the > current transaction, starting a new one, and committing it on > endBatch(). So the only real difference between batching and using > DummyTransactionManager is that batching is limited to one cache's > operations, while DummyTransactionManager supports multiple resources. > > >> @Bela is making spot-on objections based on use cases, which need to >> be addressed in some way. The "atomical" operations still don't work >> right[1] in Infinispan and that's a big usability problem. >> > > Batching never was about sending updates asynchronously. We have > putAllAsync() for that, which doesn't need transactions, and it's even > slightly more efficient without transactions. If you think this way, it sounds like you give no value to the application performance: people need more than a couple put operations. > > And atomical operations have bugs, yes, but I'm not sure how > implementing a new kind of batching that isn't based on transactions > would help with that. > > >> +1 to remove async TX >> >> I actually like the concept but the API should be different.. might as >> well remove this for now. >> >> +1 to remove the Tree module >> >> I personally never used it as you all advised against, yet it's been >> often requested by users; sometimes explicitly and others not so >> explicit, yet people often have need which would be solved by a good >> Tree module. >> I understand the reasons you all want to remove it: it's buggy. But I >> believe the real reason is that it should have been built on top of a >> proper batch API, and using real MVCC. In that case it wouldn't have >> been buggy, nor too hard to maintain, and might have attracted way >> more interest as well. > > I think the fact that we haven't been able to build a "proper" batch > API using real MVCC yet is a proof to the contrary... > > >> I'd remove it as a temporary measure: delete the bad stuff, but >> hopefully it could be reintroduced built on better principles in some >> future? >> >> Thanks, >> Sanne >> >> [1] - "right" as in user expectations and actual practical use, which >> is currently different than in the twisted definition of "right" that >> the team has been using as an excuse ;-) I'll also proof that it >> doesn't work right according to your own twisted specs, when I find >> the time to finish some tests.. >> >> >> On 20 February 2017 at 16:48, Pedro Ruivo wrote: >>> >>> >>> On 20-02-2017 16:12, Bela Ban wrote: >>>> >>>> >>>> On 20/02/17 17:06, Tristan Tarrant wrote: >>>>> Hi guys, we discussed about this a little bit in the past and this >>>>> morning on IRC. Here are some proposed removals: >>>>> >>>>> - Remove the async transactional modes, as they are quite pointless >>>>> - Remove batching: users should use transactions >>>> >>>> How do you make a bunch of modifications and send them asynchronously if >>>> both batching *and* async TXs are getting removed? >>> >>> We are not removing features, we are removing broken code. >>> >>> Batching is using transactions and async transactions doesn't make sense >>> since infinispan has to report to TransactionManager. >>> >>> Our current asyn-tx is broken in a way that is starts to commit and >>> reports OK to the transaction manager. if you have a topology change or >>> a conflict, you will end with inconsistent data. >>> >>> So, why do we keeping this code around? >>> >>> you can still move a transaction commit to another thread if you don't >>> wanna wait for its commit: >>> >>> tm.begin() >>> doWork() >>> tx = tm.suspend() >>> new_thread { >>> tm.resume(tx) >>> tm.commit() >>> } >>> >>> The best thing I can think of is to keep the batching API and >>> re-implement it to provide an endBatchAsync() that will do the above. >>> >>>> >>>> So if someone wants to apply a unit of work *atomically* (either all >>>> modifications within that unit of work are applied, or none), what >>>> alternatives exist? >>>> >>>>> - Remove the tree module: it doesn't work properly, and uses batching >>>>> >>>>> Please cast your votes >>>>> >>>>> Tristan >>>>> >>>> >>> _______________________________________________ >>> 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 From bban at redhat.com Tue Feb 21 07:21:47 2017 From: bban at redhat.com (Bela Ban) Date: Tue, 21 Feb 2017 13:21:47 +0100 Subject: [infinispan-dev] JGroups 4.0 released Message-ID: <39155eaa-3268-aa31-9013-3e72087c1c06@redhat.com> FYI: http://belaban.blogspot.ch/2017/02/jgroups-400final.html -- Bela Ban, JGroups lead (http://www.jgroups.org) From rvansa at redhat.com Tue Feb 21 08:00:04 2017 From: rvansa at redhat.com (Radim Vansa) Date: Tue, 21 Feb 2017 14:00:04 +0100 Subject: [infinispan-dev] Major version cleaning In-Reply-To: <7a3f1a47-3080-118a-2206-70dbb106bad6@gmail.com> References: <98a58d71-7daf-35c7-8e54-85735217a2d7@redhat.com> <16911ebf-a3c2-ab04-a615-03a19730aa13@redhat.com> <7c019da8-61b2-59d2-e671-aeca1f3fb7b6@infinispan.org> <81d2c0a6-a7d5-2ef8-3f6b-a59ad6d03aaf@gmail.com> <75019284-6b1d-3fa7-e82b-4154e2347fc6@redhat.com> <7a3f1a47-3080-118a-2206-70dbb106bad6@gmail.com> Message-ID: <20fe6f06-ce3f-7253-7a3c-56d4cb96a881@redhat.com> Hi Denis, recently I had to disable test for move() operation in pessimistic cache [1] because the way move is implemented cannot work. I'll be happy to consult possible fix (please use another thread for that). For the record, this is not exhaustive list of problems, I haven't touched tree module but to fix failed testsuite. Radim [1] https://github.com/infinispan/infinispan/blob/73ad80212d34ed675670f608047e014fbc00a12a/tree/src/test/java/org/infinispan/api/tree/NodeMoveAPIPessimisticTest.java#L31 On 02/21/2017 06:07 AM, Denis V. Kirpichenkov wrote: > Tristan, yes, I'd like to help. > > And the list of issues with this module would be something to start with. > > Thanks. > > -- > > Denis > > > On 21.02.2017 01:13, Tristan Tarrant wrote: >> It has always been regarded as buggy and unmaintained and more of a >> convenience for users coming from the old JBossCache. >> If you are willing to help out, we can list the most important issues. >> >> Tristan >> >> On 20/02/17 19:22, Denis V. Kirpichenkov wrote: >>> Hello. >>> >>> May I ask what's wrong with tree module? >>> >>> I work on a project which depends on this module heavily. I hope it is >>> not a huge problem to reimplement tree module or at least some part of >>> it if someone will tell me where to start :) >>> >>> -- >>> >>> Denis >>> >>> >>> On 20.02.2017 23:02, Sanne Grinovero wrote: >>>> -1 to batch removal >>>> >>>> Frankly I've always been extremely negative about the fact that >>>> batches are built on top of transactions. It's easy to find several >>>> iterations of rants of mine on this mailing list, especially fierce >>>> debates with Mircea. So I'd welcome a separation of these features. >>>> >>>> Yet, removing batching seems very wrong. I disagree that people should >>>> use Transactions instead; for many use cases it's overkill, and for >>>> others - and this is the main pain point I always had with the current >>>> design - it might make sense to have a batch (or more than one) within >>>> a transaction. >>>> I have had practical problems with needing to "flush" a single batch >>>> within a transaction as the size of the combined elements was getting >>>> too large. That doesn't imply at all that I'm ready to commit. >>>> >>>> @Pedro: the fact that some code is broken today is not relevant, when >>>> there's need for such features. Like you suggest, it had bad premises >>>> (build it on TX) so we should address that, but not throw it all out. >>>> >>>> @Bela is making spot-on objections based on use cases, which need to >>>> be addressed in some way. The "atomical" operations still don't work >>>> right[1] in Infinispan and that's a big usability problem. >>>> >>>> +1 to remove async TX >>>> >>>> I actually like the concept but the API should be different.. might as >>>> well remove this for now. >>>> >>>> +1 to remove the Tree module >>>> >>>> I personally never used it as you all advised against, yet it's been >>>> often requested by users; sometimes explicitly and others not so >>>> explicit, yet people often have need which would be solved by a good >>>> Tree module. >>>> I understand the reasons you all want to remove it: it's buggy. But I >>>> believe the real reason is that it should have been built on top of a >>>> proper batch API, and using real MVCC. In that case it wouldn't have >>>> been buggy, nor too hard to maintain, and might have attracted way >>>> more interest as well. >>>> I'd remove it as a temporary measure: delete the bad stuff, but >>>> hopefully it could be reintroduced built on better principles in some >>>> future? >>>> >>>> Thanks, >>>> Sanne >>>> >>>> [1] - "right" as in user expectations and actual practical use, which >>>> is currently different than in the twisted definition of "right" that >>>> the team has been using as an excuse ;-) I'll also proof that it >>>> doesn't work right according to your own twisted specs, when I find >>>> the time to finish some tests.. >>>> >>>> >>>> On 20 February 2017 at 16:48, Pedro Ruivo wrote: >>>>> On 20-02-2017 16:12, Bela Ban wrote: >>>>>> On 20/02/17 17:06, Tristan Tarrant wrote: >>>>>>> Hi guys, we discussed about this a little bit in the past and this >>>>>>> morning on IRC. Here are some proposed removals: >>>>>>> >>>>>>> - Remove the async transactional modes, as they are quite pointless >>>>>>> - Remove batching: users should use transactions >>>>>> How do you make a bunch of modifications and send them asynchronously if >>>>>> both batching *and* async TXs are getting removed? >>>>> We are not removing features, we are removing broken code. >>>>> >>>>> Batching is using transactions and async transactions doesn't make sense >>>>> since infinispan has to report to TransactionManager. >>>>> >>>>> Our current asyn-tx is broken in a way that is starts to commit and >>>>> reports OK to the transaction manager. if you have a topology change or >>>>> a conflict, you will end with inconsistent data. >>>>> >>>>> So, why do we keeping this code around? >>>>> >>>>> you can still move a transaction commit to another thread if you don't >>>>> wanna wait for its commit: >>>>> >>>>> tm.begin() >>>>> doWork() >>>>> tx = tm.suspend() >>>>> new_thread { >>>>> tm.resume(tx) >>>>> tm.commit() >>>>> } >>>>> >>>>> The best thing I can think of is to keep the batching API and >>>>> re-implement it to provide an endBatchAsync() that will do the above. >>>>> >>>>>> So if someone wants to apply a unit of work *atomically* (either all >>>>>> modifications within that unit of work are applied, or none), what >>>>>> alternatives exist? >>>>>> >>>>>>> - Remove the tree module: it doesn't work properly, and uses batching >>>>>>> >>>>>>> Please cast your votes >>>>>>> >>>>>>> Tristan >>>>>>> >>>>> _______________________________________________ >>>>> 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 -- Radim Vansa JBoss Performance Team From rvansa at redhat.com Tue Feb 21 08:20:00 2017 From: rvansa at redhat.com (Radim Vansa) Date: Tue, 21 Feb 2017 14:20:00 +0100 Subject: [infinispan-dev] Major version cleaning In-Reply-To: References: <98a58d71-7daf-35c7-8e54-85735217a2d7@redhat.com> <16911ebf-a3c2-ab04-a615-03a19730aa13@redhat.com> <7c019da8-61b2-59d2-e671-aeca1f3fb7b6@infinispan.org> Message-ID: On 02/21/2017 09:39 AM, Sanne Grinovero wrote: > On 21 February 2017 at 07:37, Dan Berindei wrote: >> On Mon, Feb 20, 2017 at 8:02 PM, Sanne Grinovero wrote: >>> -1 to batch removal >>> >>> Frankly I've always been extremely negative about the fact that >>> batches are built on top of transactions. It's easy to find several >>> iterations of rants of mine on this mailing list, especially fierce >>> debates with Mircea. So I'd welcome a separation of these features. >>> >>> Yet, removing batching seems very wrong. I disagree that people should >>> use Transactions instead; for many use cases it's overkill, and for >>> others - and this is the main pain point I always had with the current >>> design - it might make sense to have a batch (or more than one) within >>> a transaction. >>> I have had practical problems with needing to "flush" a single batch >>> within a transaction as the size of the combined elements was getting >>> too large. That doesn't imply at all that I'm ready to commit. >>> >> WDYM by "flush" here? I have a feeling this is nothing like our >> batching ever was... > I'm just listing points about why incorporating the batch concept with > transactions is not practical. > > I mean that when one has to write very large amounts of data, you need to > break it up in smaller batches; *essentially* to flush the first batch before > starting the second one. > So that is unrelated with atomicity and consistency, as in practice one has > to split one business operation into multiple batches. You haven't explained what "flush" means. Since you separate that from atomicity/consistency, I assume that batches on non-tx cache are just ordered putOrRemoveAll operations, immediately visible on flush without any atomicity. If you want batches in transactions, you probably mean that the changes are not visible until tx commits. So you are worried that all data modified within this transaction won't fit into single node memory? Or is there more to that? What's a "nested batch", then? I could see some benefits in removing repeatable-reads cached values. >>> @Pedro: the fact that some code is broken today is not relevant, when >>> there's need for such features. Like you suggest, it had bad premises >>> (build it on TX) so we should address that, but not throw it all out. >>> >> Infinispan never created nested batches: > I know. I'm not describing the current implementation, I'm describing use > cases which are not addressed, or in which Infinispan is clumsy to use, > to suggest improvements. > And I'm not asking to have nested batches. Again, just pointing > out practical problems with the current batch design. > > It should be possible to run an efficient batch of operations within a > transaction. > Or a sequence of batches, all within the same transaction. > N.B. you could see that as a "nested batch" in the current twisted idea that > a batch is a transaction - which is what I'm arguing against. > > >> calling startBatch() when a >> batch was already associated with the current thread just incremented >> a refcount, and only the final endBatch() did any work. OTOH running a >> batch within a transaction always worked very much like suspending the >> current transaction, starting a new one, and committing it on >> endBatch(). So the only real difference between batching and using >> DummyTransactionManager is that batching is limited to one cache's >> operations, while DummyTransactionManager supports multiple resources. >> >> >>> @Bela is making spot-on objections based on use cases, which need to >>> be addressed in some way. The "atomical" operations still don't work >>> right[1] in Infinispan and that's a big usability problem. >>> >> Batching never was about sending updates asynchronously. We have >> putAllAsync() for that, which doesn't need transactions, and it's even >> slightly more efficient without transactions. > If you think this way, it sounds like you give no value to the application > performance: people need more than a couple put operations. Removes? I am really asking out of curiosity, I hope these questions don't sound ironically. R. > >> And atomical operations have bugs, yes, but I'm not sure how >> implementing a new kind of batching that isn't based on transactions >> would help with that. >> >> >>> +1 to remove async TX >>> >>> I actually like the concept but the API should be different.. might as >>> well remove this for now. >>> >>> +1 to remove the Tree module >>> >>> I personally never used it as you all advised against, yet it's been >>> often requested by users; sometimes explicitly and others not so >>> explicit, yet people often have need which would be solved by a good >>> Tree module. >>> I understand the reasons you all want to remove it: it's buggy. But I >>> believe the real reason is that it should have been built on top of a >>> proper batch API, and using real MVCC. In that case it wouldn't have >>> been buggy, nor too hard to maintain, and might have attracted way >>> more interest as well. >> I think the fact that we haven't been able to build a "proper" batch >> API using real MVCC yet is a proof to the contrary... >> >> >>> I'd remove it as a temporary measure: delete the bad stuff, but >>> hopefully it could be reintroduced built on better principles in some >>> future? >>> >>> Thanks, >>> Sanne >>> >>> [1] - "right" as in user expectations and actual practical use, which >>> is currently different than in the twisted definition of "right" that >>> the team has been using as an excuse ;-) I'll also proof that it >>> doesn't work right according to your own twisted specs, when I find >>> the time to finish some tests.. >>> >>> >>> On 20 February 2017 at 16:48, Pedro Ruivo wrote: >>>> >>>> On 20-02-2017 16:12, Bela Ban wrote: >>>>> >>>>> On 20/02/17 17:06, Tristan Tarrant wrote: >>>>>> Hi guys, we discussed about this a little bit in the past and this >>>>>> morning on IRC. Here are some proposed removals: >>>>>> >>>>>> - Remove the async transactional modes, as they are quite pointless >>>>>> - Remove batching: users should use transactions >>>>> How do you make a bunch of modifications and send them asynchronously if >>>>> both batching *and* async TXs are getting removed? >>>> We are not removing features, we are removing broken code. >>>> >>>> Batching is using transactions and async transactions doesn't make sense >>>> since infinispan has to report to TransactionManager. >>>> >>>> Our current asyn-tx is broken in a way that is starts to commit and >>>> reports OK to the transaction manager. if you have a topology change or >>>> a conflict, you will end with inconsistent data. >>>> >>>> So, why do we keeping this code around? >>>> >>>> you can still move a transaction commit to another thread if you don't >>>> wanna wait for its commit: >>>> >>>> tm.begin() >>>> doWork() >>>> tx = tm.suspend() >>>> new_thread { >>>> tm.resume(tx) >>>> tm.commit() >>>> } >>>> >>>> The best thing I can think of is to keep the batching API and >>>> re-implement it to provide an endBatchAsync() that will do the above. >>>> >>>>> So if someone wants to apply a unit of work *atomically* (either all >>>>> modifications within that unit of work are applied, or none), what >>>>> alternatives exist? >>>>> >>>>>> - Remove the tree module: it doesn't work properly, and uses batching >>>>>> >>>>>> Please cast your votes >>>>>> >>>>>> Tristan >>>>>> >>>> _______________________________________________ >>>> 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 -- Radim Vansa JBoss Performance Team From sanne at infinispan.org Tue Feb 21 08:37:01 2017 From: sanne at infinispan.org (Sanne Grinovero) Date: Tue, 21 Feb 2017 13:37:01 +0000 Subject: [infinispan-dev] JGroups 4.0 released In-Reply-To: <39155eaa-3268-aa31-9013-3e72087c1c06@redhat.com> References: <39155eaa-3268-aa31-9013-3e72087c1c06@redhat.com> Message-ID: Congratulations! On 21 Feb 2017 12:21, "Bela Ban" wrote: > FYI: http://belaban.blogspot.ch/2017/02/jgroups-400final.html > > -- > Bela Ban, JGroups lead (http://www.jgroups.org) > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20170221/554a1d8c/attachment.html From tsykora at redhat.com Tue Feb 21 08:45:52 2017 From: tsykora at redhat.com (Tomas Sykora) Date: Tue, 21 Feb 2017 08:45:52 -0500 (EST) Subject: [infinispan-dev] Martin Ribaric -- Migration of Infinispan OData server In-Reply-To: <798061185.25172176.1487684097320.JavaMail.zimbra@redhat.com> Message-ID: <4105715.25177213.1487684752977.JavaMail.zimbra@redhat.com> Hello everyone :) I am enclosing Martin's email and sending it from my email address because he sent it twice already and we can't see his emails from his gmail address for whatever strange reason here. Martin is CCed, hopefully will receive all reactions from this thread, please make sure you include him in CC while replying :) Thank you! ----------------- Hello Infinispan community, let me introduce myself shortly, my name is Martin Ribari? and I studied Masaryk University ? Faculty of Informatics in Brno. I wrote my bachelor thesis on topic: Migration of Infinispan OData server. I would like to tell you a few words about my work. The primary goal of my bachelor thesis was to develop/migrate a new solution of OData service for Infinispan. New solution is needed, because old solution was developed using odata4j library and development of this library was kind of stopped. New solution of OData service is offered by project Apache Olingo. In my work, I've created a servlet for Infinispan cache using Apache Olingo library support for OData v4. We can put, get, manage and most importantly also query JSON documents in the cache. Querying is possible on basic key value or a property of JSON document. Also, in queries, we can use operations AND, OR, EQUALS and operations for reduction of a response list: SKIP and TOP. Source code of my bachelor thesis is available at: https://github.com/marib15/OlingoInfinispan-server Tomas Sykora will review my code and push my solution to https://github.com/infinispan/infinispan-odata-server master soon. If community will have an interest, we can have a plan to continue in development, so that server supports more operations... and also do performance testing. I know the solution is definitely not perfect but can definitely serve as a baseline for future work, adjustments or adoption. I am looking forward to hearing your responses! Have a nice day :) Ribari? From dan.berindei at gmail.com Tue Feb 21 09:52:22 2017 From: dan.berindei at gmail.com (Dan Berindei) Date: Tue, 21 Feb 2017 16:52:22 +0200 Subject: [infinispan-dev] Major version cleaning In-Reply-To: References: <98a58d71-7daf-35c7-8e54-85735217a2d7@redhat.com> <16911ebf-a3c2-ab04-a615-03a19730aa13@redhat.com> <7c019da8-61b2-59d2-e671-aeca1f3fb7b6@infinispan.org> Message-ID: On Tue, Feb 21, 2017 at 10:39 AM, Sanne Grinovero wrote: > On 21 February 2017 at 07:37, Dan Berindei wrote: >> On Mon, Feb 20, 2017 at 8:02 PM, Sanne Grinovero wrote: >>> -1 to batch removal >>> >>> Frankly I've always been extremely negative about the fact that >>> batches are built on top of transactions. It's easy to find several >>> iterations of rants of mine on this mailing list, especially fierce >>> debates with Mircea. So I'd welcome a separation of these features. >>> >>> Yet, removing batching seems very wrong. I disagree that people should >>> use Transactions instead; for many use cases it's overkill, and for >>> others - and this is the main pain point I always had with the current >>> design - it might make sense to have a batch (or more than one) within >>> a transaction. >>> I have had practical problems with needing to "flush" a single batch >>> within a transaction as the size of the combined elements was getting >>> too large. That doesn't imply at all that I'm ready to commit. >>> >> >> WDYM by "flush" here? I have a feeling this is nothing like our >> batching ever was... > > I'm just listing points about why incorporating the batch concept with > transactions is not practical. > > I mean that when one has to write very large amounts of data, you need to > break it up in smaller batches; *essentially* to flush the first batch before > starting the second one. > So that is unrelated with atomicity and consistency, as in practice one has > to split one business operation into multiple batches. > Kind of repeating Radim's question, but how is this better than having multiple small transactions and committing each one separately? >> >>> @Pedro: the fact that some code is broken today is not relevant, when >>> there's need for such features. Like you suggest, it had bad premises >>> (build it on TX) so we should address that, but not throw it all out. >>> >> >> Infinispan never created nested batches: > > I know. I'm not describing the current implementation, I'm describing use > cases which are not addressed, or in which Infinispan is clumsy to use, > to suggest improvements. > And I'm not asking to have nested batches. Again, just pointing > out practical problems with the current batch design. > > It should be possible to run an efficient batch of operations within a > transaction. > Or a sequence of batches, all within the same transaction. > N.B. you could see that as a "nested batch" in the current twisted idea that > a batch is a transaction - which is what I'm arguing against. > I'm sure there there are use cases that we don't address properly, but I don't know enough about those use cases or your proposed batching API improvements to really say anything about them. The only thing I'm confident about is that the current batching API is almost certainly not the answer. > >> calling startBatch() when a >> batch was already associated with the current thread just incremented >> a refcount, and only the final endBatch() did any work. OTOH running a >> batch within a transaction always worked very much like suspending the >> current transaction, starting a new one, and committing it on >> endBatch(). So the only real difference between batching and using >> DummyTransactionManager is that batching is limited to one cache's >> operations, while DummyTransactionManager supports multiple resources. >> >> >>> @Bela is making spot-on objections based on use cases, which need to >>> be addressed in some way. The "atomical" operations still don't work >>> right[1] in Infinispan and that's a big usability problem. >>> >> >> Batching never was about sending updates asynchronously. We have >> putAllAsync() for that, which doesn't need transactions, and it's even >> slightly more efficient without transactions. > > If you think this way, it sounds like you give no value to the application > performance: people need more than a couple put operations. > Unfortunately, going beyond simple put operations, e.g. conditional writes, is exactly where asynchronous replication fails. Even doing simple put operations and making sure that those values are written to the cache is an impossible task with asynchronous replication. Considering that the batch methods are called startAtomic() and endAtomic() in TreeCache, I really don't think they were created with asynchronous replication in mind. Off-topic: The BatchingCache#startBatch() javadoc was never true for distributed caches: writes are queued, but reads (or puts without IGNORE_RETURN_VALUES) always result in a remote call. Locks cause remote calls in a cache with pessimistic locking, too, although one could argue that back in version 4.0, locks were indeed acquired locally during the write and remotely at the end of the batch. >> >> And atomical operations have bugs, yes, but I'm not sure how >> implementing a new kind of batching that isn't based on transactions >> would help with that. >> >> >>> +1 to remove async TX >>> >>> I actually like the concept but the API should be different.. might as >>> well remove this for now. >>> >>> +1 to remove the Tree module >>> >>> I personally never used it as you all advised against, yet it's been >>> often requested by users; sometimes explicitly and others not so >>> explicit, yet people often have need which would be solved by a good >>> Tree module. >>> I understand the reasons you all want to remove it: it's buggy. But I >>> believe the real reason is that it should have been built on top of a >>> proper batch API, and using real MVCC. In that case it wouldn't have >>> been buggy, nor too hard to maintain, and might have attracted way >>> more interest as well. >> >> I think the fact that we haven't been able to build a "proper" batch >> API using real MVCC yet is a proof to the contrary... >> >> >>> I'd remove it as a temporary measure: delete the bad stuff, but >>> hopefully it could be reintroduced built on better principles in some >>> future? >>> >>> Thanks, >>> Sanne >>> >>> [1] - "right" as in user expectations and actual practical use, which >>> is currently different than in the twisted definition of "right" that >>> the team has been using as an excuse ;-) I'll also proof that it >>> doesn't work right according to your own twisted specs, when I find >>> the time to finish some tests.. >>> >>> >>> On 20 February 2017 at 16:48, Pedro Ruivo wrote: >>>> >>>> >>>> On 20-02-2017 16:12, Bela Ban wrote: >>>>> >>>>> >>>>> On 20/02/17 17:06, Tristan Tarrant wrote: >>>>>> Hi guys, we discussed about this a little bit in the past and this >>>>>> morning on IRC. Here are some proposed removals: >>>>>> >>>>>> - Remove the async transactional modes, as they are quite pointless >>>>>> - Remove batching: users should use transactions >>>>> >>>>> How do you make a bunch of modifications and send them asynchronously if >>>>> both batching *and* async TXs are getting removed? >>>> >>>> We are not removing features, we are removing broken code. >>>> >>>> Batching is using transactions and async transactions doesn't make sense >>>> since infinispan has to report to TransactionManager. >>>> >>>> Our current asyn-tx is broken in a way that is starts to commit and >>>> reports OK to the transaction manager. if you have a topology change or >>>> a conflict, you will end with inconsistent data. >>>> >>>> So, why do we keeping this code around? >>>> >>>> you can still move a transaction commit to another thread if you don't >>>> wanna wait for its commit: >>>> >>>> tm.begin() >>>> doWork() >>>> tx = tm.suspend() >>>> new_thread { >>>> tm.resume(tx) >>>> tm.commit() >>>> } >>>> >>>> The best thing I can think of is to keep the batching API and >>>> re-implement it to provide an endBatchAsync() that will do the above. >>>> >>>>> >>>>> So if someone wants to apply a unit of work *atomically* (either all >>>>> modifications within that unit of work are applied, or none), what >>>>> alternatives exist? >>>>> >>>>>> - Remove the tree module: it doesn't work properly, and uses batching >>>>>> >>>>>> Please cast your votes >>>>>> >>>>>> Tristan >>>>>> >>>>> >>>> _______________________________________________ >>>> 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 From mudokonman at gmail.com Tue Feb 21 10:11:04 2017 From: mudokonman at gmail.com (William Burns) Date: Tue, 21 Feb 2017 15:11:04 +0000 Subject: [infinispan-dev] Cluster Executor failover and execution policy Message-ID: As many of you are may or may not be aware the ClusterExecutor interface and implementation were introduced into Infinispan 8.2 [1]. This class is a new API that can be used to submit commands to other nodes in a way similar to DistributedExecutor does while also not being tied to a cache. The first implementation of ClusterExecutor did not include a couple features that DistributedExecutor has. For this post I will concentrate on failover and execution policies. My plan is to introduce some API to Infinispan 9 to allow for ClusterExecutor to also offer these capabilities. The first change is that I wanted to add additional options to Execution Policies. The execution policy is used to limit sending messages to nodes based on their topology (site, rack & machine id). The old execution policy allowed for SAME_MACHINE, SAME_RACK, SAME_SITE and ALL. I plan on adding the opposite of the SAME and also supporting DIFFERENT_MACHINE, DIFFERENT_RACK and DIFFERENT_SITE in case if the user wants to ensure that data is processed elsewhere. Unless you think this is unneeded? The API changes I am thinking of are as below (included in email to allow for responses inline). Note that existing methods would be unchanged and thus submit and execute methods would be used to send commands still. One big difference is that I have not allowed for the user to control the failover node or the target node when doing a single submission with multiple available targets. In my mind if a user wants this they should do it themselves manually, but this is open for discussion as well. /** * When a command is submitted it will only be submitted to one node of the available nodes, there is no strict * requirements as to which node is chosen and is implementation specific. Fail over can be used with configuration, * please see {@link ClusterExecutor#failOverRetries(int)} for more information. * @return this executor again with commands submitted to a single node */ ClusterExecutor singleNodeSubmission(); /** * When a command is submitted it will submit this command to all of the available nodes. Fail over is not supported * with this configuration. This is the default submission method. * @return this executor again with commands submitted to all nodes */ ClusterExecutor allNodeSubmission(); /** * Enables fail over to occur when using {@link ClusterExecutor#singleNodeSubmission()}. If the executor * is not currently in the single node submission mode, this method will throw {@link IllegalStateException}. * When fail over count is applied, a submitted command will be retried up to that many times on the available * command up to desired amount of times until an exception is not met. The one exception that is not retried is a * TimeoutException since this could be related to {@link ClusterExecutor#timeout(long, TimeUnit)}. Each time the * fail over occurs a random node in the available nodes will be used (trying not to reuse the same node). * @param failOverCount how many times this executor will attempt a failover * @return this executor again with fail over retries applied * @throws IllegalStateException if this cluster executor is not currently configured for single node submission */ ClusterExecutor failOverRetries(int failOverCount) throws IllegalStateException; /** * Allows for filtering of address nodes by only allowing addresses that match the given execution policy to be used. * Note this method overrides any previous filtering that was done (ie. calling * {@link ClusterExecutor#filterTargets(Collection)}). * @param policy the policy to determine which nodes can be used * @return this executor again with the execution policy applied to determine which nodes are contacted */ ClusterExecutor filterTargets(ClusterExecutionPolicy policy); /** * Allows for filtering of address nodes dynamically per invocation. The predicate is applied to each member that * is part of the execution policy. Note that this method overrides any previous * filtering that was done (ie. calling {@link ClusterExecutor#filterTargets(Collection)}). * @param policy the execution policy applied before predicate to allow only nodes in that group * @param predicate the dynamic predicate applied each time an invocation is done * @return */ ClusterExecutor filterTargets(ClusterExecutionPolicy policy, Predicate predicate); Thanks for any input, - Will [1] https://github.com/infinispan/infinispan/blob/master/core/src/main/java/org/infinispan/manager/ClusterExecutor.java -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20170221/4eb4a9b7/attachment.html From sanne at infinispan.org Tue Feb 21 10:29:27 2017 From: sanne at infinispan.org (Sanne Grinovero) Date: Tue, 21 Feb 2017 15:29:27 +0000 Subject: [infinispan-dev] Major version cleaning In-Reply-To: References: <98a58d71-7daf-35c7-8e54-85735217a2d7@redhat.com> <16911ebf-a3c2-ab04-a615-03a19730aa13@redhat.com> <7c019da8-61b2-59d2-e671-aeca1f3fb7b6@infinispan.org> Message-ID: On 21 February 2017 at 13:20, Radim Vansa wrote: > On 02/21/2017 09:39 AM, Sanne Grinovero wrote: >> On 21 February 2017 at 07:37, Dan Berindei wrote: >>> On Mon, Feb 20, 2017 at 8:02 PM, Sanne Grinovero wrote: >>>> -1 to batch removal >>>> >>>> Frankly I've always been extremely negative about the fact that >>>> batches are built on top of transactions. It's easy to find several >>>> iterations of rants of mine on this mailing list, especially fierce >>>> debates with Mircea. So I'd welcome a separation of these features. >>>> >>>> Yet, removing batching seems very wrong. I disagree that people should >>>> use Transactions instead; for many use cases it's overkill, and for >>>> others - and this is the main pain point I always had with the current >>>> design - it might make sense to have a batch (or more than one) within >>>> a transaction. >>>> I have had practical problems with needing to "flush" a single batch >>>> within a transaction as the size of the combined elements was getting >>>> too large. That doesn't imply at all that I'm ready to commit. >>>> >>> WDYM by "flush" here? I have a feeling this is nothing like our >>> batching ever was... >> I'm just listing points about why incorporating the batch concept with >> transactions is not practical. >> >> I mean that when one has to write very large amounts of data, you need to >> break it up in smaller batches; *essentially* to flush the first batch before >> starting the second one. >> So that is unrelated with atomicity and consistency, as in practice one has >> to split one business operation into multiple batches. > > You haven't explained what "flush" means. Since you separate that from > atomicity/consistency, I assume that batches on non-tx cache are just > ordered putOrRemoveAll operations, immediately visible on flush without > any atomicity. If you want batches in transactions, you probably mean > that the changes are not visible until tx commits. So you are worried > that all data modified within this transaction won't fit into single > node memory? Or is there more to that? What's a "nested batch", then? > I could see some benefits in removing repeatable-reads cached values. Ok my bad, I thought "flush" was quite well understood as a concept but I guess you're right it deserves a bit of elaboration on a non-typical storage engine. In my mind, it means "make sure that buffers are sent to their destination", and this doesn't have to directly relate with a commit. I just want the data entry to be shipped over to the heap which will ultimately contain it. We have real use cases in various pieces of Infinispan code I wrote over the years in which we need to write to multiple keys. For the sake of example, let's use the Lucene Directory case, in which each Lucene chunk is encoded as 3 different Infinispan entries (let's not debate why or we get heavily out of topic, trust me that it's a reasonable example of a business use case - it's probably simpler than most other cases). So I want to write a first chunk, in our code that looks like: startBatch put(chunk1/A, [some large value]) put(chunk1/B, [some small metadata]) put(chunk1/C, [some small metadata]) endBatch There is no reason to use a transaction, in fact we had to disable transactions as some of these entries could be large. There also is no reason for the batch, other than optimising the latency. You also want to be able to write 2 chunks, and still be mindful for latency: startBatch put(chunk1/A,..) put(chunk1/B,..) put(chunk1/C,..) endBatch startBatch put(chunk2/A,..) put(chunk2/B,..) put(chunk2/C,..) endBatch Again, you don't want to combine entries from chunk1 with chunk2 as they are very large. The data belonging to chunk2 is not produced yet when we write chunk1, so the explict "flush" is helpful to keep the total used heap size beyond some treshold; chunk sizes are configurable. Also, it's not important among A,B,C in which order they are written, but we definitely want to make sure that no entry from chunk2 is visible before any entry of chunk1, so we prefer these batches to be separate and sequential. Finally, such operations are usually *internal* caused by some adaptation framework which could need to be coupled to user transactions. So you actually want to be able to do: - Start Tx1 startBatch put(chunk1/A,..) put(chunk1/B,..) put(chunk1/C,..) endBatch startBatch put(chunk2/A,..) put(chunk2/B,..) put(chunk2/C,..) endBatch - Commit Tx1 Which is a very reasonable expectation from anyone using a database, yet Infinispan can't do this as it would be "nesting". In the specific case of the Lucene Directory, I don't expect people to want to do this with transactions, and we definitely need an efficient way to do batching w/o having the performance penalty of transactions. Hibernate OGM would be a better example, of a framework which needs to write a sequence of (hopefully batched) operations, and wrap them all as a single Transaction. > >>>> @Pedro: the fact that some code is broken today is not relevant, when >>>> there's need for such features. Like you suggest, it had bad premises >>>> (build it on TX) so we should address that, but not throw it all out. >>>> >>> Infinispan never created nested batches: >> I know. I'm not describing the current implementation, I'm describing use >> cases which are not addressed, or in which Infinispan is clumsy to use, >> to suggest improvements. >> And I'm not asking to have nested batches. Again, just pointing >> out practical problems with the current batch design. >> >> It should be possible to run an efficient batch of operations within a >> transaction. >> Or a sequence of batches, all within the same transaction. >> N.B. you could see that as a "nested batch" in the current twisted idea that >> a batch is a transaction - which is what I'm arguing against. >> >> >>> calling startBatch() when a >>> batch was already associated with the current thread just incremented >>> a refcount, and only the final endBatch() did any work. OTOH running a >>> batch within a transaction always worked very much like suspending the >>> current transaction, starting a new one, and committing it on >>> endBatch(). So the only real difference between batching and using >>> DummyTransactionManager is that batching is limited to one cache's >>> operations, while DummyTransactionManager supports multiple resources. >>> >>> >>>> @Bela is making spot-on objections based on use cases, which need to >>>> be addressed in some way. The "atomical" operations still don't work >>>> right[1] in Infinispan and that's a big usability problem. >>>> >>> Batching never was about sending updates asynchronously. We have >>> putAllAsync() for that, which doesn't need transactions, and it's even >>> slightly more efficient without transactions. >> If you think this way, it sounds like you give no value to the application >> performance: people need more than a couple put operations. > > Removes? > > I am really asking out of curiosity, I hope these questions don't sound > ironically. > > R. > > >> >>> And atomical operations have bugs, yes, but I'm not sure how >>> implementing a new kind of batching that isn't based on transactions >>> would help with that. >>> >>> >>>> +1 to remove async TX >>>> >>>> I actually like the concept but the API should be different.. might as >>>> well remove this for now. >>>> >>>> +1 to remove the Tree module >>>> >>>> I personally never used it as you all advised against, yet it's been >>>> often requested by users; sometimes explicitly and others not so >>>> explicit, yet people often have need which would be solved by a good >>>> Tree module. >>>> I understand the reasons you all want to remove it: it's buggy. But I >>>> believe the real reason is that it should have been built on top of a >>>> proper batch API, and using real MVCC. In that case it wouldn't have >>>> been buggy, nor too hard to maintain, and might have attracted way >>>> more interest as well. >>> I think the fact that we haven't been able to build a "proper" batch >>> API using real MVCC yet is a proof to the contrary... >>> >>> >>>> I'd remove it as a temporary measure: delete the bad stuff, but >>>> hopefully it could be reintroduced built on better principles in some >>>> future? >>>> >>>> Thanks, >>>> Sanne >>>> >>>> [1] - "right" as in user expectations and actual practical use, which >>>> is currently different than in the twisted definition of "right" that >>>> the team has been using as an excuse ;-) I'll also proof that it >>>> doesn't work right according to your own twisted specs, when I find >>>> the time to finish some tests.. >>>> >>>> >>>> On 20 February 2017 at 16:48, Pedro Ruivo wrote: >>>>> >>>>> On 20-02-2017 16:12, Bela Ban wrote: >>>>>> >>>>>> On 20/02/17 17:06, Tristan Tarrant wrote: >>>>>>> Hi guys, we discussed about this a little bit in the past and this >>>>>>> morning on IRC. Here are some proposed removals: >>>>>>> >>>>>>> - Remove the async transactional modes, as they are quite pointless >>>>>>> - Remove batching: users should use transactions >>>>>> How do you make a bunch of modifications and send them asynchronously if >>>>>> both batching *and* async TXs are getting removed? >>>>> We are not removing features, we are removing broken code. >>>>> >>>>> Batching is using transactions and async transactions doesn't make sense >>>>> since infinispan has to report to TransactionManager. >>>>> >>>>> Our current asyn-tx is broken in a way that is starts to commit and >>>>> reports OK to the transaction manager. if you have a topology change or >>>>> a conflict, you will end with inconsistent data. >>>>> >>>>> So, why do we keeping this code around? >>>>> >>>>> you can still move a transaction commit to another thread if you don't >>>>> wanna wait for its commit: >>>>> >>>>> tm.begin() >>>>> doWork() >>>>> tx = tm.suspend() >>>>> new_thread { >>>>> tm.resume(tx) >>>>> tm.commit() >>>>> } >>>>> >>>>> The best thing I can think of is to keep the batching API and >>>>> re-implement it to provide an endBatchAsync() that will do the above. >>>>> >>>>>> So if someone wants to apply a unit of work *atomically* (either all >>>>>> modifications within that unit of work are applied, or none), what >>>>>> alternatives exist? >>>>>> >>>>>>> - Remove the tree module: it doesn't work properly, and uses batching >>>>>>> >>>>>>> Please cast your votes >>>>>>> >>>>>>> Tristan >>>>>>> >>>>> _______________________________________________ >>>>> 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 > > > -- > Radim Vansa > JBoss Performance Team > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev From vblagoje at redhat.com Tue Feb 21 10:31:52 2017 From: vblagoje at redhat.com (Vladimir Blagojevic) Date: Tue, 21 Feb 2017 10:31:52 -0500 Subject: [infinispan-dev] Cluster Executor failover and execution policy In-Reply-To: References: Message-ID: <5e9b2861-643b-7140-2d57-04c0c4959c7a@redhat.com> Will, I like the API proposal but one thing that jumps out for me is to combine or rather overload singleNodeSubmission with singleNodeSubmission(int failOverCount) and remove failoverRetries method. The first singleNodeSubmission does not failover while the second one does with the specified failOverCount. That way we don't have to keep state and throw IllegalStateException when someone erroneously calls failOverRetries. Vladimir On 2017-02-21 10:11 AM, William Burns wrote: > As many of you are may or may not be aware the ClusterExecutor > interface and implementation were introduced into Infinispan 8.2 [1]. > This class is a new API that can be used to submit commands to other > nodes in a way similar to DistributedExecutor does while also not > being tied to a cache. > > The first implementation of ClusterExecutor did not include a couple > features that DistributedExecutor has. For this post I will > concentrate on failover and execution policies. My plan is to > introduce some API to Infinispan 9 to allow for ClusterExecutor to > also offer these capabilities. > > The first change is that I wanted to add additional options to > Execution Policies. The execution policy is used to limit sending > messages to nodes based on their topology (site, rack & machine id). > The old execution policy allowed for SAME_MACHINE, SAME_RACK, > SAME_SITE and ALL. I plan on adding the opposite of the SAME and also > supporting DIFFERENT_MACHINE, DIFFERENT_RACK and DIFFERENT_SITE in > case if the user wants to ensure that data is processed elsewhere. > Unless you think this is unneeded? > > The API changes I am thinking of are as below (included in email to > allow for responses inline). Note that existing methods would be > unchanged and thus submit and execute methods would be used to send > commands still. One big difference is that I have not allowed for the > user to control the failover node or the target node when doing a > single submission with multiple available targets. In my mind if a > user wants this they should do it themselves manually, but this is > open for discussion as well. > > /** * When a command is submitted it will only be submitted to one > node of the available nodes, there is no strict * requirements as to > which node is chosen and is implementation specific. Fail over can be > used with configuration, * please see {@link > ClusterExecutor#failOverRetries(int)} for more information. * @return > this executor again with commands submitted to a single node */ ClusterExecutor singleNodeSubmission(); > > /** * When a command is submitted it will submit this command to all > of the available nodes. Fail over is not supported * with this > configuration. This is the default submission method. * @return this > executor again with commands submitted to all nodes */ ClusterExecutor allNodeSubmission(); > > /** * Enables fail over to occur when using {@link > ClusterExecutor#singleNodeSubmission()}. If the executor * is not > currently in the single node submission mode, this method will throw > {@link IllegalStateException}. * When fail over count is applied, a > submitted command will be retried up to that many times on the > available * command up to desired amount of times until an exception > is not met. The one exception that is not retried is a * > TimeoutException since this could be related to {@link > ClusterExecutor#timeout(long, TimeUnit)}. Each time the * fail over > occurs a random node in the available nodes will be used (trying not > to reuse the same node).* @param failOverCount how many times this > executor will attempt a failover * @return this executor again with > fail over retries applied * @throws IllegalStateException if this > cluster executor is not currently configured for single node > submission */ ClusterExecutor failOverRetries(int failOverCount)throws IllegalStateException; > > /** * Allows for filtering of address nodes by only allowing addresses > that match the given execution policy to be used. * Note this method > overrides any previous filtering that was done (ie. calling * {@link > ClusterExecutor#filterTargets(Collection)}). * @param policy the > policy to determine which nodes can be used * @return this executor > again with the execution policy applied to determine which nodes are > contacted */ ClusterExecutor filterTargets(ClusterExecutionPolicy policy); > > /** * Allows for filtering of address nodes dynamically per > invocation. The predicate is applied to each member that * is part of > the execution policy. Note that this method overrides any previous * > filtering that was done (ie. calling {@link > ClusterExecutor#filterTargets(Collection)}). * @param policy the > execution policy applied before predicate to allow only nodes in that > group * @param predicate the dynamic predicate applied each time an > invocation is done * @return */ ClusterExecutor filterTargets(ClusterExecutionPolicy policy, Predicate predicate); > > Thanks for any input, > > - Will > > [1] > https://github.com/infinispan/infinispan/blob/master/core/src/main/java/org/infinispan/manager/ClusterExecutor.java > > > > > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20170221/66ae664a/attachment.html From sanne at infinispan.org Tue Feb 21 10:36:02 2017 From: sanne at infinispan.org (Sanne Grinovero) Date: Tue, 21 Feb 2017 15:36:02 +0000 Subject: [infinispan-dev] Major version cleaning In-Reply-To: References: <98a58d71-7daf-35c7-8e54-85735217a2d7@redhat.com> <16911ebf-a3c2-ab04-a615-03a19730aa13@redhat.com> <7c019da8-61b2-59d2-e671-aeca1f3fb7b6@infinispan.org> Message-ID: On 21 February 2017 at 14:52, Dan Berindei wrote: > On Tue, Feb 21, 2017 at 10:39 AM, Sanne Grinovero wrote: >> On 21 February 2017 at 07:37, Dan Berindei wrote: >>> On Mon, Feb 20, 2017 at 8:02 PM, Sanne Grinovero wrote: >>>> -1 to batch removal >>>> >>>> Frankly I've always been extremely negative about the fact that >>>> batches are built on top of transactions. It's easy to find several >>>> iterations of rants of mine on this mailing list, especially fierce >>>> debates with Mircea. So I'd welcome a separation of these features. >>>> >>>> Yet, removing batching seems very wrong. I disagree that people should >>>> use Transactions instead; for many use cases it's overkill, and for >>>> others - and this is the main pain point I always had with the current >>>> design - it might make sense to have a batch (or more than one) within >>>> a transaction. >>>> I have had practical problems with needing to "flush" a single batch >>>> within a transaction as the size of the combined elements was getting >>>> too large. That doesn't imply at all that I'm ready to commit. >>>> >>> >>> WDYM by "flush" here? I have a feeling this is nothing like our >>> batching ever was... >> >> I'm just listing points about why incorporating the batch concept with >> transactions is not practical. >> >> I mean that when one has to write very large amounts of data, you need to >> break it up in smaller batches; *essentially* to flush the first batch before >> starting the second one. >> So that is unrelated with atomicity and consistency, as in practice one has >> to split one business operation into multiple batches. >> > > Kind of repeating Radim's question, but how is this better than having > multiple small transactions and committing each one separately? If you assume that code integrating with Infinispan is in control of the transaction boundaries - for example able to decide when it's time to commit - it implies you can not integrate with other transactional components. Which defeats the purpose of exposing JTA integration. > >>> >>>> @Pedro: the fact that some code is broken today is not relevant, when >>>> there's need for such features. Like you suggest, it had bad premises >>>> (build it on TX) so we should address that, but not throw it all out. >>>> >>> >>> Infinispan never created nested batches: >> >> I know. I'm not describing the current implementation, I'm describing use >> cases which are not addressed, or in which Infinispan is clumsy to use, >> to suggest improvements. >> And I'm not asking to have nested batches. Again, just pointing >> out practical problems with the current batch design. >> >> It should be possible to run an efficient batch of operations within a >> transaction. >> Or a sequence of batches, all within the same transaction. >> N.B. you could see that as a "nested batch" in the current twisted idea that >> a batch is a transaction - which is what I'm arguing against. >> > > I'm sure there there are use cases that we don't address properly, but > I don't know enough about those use cases or your proposed batching > API improvements to really say anything about them. The only thing I'm > confident about is that the current batching API is almost certainly > not the answer. > >> >>> calling startBatch() when a >>> batch was already associated with the current thread just incremented >>> a refcount, and only the final endBatch() did any work. OTOH running a >>> batch within a transaction always worked very much like suspending the >>> current transaction, starting a new one, and committing it on >>> endBatch(). So the only real difference between batching and using >>> DummyTransactionManager is that batching is limited to one cache's >>> operations, while DummyTransactionManager supports multiple resources. >>> >>> >>>> @Bela is making spot-on objections based on use cases, which need to >>>> be addressed in some way. The "atomical" operations still don't work >>>> right[1] in Infinispan and that's a big usability problem. >>>> >>> >>> Batching never was about sending updates asynchronously. We have >>> putAllAsync() for that, which doesn't need transactions, and it's even >>> slightly more efficient without transactions. >> >> If you think this way, it sounds like you give no value to the application >> performance: people need more than a couple put operations. >> > > Unfortunately, going beyond simple put operations, e.g. conditional > writes, is exactly where asynchronous replication fails. Even doing > simple put operations and making sure that those values are written to > the cache is an impossible task with asynchronous replication. > Considering that the batch methods are called startAtomic() and > endAtomic() in TreeCache, I really don't think they were created with > asynchronous replication in mind. > > Off-topic: The BatchingCache#startBatch() javadoc was never true for > distributed caches: writes are queued, but reads (or puts without > IGNORE_RETURN_VALUES) always result in a remote call. Locks cause > remote calls in a cache with pessimistic locking, too, although one > could argue that back in version 4.0, locks were indeed acquired > locally during the write and remotely at the end of the batch. > >>> >>> And atomical operations have bugs, yes, but I'm not sure how >>> implementing a new kind of batching that isn't based on transactions >>> would help with that. >>> >>> >>>> +1 to remove async TX >>>> >>>> I actually like the concept but the API should be different.. might as >>>> well remove this for now. >>>> >>>> +1 to remove the Tree module >>>> >>>> I personally never used it as you all advised against, yet it's been >>>> often requested by users; sometimes explicitly and others not so >>>> explicit, yet people often have need which would be solved by a good >>>> Tree module. >>>> I understand the reasons you all want to remove it: it's buggy. But I >>>> believe the real reason is that it should have been built on top of a >>>> proper batch API, and using real MVCC. In that case it wouldn't have >>>> been buggy, nor too hard to maintain, and might have attracted way >>>> more interest as well. >>> >>> I think the fact that we haven't been able to build a "proper" batch >>> API using real MVCC yet is a proof to the contrary... >>> >>> >>>> I'd remove it as a temporary measure: delete the bad stuff, but >>>> hopefully it could be reintroduced built on better principles in some >>>> future? >>>> >>>> Thanks, >>>> Sanne >>>> >>>> [1] - "right" as in user expectations and actual practical use, which >>>> is currently different than in the twisted definition of "right" that >>>> the team has been using as an excuse ;-) I'll also proof that it >>>> doesn't work right according to your own twisted specs, when I find >>>> the time to finish some tests.. >>>> >>>> >>>> On 20 February 2017 at 16:48, Pedro Ruivo wrote: >>>>> >>>>> >>>>> On 20-02-2017 16:12, Bela Ban wrote: >>>>>> >>>>>> >>>>>> On 20/02/17 17:06, Tristan Tarrant wrote: >>>>>>> Hi guys, we discussed about this a little bit in the past and this >>>>>>> morning on IRC. Here are some proposed removals: >>>>>>> >>>>>>> - Remove the async transactional modes, as they are quite pointless >>>>>>> - Remove batching: users should use transactions >>>>>> >>>>>> How do you make a bunch of modifications and send them asynchronously if >>>>>> both batching *and* async TXs are getting removed? >>>>> >>>>> We are not removing features, we are removing broken code. >>>>> >>>>> Batching is using transactions and async transactions doesn't make sense >>>>> since infinispan has to report to TransactionManager. >>>>> >>>>> Our current asyn-tx is broken in a way that is starts to commit and >>>>> reports OK to the transaction manager. if you have a topology change or >>>>> a conflict, you will end with inconsistent data. >>>>> >>>>> So, why do we keeping this code around? >>>>> >>>>> you can still move a transaction commit to another thread if you don't >>>>> wanna wait for its commit: >>>>> >>>>> tm.begin() >>>>> doWork() >>>>> tx = tm.suspend() >>>>> new_thread { >>>>> tm.resume(tx) >>>>> tm.commit() >>>>> } >>>>> >>>>> The best thing I can think of is to keep the batching API and >>>>> re-implement it to provide an endBatchAsync() that will do the above. >>>>> >>>>>> >>>>>> So if someone wants to apply a unit of work *atomically* (either all >>>>>> modifications within that unit of work are applied, or none), what >>>>>> alternatives exist? >>>>>> >>>>>>> - Remove the tree module: it doesn't work properly, and uses batching >>>>>>> >>>>>>> Please cast your votes >>>>>>> >>>>>>> Tristan >>>>>>> >>>>>> >>>>> _______________________________________________ >>>>> 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 From vblagoje at redhat.com Tue Feb 21 10:46:40 2017 From: vblagoje at redhat.com (Vladimir Blagojevic) Date: Tue, 21 Feb 2017 10:46:40 -0500 Subject: [infinispan-dev] JGroups 4.0 released In-Reply-To: References: <39155eaa-3268-aa31-9013-3e72087c1c06@redhat.com> Message-ID: <36ff6390-b1b0-8ded-b31c-08746f4b871a@redhat.com> Congratulations Bela. What a milestone! I was just counting - I can't believe it was almost 16 years ago that I first got introduced to JGroups. All the best, Vladimir On 2017-02-21 8:37 AM, Sanne Grinovero wrote: > Congratulations! > > On 21 Feb 2017 12:21, "Bela Ban" > wrote: > > FYI: http://belaban.blogspot.ch/2017/02/jgroups-400final.html > > > -- > Bela Ban, JGroups lead (http://www.jgroups.org) > > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20170221/1c45b1b7/attachment.html From mudokonman at gmail.com Tue Feb 21 10:54:25 2017 From: mudokonman at gmail.com (William Burns) Date: Tue, 21 Feb 2017 15:54:25 +0000 Subject: [infinispan-dev] Cluster Executor failover and execution policy In-Reply-To: <5e9b2861-643b-7140-2d57-04c0c4959c7a@redhat.com> References: <5e9b2861-643b-7140-2d57-04c0c4959c7a@redhat.com> Message-ID: On Tue, Feb 21, 2017 at 10:33 AM Vladimir Blagojevic wrote: > Will, > > I like the API proposal but one thing that jumps out for me is to combine > or rather overload singleNodeSubmission with singleNodeSubmission(int > failOverCount) and remove failoverRetries method. The first > singleNodeSubmission does not failover while the second one does with the > specified failOverCount. That way we don't have to keep state and throw > IllegalStateException when someone erroneously calls failOverRetries. > Sounds good to me. Not sure why I didn't think of that before. It felt awkward to me as well. Guess I was stuck on having the method have the name failover in it :) > > Vladimir > > > > On 2017-02-21 10:11 AM, William Burns wrote: > > As many of you are may or may not be aware the ClusterExecutor interface > and implementation were introduced into Infinispan 8.2 [1]. This class is > a new API that can be used to submit commands to other nodes in a way > similar to DistributedExecutor does while also not being tied to a cache. > > The first implementation of ClusterExecutor did not include a couple > features that DistributedExecutor has. For this post I will concentrate on > failover and execution policies. My plan is to introduce some API to > Infinispan 9 to allow for ClusterExecutor to also offer these capabilities. > > The first change is that I wanted to add additional options to Execution > Policies. The execution policy is used to limit sending messages to nodes > based on their topology (site, rack & machine id). The old execution > policy allowed for SAME_MACHINE, SAME_RACK, SAME_SITE and ALL. I plan on > adding the opposite of the SAME and also supporting DIFFERENT_MACHINE, > DIFFERENT_RACK and DIFFERENT_SITE in case if the user wants to ensure that > data is processed elsewhere. Unless you think this is unneeded? > > The API changes I am thinking of are as below (included in email to allow > for responses inline). Note that existing methods would be unchanged and > thus submit and execute methods would be used to send commands still. One > big difference is that I have not allowed for the user to control the > failover node or the target node when doing a single submission with > multiple available targets. In my mind if a user wants this they should do > it themselves manually, but this is open for discussion as well. > > /** * When a command is submitted it will only be submitted to one node of the available nodes, there is no strict * requirements as to which node is chosen and is implementation specific. Fail over can be used with configuration, * please see {@link ClusterExecutor#failOverRetries(int)} for more information. * @return this executor again with commands submitted to a single node */ClusterExecutor singleNodeSubmission(); > /** * When a command is submitted it will submit this command to all of the available nodes. Fail over is not supported * with this configuration. This is the default submission method. * @return this executor again with commands submitted to all nodes */ClusterExecutor allNodeSubmission(); > /** * Enables fail over to occur when using {@link ClusterExecutor#singleNodeSubmission()}. If the executor * is not currently in the single node submission mode, this method will throw {@link IllegalStateException}. * When fail over count is applied, a submitted command will be retried up to that many times on the available * command up to desired amount of times until an exception is not met. The one exception that is not retried is a * TimeoutException since this could be related to {@link ClusterExecutor#timeout(long, TimeUnit)}. Each time the * fail over occurs a random node in the available nodes will be used (trying not to reuse the same node). * @param failOverCount how many times this executor will attempt a failover * @return this executor again with fail over retries applied * @throws IllegalStateException if this cluster executor is not currently configured for single node submission */ClusterExecutor failOverRetries(int failOverCount) throws IllegalStateException; > /** * Allows for filtering of address nodes by only allowing addresses that match the given execution policy to be used. * Note this method overrides any previous filtering that was done (ie. calling * {@link ClusterExecutor#filterTargets(Collection)}). * @param policy the policy to determine which nodes can be used * @return this executor again with the execution policy applied to determine which nodes are contacted */ClusterExecutor filterTargets(ClusterExecutionPolicy policy); > /** * Allows for filtering of address nodes dynamically per invocation. The predicate is applied to each member that * is part of the execution policy. Note that this method overrides any previous * filtering that was done (ie. calling {@link ClusterExecutor#filterTargets(Collection)}). * @param policy the execution policy applied before predicate to allow only nodes in that group * @param predicate the dynamic predicate applied each time an invocation is done * @return */ClusterExecutor filterTargets(ClusterExecutionPolicy policy, Predicate predicate); > > > Thanks for any input, > > - Will > > [1] > https://github.com/infinispan/infinispan/blob/master/core/src/main/java/org/infinispan/manager/ClusterExecutor.java > > > > > > > _______________________________________________ > infinispan-dev mailing listinfinispan-dev at lists.jboss.orghttps://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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20170221/ca738bc3/attachment-0001.html From ttarrant at redhat.com Tue Feb 21 11:01:50 2017 From: ttarrant at redhat.com (Tristan Tarrant) Date: Tue, 21 Feb 2017 17:01:50 +0100 Subject: [infinispan-dev] JGroups 4.0 released In-Reply-To: <39155eaa-3268-aa31-9013-3e72087c1c06@redhat.com> References: <39155eaa-3268-aa31-9013-3e72087c1c06@redhat.com> Message-ID: <2a346c29-1ea1-e445-03e9-a8648b71e3eb@redhat.com> Nice one Bela ! Tristan On 21/02/17 13:21, Bela Ban wrote: > FYI: http://belaban.blogspot.ch/2017/02/jgroups-400final.html > -- Tristan Tarrant Infinispan Lead JBoss, a division of Red Hat From ttarrant at redhat.com Tue Feb 21 11:16:37 2017 From: ttarrant at redhat.com (Tristan Tarrant) Date: Tue, 21 Feb 2017 17:16:37 +0100 Subject: [infinispan-dev] Major version cleaning In-Reply-To: References: <98a58d71-7daf-35c7-8e54-85735217a2d7@redhat.com> <16911ebf-a3c2-ab04-a615-03a19730aa13@redhat.com> <7c019da8-61b2-59d2-e671-aeca1f3fb7b6@infinispan.org> Message-ID: On 21/02/17 16:29, Sanne Grinovero wrote: >> You haven't explained what "flush" means. Since you separate that from >> atomicity/consistency, I assume that batches on non-tx cache are just >> ordered putOrRemoveAll operations, immediately visible on flush without >> any atomicity. I assume that in Sanne's idea, ordering in a batch doesn't matter, aside from operations on the same key. Having ordering in there would for example not allow us to parallelize by segment. > So I want to write a first chunk, in our code that looks like: > > startBatch > put(chunk1/A, [some large value]) > put(chunk1/B, [some small metadata]) > put(chunk1/C, [some small metadata]) > endBatch > There is no reason to use a transaction, in fact we had to disable > transactions as some of these entries could be large. > There also is no reason for the batch, other than optimising the latency. Let me summarize to see if we have the requirements for a useful batching system (which is sort of patterned on the JDBC statement batching): - a batch is not an atomic operation, i.e. it is not backed by a transaction - it can be wrapped in a transaction if needed - batches cannot be nested - batches only involve unconditional write operations (put, putAll, remove) - ordering of operations within a batch is unimportant aside from modifications to the same key where we apply "last one wins" - when a batch is "flushed" (i.e. endBatch is invoked) the ops are grouped by segment and sent to the appropriate owner for processing, potentially in parallel As Radim has called it, this is essentially a putOrRemoveAll op (with an async counterpart). Is that summary correct ? Tristan -- Tristan Tarrant Infinispan Lead JBoss, a division of Red Hat From bban at redhat.com Tue Feb 21 11:18:38 2017 From: bban at redhat.com (Bela Ban) Date: Tue, 21 Feb 2017 17:18:38 +0100 Subject: [infinispan-dev] JGroups 4.0 released In-Reply-To: <36ff6390-b1b0-8ded-b31c-08746f4b871a@redhat.com> References: <39155eaa-3268-aa31-9013-3e72087c1c06@redhat.com> <36ff6390-b1b0-8ded-b31c-08746f4b871a@redhat.com> Message-ID: On 21/02/17 16:46, Vladimir Blagojevic wrote: > Congratulations Bela. What a milestone! Thanks! > I was just counting - I can't believe it was almost 16 years ago that I > first got introduced to JGroups. Wow, you've been around for a long time already! :-) > All the best, > Vladimir > > On 2017-02-21 8:37 AM, Sanne Grinovero wrote: >> Congratulations! >> >> On 21 Feb 2017 12:21, "Bela Ban" > > wrote: >> >> FYI: http://belaban.blogspot.ch/2017/02/jgroups-400final.html >> >> >> -- >> Bela Ban, JGroups lead (http://www.jgroups.org) >> >> _______________________________________________ >> 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 > -- Bela Ban, JGroups lead (http://www.jgroups.org) From sanne at infinispan.org Tue Feb 21 11:59:53 2017 From: sanne at infinispan.org (Sanne Grinovero) Date: Tue, 21 Feb 2017 16:59:53 +0000 Subject: [infinispan-dev] Major version cleaning In-Reply-To: References: <98a58d71-7daf-35c7-8e54-85735217a2d7@redhat.com> <16911ebf-a3c2-ab04-a615-03a19730aa13@redhat.com> <7c019da8-61b2-59d2-e671-aeca1f3fb7b6@infinispan.org> Message-ID: On 21 February 2017 at 16:16, Tristan Tarrant wrote: > On 21/02/17 16:29, Sanne Grinovero wrote: >>> You haven't explained what "flush" means. Since you separate that from >>> atomicity/consistency, I assume that batches on non-tx cache are just >>> ordered putOrRemoveAll operations, immediately visible on flush without >>> any atomicity. > > I assume that in Sanne's idea, ordering in a batch doesn't matter, aside > from operations on the same key. Having ordering in there would for > example not allow us to parallelize by segment. > >> So I want to write a first chunk, in our code that looks like: >> >> startBatch >> put(chunk1/A, [some large value]) >> put(chunk1/B, [some small metadata]) >> put(chunk1/C, [some small metadata]) >> endBatch >> There is no reason to use a transaction, in fact we had to disable >> transactions as some of these entries could be large. >> There also is no reason for the batch, other than optimising the latency. > Let me summarize to see if we have the requirements for a useful > batching system (which is sort of patterned on the JDBC statement batching): > > - a batch is not an atomic operation, i.e. it is not backed by a transaction > - it can be wrapped in a transaction if needed > - batches cannot be nested > - batches only involve unconditional write operations (put, putAll, remove) > - ordering of operations within a batch is unimportant aside from > modifications to the same key where we apply "last one wins" > - when a batch is "flushed" (i.e. endBatch is invoked) the ops are > grouped by segment and sent to the appropriate owner for processing, > potentially in parallel > > As Radim has called it, this is essentially a putOrRemoveAll op (with an > async counterpart). > > Is that summary correct ? Yes! Thanks BTW I don't fully subscribe that conditional operations shouldn't be considered, but I'm happy to keep that pandora box for another time. Remember optimistic transactions are useful in some cases. > > Tristan > -- > Tristan Tarrant > Infinispan Lead > JBoss, a division of Red Hat > _______________________________________________ > infinispan-dev mailing list > infinispan-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev From dan.berindei at gmail.com Tue Feb 21 12:30:52 2017 From: dan.berindei at gmail.com (Dan Berindei) Date: Tue, 21 Feb 2017 19:30:52 +0200 Subject: [infinispan-dev] Major version cleaning In-Reply-To: References: <98a58d71-7daf-35c7-8e54-85735217a2d7@redhat.com> <16911ebf-a3c2-ab04-a615-03a19730aa13@redhat.com> <7c019da8-61b2-59d2-e671-aeca1f3fb7b6@infinispan.org> Message-ID: On Tue, Feb 21, 2017 at 5:36 PM, Sanne Grinovero wrote: > On 21 February 2017 at 14:52, Dan Berindei wrote: >> On Tue, Feb 21, 2017 at 10:39 AM, Sanne Grinovero wrote: >>> On 21 February 2017 at 07:37, Dan Berindei wrote: >>>> On Mon, Feb 20, 2017 at 8:02 PM, Sanne Grinovero wrote: >>>>> -1 to batch removal >>>>> >>>>> Frankly I've always been extremely negative about the fact that >>>>> batches are built on top of transactions. It's easy to find several >>>>> iterations of rants of mine on this mailing list, especially fierce >>>>> debates with Mircea. So I'd welcome a separation of these features. >>>>> >>>>> Yet, removing batching seems very wrong. I disagree that people should >>>>> use Transactions instead; for many use cases it's overkill, and for >>>>> others - and this is the main pain point I always had with the current >>>>> design - it might make sense to have a batch (or more than one) within >>>>> a transaction. >>>>> I have had practical problems with needing to "flush" a single batch >>>>> within a transaction as the size of the combined elements was getting >>>>> too large. That doesn't imply at all that I'm ready to commit. >>>>> >>>> >>>> WDYM by "flush" here? I have a feeling this is nothing like our >>>> batching ever was... >>> >>> I'm just listing points about why incorporating the batch concept with >>> transactions is not practical. >>> >>> I mean that when one has to write very large amounts of data, you need to >>> break it up in smaller batches; *essentially* to flush the first batch before >>> starting the second one. >>> So that is unrelated with atomicity and consistency, as in practice one has >>> to split one business operation into multiple batches. >>> >> >> Kind of repeating Radim's question, but how is this better than having >> multiple small transactions and committing each one separately? > > If you assume that code integrating with Infinispan is in control of > the transaction boundaries - for example able to decide when it's time > to commit - it implies you can not integrate with other transactional > components. > > Which defeats the purpose of exposing JTA integration. > I was assuming that we can suspend the current JTA transaction, start and commit a new transaction, then resume the pre-existing transaction. Dan From ttarrant at redhat.com Tue Feb 21 12:37:18 2017 From: ttarrant at redhat.com (Tristan Tarrant) Date: Tue, 21 Feb 2017 18:37:18 +0100 Subject: [infinispan-dev] Major version cleaning In-Reply-To: References: <98a58d71-7daf-35c7-8e54-85735217a2d7@redhat.com> <16911ebf-a3c2-ab04-a615-03a19730aa13@redhat.com> <7c019da8-61b2-59d2-e671-aeca1f3fb7b6@infinispan.org> Message-ID: On 21/02/17 17:59, Sanne Grinovero wrote: > On 21 February 2017 at 16:16, Tristan Tarrant wrote: >> On 21/02/17 16:29, Sanne Grinovero wrote: >>>> You haven't explained what "flush" means. Since you separate that from >>>> atomicity/consistency, I assume that batches on non-tx cache are just >>>> ordered putOrRemoveAll operations, immediately visible on flush without >>>> any atomicity. >> >> I assume that in Sanne's idea, ordering in a batch doesn't matter, aside >> from operations on the same key. Having ordering in there would for >> example not allow us to parallelize by segment. >> >>> So I want to write a first chunk, in our code that looks like: >>> >>> startBatch >>> put(chunk1/A, [some large value]) >>> put(chunk1/B, [some small metadata]) >>> put(chunk1/C, [some small metadata]) >>> endBatch >>> There is no reason to use a transaction, in fact we had to disable >>> transactions as some of these entries could be large. >>> There also is no reason for the batch, other than optimising the latency. >> Let me summarize to see if we have the requirements for a useful >> batching system (which is sort of patterned on the JDBC statement batching): >> >> - a batch is not an atomic operation, i.e. it is not backed by a transaction >> - it can be wrapped in a transaction if needed >> - batches cannot be nested >> - batches only involve unconditional write operations (put, putAll, remove) >> - ordering of operations within a batch is unimportant aside from >> modifications to the same key where we apply "last one wins" >> - when a batch is "flushed" (i.e. endBatch is invoked) the ops are >> grouped by segment and sent to the appropriate owner for processing, >> potentially in parallel >> >> As Radim has called it, this is essentially a putOrRemoveAll op (with an >> async counterpart). >> >> Is that summary correct ? > > Yes! Thanks > > BTW I don't fully subscribe that conditional operations shouldn't be > considered, but I'm happy to keep that pandora box for another time. > Remember optimistic transactions are useful in some cases. Why I thought that putIfAbsent might not be appropriate I don't know. It makes perfect sense. Even the replace ops. -- Tristan Tarrant Infinispan Lead JBoss, a division of Red Hat From rvansa at redhat.com Tue Feb 21 12:55:23 2017 From: rvansa at redhat.com (Radim Vansa) Date: Tue, 21 Feb 2017 18:55:23 +0100 Subject: [infinispan-dev] Major version cleaning In-Reply-To: References: <98a58d71-7daf-35c7-8e54-85735217a2d7@redhat.com> <16911ebf-a3c2-ab04-a615-03a19730aa13@redhat.com> <7c019da8-61b2-59d2-e671-aeca1f3fb7b6@infinispan.org> Message-ID: <35ac9568-2297-bf4e-dc29-ad62d7888322@redhat.com> On 02/21/2017 05:16 PM, Tristan Tarrant wrote: > On 21/02/17 16:29, Sanne Grinovero wrote: >>> You haven't explained what "flush" means. Since you separate that from >>> atomicity/consistency, I assume that batches on non-tx cache are just >>> ordered putOrRemoveAll operations, immediately visible on flush without >>> any atomicity. > I assume that in Sanne's idea, ordering in a batch doesn't matter, aside > from operations on the same key. Having ordering in there would for > example not allow us to parallelize by segment. > >> So I want to write a first chunk, in our code that looks like: >> >> startBatch >> put(chunk1/A, [some large value]) >> put(chunk1/B, [some small metadata]) >> put(chunk1/C, [some small metadata]) >> endBatch >> There is no reason to use a transaction, in fact we had to disable >> transactions as some of these entries could be large. >> There also is no reason for the batch, other than optimising the latency. > Let me summarize to see if we have the requirements for a useful > batching system (which is sort of patterned on the JDBC statement batching): > > - a batch is not an atomic operation, i.e. it is not backed by a transaction > - it can be wrapped in a transaction if needed > - batches cannot be nested > - batches only involve unconditional write operations (put, putAll, remove) > - ordering of operations within a batch is unimportant aside from > modifications to the same key where we apply "last one wins" > - when a batch is "flushed" (i.e. endBatch is invoked) the ops are > grouped by segment and sent to the appropriate owner for processing, > potentially in parallel > > As Radim has called it, this is essentially a putOrRemoveAll op (with an > async counterpart). It is putOrRemoveAll when applied on a non-tx cache, and actually implementing that shouldn't be complex. However, when transactions come into play, it is different, because Sanne wants us to remove the modifications in completed batch from the local transactional invocation context and 'cache' them on the owners. Since reads have to be transactionally consistent, we need to inspect the transaction on the remote nodes (remote repeatable read). Sanne's request makes sense to me. However as the current implementation is providing a false assumption that it could work as JDBC batches while it's nothing but crippled JTA, and as I don't see anyone shouting "I'll implement that, next week it's done!", I second deprecating/removing the API for the time being. I don't find the current API ideal either, as it depends on thread locals (JTA does as well, but...) while it does not seem useful enough to me. I would prefer interface BatchingCache { Batch start(); } @NotThreadSafe interface Batch { void put(K k, V value); ... void execute(); void drop(); // maybe not needed } Radim > > Is that summary correct ? > > Tristan -- Radim Vansa JBoss Performance Team From slaskawi at redhat.com Tue Feb 21 13:08:43 2017 From: slaskawi at redhat.com (Sebastian Laskawiec) Date: Tue, 21 Feb 2017 18:08:43 +0000 Subject: [infinispan-dev] Martin Ribaric -- Migration of Infinispan OData server In-Reply-To: <4105715.25177213.1487684752977.JavaMail.zimbra@redhat.com> References: <798061185.25172176.1487684097320.JavaMail.zimbra@redhat.com> <4105715.25177213.1487684752977.JavaMail.zimbra@redhat.com> Message-ID: Hey guys! I've briefly looked through the code and Apache Olingo. It looks very interesting! As far as I can see the project has been designed to be deployed on Tomcat and use Infinispan Embedded. For me the more interesting usecase would be to make it available on Infinispan Server (just like REST or Memcached support). But I realized that we have zero support for this kind of custom plugins (extensions or data format providers I should say? It's hard to find a good word for that). Just thinking out laud - maybe the scope of the project should be larger? Maybe the proper way of doing this is developing an SPI for deploying custom 'server extensions' (perhaps as WARs) and implementing OData support as a proof of service? But regardless what I've just said, Ribari?, Tomas, great work! Keep it up! Thanks, Sebastian On Tue, Feb 21, 2017 at 2:46 PM Tomas Sykora wrote: > Hello everyone :) > I am enclosing Martin's email and sending it from my email address because > he sent it twice already and we can't see his emails from his gmail address > for whatever strange reason here. Martin is CCed, hopefully will receive > all reactions from this thread, please make sure you include him in CC > while replying :) > Thank you! > ----------------- > > Hello Infinispan community, > let me introduce myself shortly, my name is Martin Ribari? and I studied > Masaryk University ? Faculty of Informatics in Brno. I wrote my bachelor > thesis on topic: Migration of Infinispan OData server. I would like to tell > you a few words about my work. > > The primary goal of my bachelor thesis was to develop/migrate a new > solution of OData service for Infinispan. New solution is needed, because > old solution was developed using odata4j library and development of this > library was kind of stopped. New solution of OData service is offered by > project Apache Olingo. In my work, I've created a servlet for Infinispan > cache using Apache Olingo library support for OData v4. > We can put, get, manage and most importantly also query JSON documents in > the cache. Querying is possible on basic key value or a property of JSON > document. Also, in queries, we can use operations AND, OR, EQUALS and > operations for reduction of a response list: SKIP and TOP. > > Source code of my bachelor thesis is available at: > https://github.com/marib15/OlingoInfinispan-server > > Tomas Sykora will review my code and push my solution to > https://github.com/infinispan/infinispan-odata-server master soon. > > If community will have an interest, we can have a plan to continue in > development, so that server supports more operations... and also do > performance testing. > I know the solution is definitely not perfect but can definitely serve as > a baseline for future work, adjustments or adoption. > > I am looking forward to hearing your responses! > Have a nice day :) > Ribari? > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20170221/02f99ebd/attachment.html From dan.berindei at gmail.com Tue Feb 21 13:14:12 2017 From: dan.berindei at gmail.com (Dan Berindei) Date: Tue, 21 Feb 2017 20:14:12 +0200 Subject: [infinispan-dev] Major version cleaning In-Reply-To: <35ac9568-2297-bf4e-dc29-ad62d7888322@redhat.com> References: <98a58d71-7daf-35c7-8e54-85735217a2d7@redhat.com> <16911ebf-a3c2-ab04-a615-03a19730aa13@redhat.com> <7c019da8-61b2-59d2-e671-aeca1f3fb7b6@infinispan.org> <35ac9568-2297-bf4e-dc29-ad62d7888322@redhat.com> Message-ID: But doesn't the functional API's evalMany() provide something very close to the API you're suggesting? Dan On Tue, Feb 21, 2017 at 7:55 PM, Radim Vansa wrote: > On 02/21/2017 05:16 PM, Tristan Tarrant wrote: >> On 21/02/17 16:29, Sanne Grinovero wrote: >>>> You haven't explained what "flush" means. Since you separate that from >>>> atomicity/consistency, I assume that batches on non-tx cache are just >>>> ordered putOrRemoveAll operations, immediately visible on flush without >>>> any atomicity. >> I assume that in Sanne's idea, ordering in a batch doesn't matter, aside >> from operations on the same key. Having ordering in there would for >> example not allow us to parallelize by segment. >> >>> So I want to write a first chunk, in our code that looks like: >>> >>> startBatch >>> put(chunk1/A, [some large value]) >>> put(chunk1/B, [some small metadata]) >>> put(chunk1/C, [some small metadata]) >>> endBatch >>> There is no reason to use a transaction, in fact we had to disable >>> transactions as some of these entries could be large. >>> There also is no reason for the batch, other than optimising the latency. >> Let me summarize to see if we have the requirements for a useful >> batching system (which is sort of patterned on the JDBC statement batching): >> >> - a batch is not an atomic operation, i.e. it is not backed by a transaction >> - it can be wrapped in a transaction if needed >> - batches cannot be nested >> - batches only involve unconditional write operations (put, putAll, remove) >> - ordering of operations within a batch is unimportant aside from >> modifications to the same key where we apply "last one wins" >> - when a batch is "flushed" (i.e. endBatch is invoked) the ops are >> grouped by segment and sent to the appropriate owner for processing, >> potentially in parallel >> >> As Radim has called it, this is essentially a putOrRemoveAll op (with an >> async counterpart). > > It is putOrRemoveAll when applied on a non-tx cache, and actually > implementing that shouldn't be complex. However, when transactions come > into play, it is different, because Sanne wants us to remove the > modifications in completed batch from the local transactional invocation > context and 'cache' them on the owners. Since reads have to be > transactionally consistent, we need to inspect the transaction on the > remote nodes (remote repeatable read). > > Sanne's request makes sense to me. However as the current implementation > is providing a false assumption that it could work as JDBC batches while > it's nothing but crippled JTA, and as I don't see anyone shouting "I'll > implement that, next week it's done!", I second deprecating/removing the > API for the time being. > Exactly my thoughts, it's definitely not an unreasonable request, but it would require a lot of work to implement correctly. > I don't find the current API ideal either, as it depends on thread > locals (JTA does as well, but...) while it does not seem useful enough > to me. I would prefer > > interface BatchingCache { > Batch start(); > } > > @NotThreadSafe > interface Batch { > void put(K k, V value); > ... > void execute(); > void drop(); // maybe not needed > } > I was hoping the functional API's evalMany() would be good enough, but I see now that it replicates the function argument (which holds all the values) everywhere. So putAll() is still more efficient, unless using groups to make sure all keys in the batch have the same owners. Dan From rvansa at redhat.com Tue Feb 21 13:28:43 2017 From: rvansa at redhat.com (Radim Vansa) Date: Tue, 21 Feb 2017 19:28:43 +0100 Subject: [infinispan-dev] Major version cleaning In-Reply-To: References: <98a58d71-7daf-35c7-8e54-85735217a2d7@redhat.com> <16911ebf-a3c2-ab04-a615-03a19730aa13@redhat.com> <7c019da8-61b2-59d2-e671-aeca1f3fb7b6@infinispan.org> <35ac9568-2297-bf4e-dc29-ad62d7888322@redhat.com> Message-ID: <7c7f128e-2eec-62bf-c516-87540801a690@redhat.com> On 02/21/2017 07:14 PM, Dan Berindei wrote: > But doesn't the functional API's evalMany() provide something very > close to the API you're suggesting? > > Dan > > > On Tue, Feb 21, 2017 at 7:55 PM, Radim Vansa wrote: >> On 02/21/2017 05:16 PM, Tristan Tarrant wrote: >>> On 21/02/17 16:29, Sanne Grinovero wrote: >>>>> You haven't explained what "flush" means. Since you separate that from >>>>> atomicity/consistency, I assume that batches on non-tx cache are just >>>>> ordered putOrRemoveAll operations, immediately visible on flush without >>>>> any atomicity. >>> I assume that in Sanne's idea, ordering in a batch doesn't matter, aside >>> from operations on the same key. Having ordering in there would for >>> example not allow us to parallelize by segment. >>> >>>> So I want to write a first chunk, in our code that looks like: >>>> >>>> startBatch >>>> put(chunk1/A, [some large value]) >>>> put(chunk1/B, [some small metadata]) >>>> put(chunk1/C, [some small metadata]) >>>> endBatch >>>> There is no reason to use a transaction, in fact we had to disable >>>> transactions as some of these entries could be large. >>>> There also is no reason for the batch, other than optimising the latency. >>> Let me summarize to see if we have the requirements for a useful >>> batching system (which is sort of patterned on the JDBC statement batching): >>> >>> - a batch is not an atomic operation, i.e. it is not backed by a transaction >>> - it can be wrapped in a transaction if needed >>> - batches cannot be nested >>> - batches only involve unconditional write operations (put, putAll, remove) >>> - ordering of operations within a batch is unimportant aside from >>> modifications to the same key where we apply "last one wins" >>> - when a batch is "flushed" (i.e. endBatch is invoked) the ops are >>> grouped by segment and sent to the appropriate owner for processing, >>> potentially in parallel >>> >>> As Radim has called it, this is essentially a putOrRemoveAll op (with an >>> async counterpart). >> It is putOrRemoveAll when applied on a non-tx cache, and actually >> implementing that shouldn't be complex. However, when transactions come >> into play, it is different, because Sanne wants us to remove the >> modifications in completed batch from the local transactional invocation >> context and 'cache' them on the owners. Since reads have to be >> transactionally consistent, we need to inspect the transaction on the >> remote nodes (remote repeatable read). >> >> Sanne's request makes sense to me. However as the current implementation >> is providing a false assumption that it could work as JDBC batches while >> it's nothing but crippled JTA, and as I don't see anyone shouting "I'll >> implement that, next week it's done!", I second deprecating/removing the >> API for the time being. >> > Exactly my thoughts, it's definitely not an unreasonable request, but > it would require a lot of work to implement correctly. > > >> I don't find the current API ideal either, as it depends on thread >> locals (JTA does as well, but...) while it does not seem useful enough >> to me. I would prefer >> >> interface BatchingCache { >> Batch start(); >> } >> >> @NotThreadSafe >> interface Batch { >> void put(K k, V value); >> ... >> void execute(); >> void drop(); // maybe not needed >> } >> > I was hoping the functional API's evalMany() would be good enough, but > I see now that it replicates the function argument (which holds all > the values) everywhere. So putAll() is still more efficient, unless > using groups to make sure all keys in the batch have the same owners. Uh, doesn't putAll do the same? Is the modifications list isolate per target segments when replicating? R. > > Dan > _______________________________________________ > infinispan-dev mailing list > infinispan-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Radim Vansa JBoss Performance Team From dan.berindei at gmail.com Wed Feb 22 03:11:55 2017 From: dan.berindei at gmail.com (Dan Berindei) Date: Wed, 22 Feb 2017 10:11:55 +0200 Subject: [infinispan-dev] Major version cleaning In-Reply-To: <7c7f128e-2eec-62bf-c516-87540801a690@redhat.com> References: <98a58d71-7daf-35c7-8e54-85735217a2d7@redhat.com> <16911ebf-a3c2-ab04-a615-03a19730aa13@redhat.com> <7c019da8-61b2-59d2-e671-aeca1f3fb7b6@infinispan.org> <35ac9568-2297-bf4e-dc29-ad62d7888322@redhat.com> <7c7f128e-2eec-62bf-c516-87540801a690@redhat.com> Message-ID: On Tue, Feb 21, 2017 at 8:28 PM, Radim Vansa wrote: > On 02/21/2017 07:14 PM, Dan Berindei wrote: >> But doesn't the functional API's evalMany() provide something very >> close to the API you're suggesting? >> >> Dan >> >> >> On Tue, Feb 21, 2017 at 7:55 PM, Radim Vansa wrote: >>> On 02/21/2017 05:16 PM, Tristan Tarrant wrote: >>>> On 21/02/17 16:29, Sanne Grinovero wrote: >>>>>> You haven't explained what "flush" means. Since you separate that from >>>>>> atomicity/consistency, I assume that batches on non-tx cache are just >>>>>> ordered putOrRemoveAll operations, immediately visible on flush without >>>>>> any atomicity. >>>> I assume that in Sanne's idea, ordering in a batch doesn't matter, aside >>>> from operations on the same key. Having ordering in there would for >>>> example not allow us to parallelize by segment. >>>> >>>>> So I want to write a first chunk, in our code that looks like: >>>>> >>>>> startBatch >>>>> put(chunk1/A, [some large value]) >>>>> put(chunk1/B, [some small metadata]) >>>>> put(chunk1/C, [some small metadata]) >>>>> endBatch >>>>> There is no reason to use a transaction, in fact we had to disable >>>>> transactions as some of these entries could be large. >>>>> There also is no reason for the batch, other than optimising the latency. >>>> Let me summarize to see if we have the requirements for a useful >>>> batching system (which is sort of patterned on the JDBC statement batching): >>>> >>>> - a batch is not an atomic operation, i.e. it is not backed by a transaction >>>> - it can be wrapped in a transaction if needed >>>> - batches cannot be nested >>>> - batches only involve unconditional write operations (put, putAll, remove) >>>> - ordering of operations within a batch is unimportant aside from >>>> modifications to the same key where we apply "last one wins" >>>> - when a batch is "flushed" (i.e. endBatch is invoked) the ops are >>>> grouped by segment and sent to the appropriate owner for processing, >>>> potentially in parallel >>>> >>>> As Radim has called it, this is essentially a putOrRemoveAll op (with an >>>> async counterpart). >>> It is putOrRemoveAll when applied on a non-tx cache, and actually >>> implementing that shouldn't be complex. However, when transactions come >>> into play, it is different, because Sanne wants us to remove the >>> modifications in completed batch from the local transactional invocation >>> context and 'cache' them on the owners. Since reads have to be >>> transactionally consistent, we need to inspect the transaction on the >>> remote nodes (remote repeatable read). >>> >>> Sanne's request makes sense to me. However as the current implementation >>> is providing a false assumption that it could work as JDBC batches while >>> it's nothing but crippled JTA, and as I don't see anyone shouting "I'll >>> implement that, next week it's done!", I second deprecating/removing the >>> API for the time being. >>> >> Exactly my thoughts, it's definitely not an unreasonable request, but >> it would require a lot of work to implement correctly. >> >> >>> I don't find the current API ideal either, as it depends on thread >>> locals (JTA does as well, but...) while it does not seem useful enough >>> to me. I would prefer >>> >>> interface BatchingCache { >>> Batch start(); >>> } >>> >>> @NotThreadSafe >>> interface Batch { >>> void put(K k, V value); >>> ... >>> void execute(); >>> void drop(); // maybe not needed >>> } >>> >> I was hoping the functional API's evalMany() would be good enough, but >> I see now that it replicates the function argument (which holds all >> the values) everywhere. So putAll() is still more efficient, unless >> using groups to make sure all keys in the batch have the same owners. > > Uh, doesn't putAll do the same? Is the modifications list isolate per > target segments when replicating? > I missed the evalMany(Map, BiFunction) overload yesterday, and I assume WriteOnlyMap.evalMany(Map, MarshallableFunctions.setValueConsumer()) would behave exactly the same as putAll(Map). Of course, it's not better either, as you still have to create the map beforehand... OTOH I'm pretty sure you're the one who wrote the code to split the input keys/values by target segments both for putAll() and for evalMany() in NonTxDistributionInterceptor :) Dan From rvansa at redhat.com Wed Feb 22 03:53:53 2017 From: rvansa at redhat.com (Radim Vansa) Date: Wed, 22 Feb 2017 09:53:53 +0100 Subject: [infinispan-dev] Major version cleaning In-Reply-To: References: <98a58d71-7daf-35c7-8e54-85735217a2d7@redhat.com> <16911ebf-a3c2-ab04-a615-03a19730aa13@redhat.com> <7c019da8-61b2-59d2-e671-aeca1f3fb7b6@infinispan.org> <35ac9568-2297-bf4e-dc29-ad62d7888322@redhat.com> <7c7f128e-2eec-62bf-c516-87540801a690@redhat.com> Message-ID: <84e0313a-f2a5-f021-2bf0-5b08d4feb57e@redhat.com> On 02/22/2017 09:11 AM, Dan Berindei wrote: > On Tue, Feb 21, 2017 at 8:28 PM, Radim Vansa wrote: >> On 02/21/2017 07:14 PM, Dan Berindei wrote: >>> But doesn't the functional API's evalMany() provide something very >>> close to the API you're suggesting? >>> >>> Dan >>> >>> >>> On Tue, Feb 21, 2017 at 7:55 PM, Radim Vansa wrote: >>>> On 02/21/2017 05:16 PM, Tristan Tarrant wrote: >>>>> On 21/02/17 16:29, Sanne Grinovero wrote: >>>>>>> You haven't explained what "flush" means. Since you separate that from >>>>>>> atomicity/consistency, I assume that batches on non-tx cache are just >>>>>>> ordered putOrRemoveAll operations, immediately visible on flush without >>>>>>> any atomicity. >>>>> I assume that in Sanne's idea, ordering in a batch doesn't matter, aside >>>>> from operations on the same key. Having ordering in there would for >>>>> example not allow us to parallelize by segment. >>>>> >>>>>> So I want to write a first chunk, in our code that looks like: >>>>>> >>>>>> startBatch >>>>>> put(chunk1/A, [some large value]) >>>>>> put(chunk1/B, [some small metadata]) >>>>>> put(chunk1/C, [some small metadata]) >>>>>> endBatch >>>>>> There is no reason to use a transaction, in fact we had to disable >>>>>> transactions as some of these entries could be large. >>>>>> There also is no reason for the batch, other than optimising the latency. >>>>> Let me summarize to see if we have the requirements for a useful >>>>> batching system (which is sort of patterned on the JDBC statement batching): >>>>> >>>>> - a batch is not an atomic operation, i.e. it is not backed by a transaction >>>>> - it can be wrapped in a transaction if needed >>>>> - batches cannot be nested >>>>> - batches only involve unconditional write operations (put, putAll, remove) >>>>> - ordering of operations within a batch is unimportant aside from >>>>> modifications to the same key where we apply "last one wins" >>>>> - when a batch is "flushed" (i.e. endBatch is invoked) the ops are >>>>> grouped by segment and sent to the appropriate owner for processing, >>>>> potentially in parallel >>>>> >>>>> As Radim has called it, this is essentially a putOrRemoveAll op (with an >>>>> async counterpart). >>>> It is putOrRemoveAll when applied on a non-tx cache, and actually >>>> implementing that shouldn't be complex. However, when transactions come >>>> into play, it is different, because Sanne wants us to remove the >>>> modifications in completed batch from the local transactional invocation >>>> context and 'cache' them on the owners. Since reads have to be >>>> transactionally consistent, we need to inspect the transaction on the >>>> remote nodes (remote repeatable read). >>>> >>>> Sanne's request makes sense to me. However as the current implementation >>>> is providing a false assumption that it could work as JDBC batches while >>>> it's nothing but crippled JTA, and as I don't see anyone shouting "I'll >>>> implement that, next week it's done!", I second deprecating/removing the >>>> API for the time being. >>>> >>> Exactly my thoughts, it's definitely not an unreasonable request, but >>> it would require a lot of work to implement correctly. >>> >>> >>>> I don't find the current API ideal either, as it depends on thread >>>> locals (JTA does as well, but...) while it does not seem useful enough >>>> to me. I would prefer >>>> >>>> interface BatchingCache { >>>> Batch start(); >>>> } >>>> >>>> @NotThreadSafe >>>> interface Batch { >>>> void put(K k, V value); >>>> ... >>>> void execute(); >>>> void drop(); // maybe not needed >>>> } >>>> >>> I was hoping the functional API's evalMany() would be good enough, but >>> I see now that it replicates the function argument (which holds all >>> the values) everywhere. So putAll() is still more efficient, unless >>> using groups to make sure all keys in the batch have the same owners. >> Uh, doesn't putAll do the same? Is the modifications list isolate per >> target segments when replicating? >> > I missed the evalMany(Map, BiFunction) overload yesterday, and I > assume WriteOnlyMap.evalMany(Map, > MarshallableFunctions.setValueConsumer()) would behave exactly the > same as putAll(Map). Of course, it's not better either, as you still > have to create the map beforehand... > > OTOH I'm pretty sure you're the one who wrote the code to split the > input keys/values by target segments both for putAll() and for > evalMany() in NonTxDistributionInterceptor :) I was referring to "I see now that it replicates the function argument (which holds all the values) everywhere. So putAll() is still more efficient." And besides sending the setValue operation along, I don't see what you mean. * In non-tx mode, evalMany() wraps the entries using ReadOnlySegmentAwareMap which filters segments for given node during marshalling. putAll does exactly the same. * In tx mode, both commands are added to modifications list and this is sent (in PrepareCommand) to all participating nodes, including entries that are not owned by a given node. (that's a space for optimizations). Anyway, while evalMany would be sufficient for non-transactional mode (and batching API would be only a convenience), it is not enough in tx mode as it does not wipe out non-local modifications/reads on originator during the flush. When implementing tx functional commands, I was considering keeping modifications on remote node during the transaction (before the prepare phase) for repeatable functional reads, but in the end I went with sending all modifications for a given entry along with the read. Radim > > Dan > _______________________________________________ > infinispan-dev mailing list > infinispan-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Radim Vansa JBoss Performance Team From rvansa at redhat.com Wed Feb 22 04:08:38 2017 From: rvansa at redhat.com (Radim Vansa) Date: Wed, 22 Feb 2017 10:08:38 +0100 Subject: [infinispan-dev] Major version cleaning In-Reply-To: <84e0313a-f2a5-f021-2bf0-5b08d4feb57e@redhat.com> References: <98a58d71-7daf-35c7-8e54-85735217a2d7@redhat.com> <16911ebf-a3c2-ab04-a615-03a19730aa13@redhat.com> <7c019da8-61b2-59d2-e671-aeca1f3fb7b6@infinispan.org> <35ac9568-2297-bf4e-dc29-ad62d7888322@redhat.com> <7c7f128e-2eec-62bf-c516-87540801a690@redhat.com> <84e0313a-f2a5-f021-2bf0-5b08d4feb57e@redhat.com> Message-ID: On 02/22/2017 09:53 AM, Radim Vansa wrote: > On 02/22/2017 09:11 AM, Dan Berindei wrote: >> On Tue, Feb 21, 2017 at 8:28 PM, Radim Vansa wrote: >>> On 02/21/2017 07:14 PM, Dan Berindei wrote: >>>> But doesn't the functional API's evalMany() provide something very >>>> close to the API you're suggesting? >>>> >>>> Dan >>>> >>>> >>>> On Tue, Feb 21, 2017 at 7:55 PM, Radim Vansa wrote: >>>>> On 02/21/2017 05:16 PM, Tristan Tarrant wrote: >>>>>> On 21/02/17 16:29, Sanne Grinovero wrote: >>>>>>>> You haven't explained what "flush" means. Since you separate that from >>>>>>>> atomicity/consistency, I assume that batches on non-tx cache are just >>>>>>>> ordered putOrRemoveAll operations, immediately visible on flush without >>>>>>>> any atomicity. >>>>>> I assume that in Sanne's idea, ordering in a batch doesn't matter, aside >>>>>> from operations on the same key. Having ordering in there would for >>>>>> example not allow us to parallelize by segment. >>>>>> >>>>>>> So I want to write a first chunk, in our code that looks like: >>>>>>> >>>>>>> startBatch >>>>>>> put(chunk1/A, [some large value]) >>>>>>> put(chunk1/B, [some small metadata]) >>>>>>> put(chunk1/C, [some small metadata]) >>>>>>> endBatch >>>>>>> There is no reason to use a transaction, in fact we had to disable >>>>>>> transactions as some of these entries could be large. >>>>>>> There also is no reason for the batch, other than optimising the latency. >>>>>> Let me summarize to see if we have the requirements for a useful >>>>>> batching system (which is sort of patterned on the JDBC statement batching): >>>>>> >>>>>> - a batch is not an atomic operation, i.e. it is not backed by a transaction >>>>>> - it can be wrapped in a transaction if needed >>>>>> - batches cannot be nested >>>>>> - batches only involve unconditional write operations (put, putAll, remove) >>>>>> - ordering of operations within a batch is unimportant aside from >>>>>> modifications to the same key where we apply "last one wins" >>>>>> - when a batch is "flushed" (i.e. endBatch is invoked) the ops are >>>>>> grouped by segment and sent to the appropriate owner for processing, >>>>>> potentially in parallel >>>>>> >>>>>> As Radim has called it, this is essentially a putOrRemoveAll op (with an >>>>>> async counterpart). >>>>> It is putOrRemoveAll when applied on a non-tx cache, and actually >>>>> implementing that shouldn't be complex. However, when transactions come >>>>> into play, it is different, because Sanne wants us to remove the >>>>> modifications in completed batch from the local transactional invocation >>>>> context and 'cache' them on the owners. Since reads have to be >>>>> transactionally consistent, we need to inspect the transaction on the >>>>> remote nodes (remote repeatable read). >>>>> >>>>> Sanne's request makes sense to me. However as the current implementation >>>>> is providing a false assumption that it could work as JDBC batches while >>>>> it's nothing but crippled JTA, and as I don't see anyone shouting "I'll >>>>> implement that, next week it's done!", I second deprecating/removing the >>>>> API for the time being. >>>>> >>>> Exactly my thoughts, it's definitely not an unreasonable request, but >>>> it would require a lot of work to implement correctly. >>>> >>>> >>>>> I don't find the current API ideal either, as it depends on thread >>>>> locals (JTA does as well, but...) while it does not seem useful enough >>>>> to me. I would prefer >>>>> >>>>> interface BatchingCache { >>>>> Batch start(); >>>>> } >>>>> >>>>> @NotThreadSafe >>>>> interface Batch { >>>>> void put(K k, V value); >>>>> ... >>>>> void execute(); >>>>> void drop(); // maybe not needed >>>>> } >>>>> >>>> I was hoping the functional API's evalMany() would be good enough, but >>>> I see now that it replicates the function argument (which holds all >>>> the values) everywhere. So putAll() is still more efficient, unless >>>> using groups to make sure all keys in the batch have the same owners. >>> Uh, doesn't putAll do the same? Is the modifications list isolate per >>> target segments when replicating? >>> >> I missed the evalMany(Map, BiFunction) overload yesterday, and I >> assume WriteOnlyMap.evalMany(Map, >> MarshallableFunctions.setValueConsumer()) would behave exactly the >> same as putAll(Map). Of course, it's not better either, as you still >> have to create the map beforehand... >> >> OTOH I'm pretty sure you're the one who wrote the code to split the >> input keys/values by target segments both for putAll() and for >> evalMany() in NonTxDistributionInterceptor :) > I was referring to "I see now that it replicates the function argument > (which holds all the values) everywhere. So putAll() is still more > efficient." And besides sending the setValue operation along, I don't > see what you mean. > > * In non-tx mode, evalMany() wraps the entries using > ReadOnlySegmentAwareMap which filters segments for given node during > marshalling. putAll does exactly the same. > * In tx mode, both commands are added to modifications list and this is > sent (in PrepareCommand) to all participating nodes, including entries > that are not owned by a given node. (that's a space for optimizations). > > Anyway, while evalMany would be sufficient for non-transactional mode > (and batching API would be only a convenience), it is not enough in tx > mode as it does not wipe out non-local modifications/reads on originator > during the flush. > When implementing tx functional commands, I was considering keeping > modifications on remote node during the transaction (before the prepare > phase) for repeatable functional reads, but in the end I went with > sending all modifications for a given entry along with the read. Silly me :-/ When reviewing the code I've realized that non-functional reads don't send these modifications, which is a bug [1] R. [1] https://issues.jboss.org/browse/ISPN-7505 > > Radim > > > >> Dan >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > -- Radim Vansa JBoss Performance Team From dan.berindei at gmail.com Wed Feb 22 05:08:22 2017 From: dan.berindei at gmail.com (Dan Berindei) Date: Wed, 22 Feb 2017 12:08:22 +0200 Subject: [infinispan-dev] Major version cleaning In-Reply-To: <84e0313a-f2a5-f021-2bf0-5b08d4feb57e@redhat.com> References: <98a58d71-7daf-35c7-8e54-85735217a2d7@redhat.com> <16911ebf-a3c2-ab04-a615-03a19730aa13@redhat.com> <7c019da8-61b2-59d2-e671-aeca1f3fb7b6@infinispan.org> <35ac9568-2297-bf4e-dc29-ad62d7888322@redhat.com> <7c7f128e-2eec-62bf-c516-87540801a690@redhat.com> <84e0313a-f2a5-f021-2bf0-5b08d4feb57e@redhat.com> Message-ID: On Wed, Feb 22, 2017 at 10:53 AM, Radim Vansa wrote: > On 02/22/2017 09:11 AM, Dan Berindei wrote: >> On Tue, Feb 21, 2017 at 8:28 PM, Radim Vansa wrote: >>> On 02/21/2017 07:14 PM, Dan Berindei wrote: >>>> But doesn't the functional API's evalMany() provide something very >>>> close to the API you're suggesting? >>>> >>>> Dan >>>> >>>> >>>> On Tue, Feb 21, 2017 at 7:55 PM, Radim Vansa wrote: >>>>> On 02/21/2017 05:16 PM, Tristan Tarrant wrote: >>>>>> On 21/02/17 16:29, Sanne Grinovero wrote: >>>>>>>> You haven't explained what "flush" means. Since you separate that from >>>>>>>> atomicity/consistency, I assume that batches on non-tx cache are just >>>>>>>> ordered putOrRemoveAll operations, immediately visible on flush without >>>>>>>> any atomicity. >>>>>> I assume that in Sanne's idea, ordering in a batch doesn't matter, aside >>>>>> from operations on the same key. Having ordering in there would for >>>>>> example not allow us to parallelize by segment. >>>>>> >>>>>>> So I want to write a first chunk, in our code that looks like: >>>>>>> >>>>>>> startBatch >>>>>>> put(chunk1/A, [some large value]) >>>>>>> put(chunk1/B, [some small metadata]) >>>>>>> put(chunk1/C, [some small metadata]) >>>>>>> endBatch >>>>>>> There is no reason to use a transaction, in fact we had to disable >>>>>>> transactions as some of these entries could be large. >>>>>>> There also is no reason for the batch, other than optimising the latency. >>>>>> Let me summarize to see if we have the requirements for a useful >>>>>> batching system (which is sort of patterned on the JDBC statement batching): >>>>>> >>>>>> - a batch is not an atomic operation, i.e. it is not backed by a transaction >>>>>> - it can be wrapped in a transaction if needed >>>>>> - batches cannot be nested >>>>>> - batches only involve unconditional write operations (put, putAll, remove) >>>>>> - ordering of operations within a batch is unimportant aside from >>>>>> modifications to the same key where we apply "last one wins" >>>>>> - when a batch is "flushed" (i.e. endBatch is invoked) the ops are >>>>>> grouped by segment and sent to the appropriate owner for processing, >>>>>> potentially in parallel >>>>>> >>>>>> As Radim has called it, this is essentially a putOrRemoveAll op (with an >>>>>> async counterpart). >>>>> It is putOrRemoveAll when applied on a non-tx cache, and actually >>>>> implementing that shouldn't be complex. However, when transactions come >>>>> into play, it is different, because Sanne wants us to remove the >>>>> modifications in completed batch from the local transactional invocation >>>>> context and 'cache' them on the owners. Since reads have to be >>>>> transactionally consistent, we need to inspect the transaction on the >>>>> remote nodes (remote repeatable read). >>>>> >>>>> Sanne's request makes sense to me. However as the current implementation >>>>> is providing a false assumption that it could work as JDBC batches while >>>>> it's nothing but crippled JTA, and as I don't see anyone shouting "I'll >>>>> implement that, next week it's done!", I second deprecating/removing the >>>>> API for the time being. >>>>> >>>> Exactly my thoughts, it's definitely not an unreasonable request, but >>>> it would require a lot of work to implement correctly. >>>> >>>> >>>>> I don't find the current API ideal either, as it depends on thread >>>>> locals (JTA does as well, but...) while it does not seem useful enough >>>>> to me. I would prefer >>>>> >>>>> interface BatchingCache { >>>>> Batch start(); >>>>> } >>>>> >>>>> @NotThreadSafe >>>>> interface Batch { >>>>> void put(K k, V value); >>>>> ... >>>>> void execute(); >>>>> void drop(); // maybe not needed >>>>> } >>>>> >>>> I was hoping the functional API's evalMany() would be good enough, but >>>> I see now that it replicates the function argument (which holds all >>>> the values) everywhere. So putAll() is still more efficient, unless >>>> using groups to make sure all keys in the batch have the same owners. >>> Uh, doesn't putAll do the same? Is the modifications list isolate per >>> target segments when replicating? >>> >> I missed the evalMany(Map, BiFunction) overload yesterday, and I >> assume WriteOnlyMap.evalMany(Map, >> MarshallableFunctions.setValueConsumer()) would behave exactly the >> same as putAll(Map). Of course, it's not better either, as you still >> have to create the map beforehand... >> >> OTOH I'm pretty sure you're the one who wrote the code to split the >> input keys/values by target segments both for putAll() and for >> evalMany() in NonTxDistributionInterceptor :) > > I was referring to "I see now that it replicates the function argument > (which holds all the values) everywhere. So putAll() is still more > efficient." And besides sending the setValue operation along, I don't > see what you mean. > > * In non-tx mode, evalMany() wraps the entries using > ReadOnlySegmentAwareMap which filters segments for given node during > marshalling. putAll does exactly the same. > * In tx mode, both commands are added to modifications list and this is > sent (in PrepareCommand) to all participating nodes, including entries > that are not owned by a given node. (that's a space for optimizations). > > Anyway, while evalMany would be sufficient for non-transactional mode > (and batching API would be only a convenience), it is not enough in tx > mode as it does not wipe out non-local modifications/reads on originator > during the flush. I should have clarified that I was only talking about non-tx. With transactions, the owners can change between the write and the prepare (and the prepare can also be retried because of a topology change), so it should be the PrepareCommand's job to filter updates by destination. > When implementing tx functional commands, I was considering keeping > modifications on remote node during the transaction (before the prepare > phase) for repeatable functional reads, but in the end I went with > sending all modifications for a given entry along with the read. > Hmmm, neither seems like a very good fit... I was wondering about making the CompletableFutures returned by eval/evalMany during a transaction only complete after the transaction is done, and have methods thenEval()/thenEvalMany() to add another read/write to the transaction. The weird part would be that some other code might extend the scope of our transaction by starting an outer transaction, then committing the inner transaction wouldn't run the batched operations and wouldn't complete anything. The transaction manager wouldn't even notify the cache when the inner transaction is committed, so perhaps this could only work with our own "functional batching" API. Cheers Dan From pedro at infinispan.org Wed Feb 22 09:59:21 2017 From: pedro at infinispan.org (Pedro Ruivo) Date: Wed, 22 Feb 2017 14:59:21 +0000 Subject: [infinispan-dev] Default TCP configuration is broken. Message-ID: <1e296e81-29cb-f9af-7ba0-2badd6c60bd5@infinispan.org> Hi team, The 'default-jgroups-tcp.xml" has MFC protocol without the FRAG2/3 protocol. This is broken when we send a multicast message larger than 'max-credits'. It will block forever in MFC [1]. No timeouts since we don't have the CompletableFuture at this point. Possible solutions are: #1 put back FRAG2/3 advantage: we have multicast flow control. disadvantage: all messages are fragmented (unicast and multicast), that probably requires more resources (more messages in NAKACK and UNICAST tables?) #2 remove MFC advantage: probably low resources usages. TCP will handle any fragmentation. disadvantage: we don't have multicast flow control. #3 alternative? Cheers, Pedro [1] actually, I need a thread dump to confirm it. From sanne at infinispan.org Wed Feb 22 14:25:51 2017 From: sanne at infinispan.org (Sanne Grinovero) Date: Wed, 22 Feb 2017 19:25:51 +0000 Subject: [infinispan-dev] Classloader leaks? Message-ID: Hi all, our documentation suggest to raise the file limits to about 16K: http://infinispan.org/docs/stable/contributing/contributing.html#running_and_writing_tests I already have this setup since years, yet I've been noticing errors such as: "Caused by: java.io.IOException: Too many open files" Today I decided to finally have a look, and I see that while running the testsuite, my system's consumption of file descriptor raises continuously, up to more than 2 millions. (When not running the suite, I'm consuming 200K - that's including IDEs and other FD hungry systems like Chrome) Trying to get some samples of these file descriptors, it looks like it's really about open files. Jar files to be more precise. What puzzles me is that taking just one jar - jgroups for example - I can count 7852 open instances of it, but distributed among a handful of processes only. My guess is classloaders aren't being closed? Also: why did nobody else notice problems? Do you all have reconfigured your system for unlimited FDs? Thanks, Sanne From afield at redhat.com Wed Feb 22 14:41:11 2017 From: afield at redhat.com (Alan Field) Date: Wed, 22 Feb 2017 14:41:11 -0500 (EST) Subject: [infinispan-dev] Default TCP configuration is broken. In-Reply-To: <1e296e81-29cb-f9af-7ba0-2badd6c60bd5@infinispan.org> References: <1e296e81-29cb-f9af-7ba0-2badd6c60bd5@infinispan.org> Message-ID: <685568376.110231956.1487792471372.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Pedro Ruivo" > To: "ispn-dev" > Sent: Wednesday, February 22, 2017 9:59:21 AM > Subject: [infinispan-dev] Default TCP configuration is broken. > > Hi team, > > The 'default-jgroups-tcp.xml" has MFC protocol without the FRAG2/3 > protocol. This is broken when we send a multicast message larger than > 'max-credits'. It will block forever in MFC [1]. No timeouts since we > don't have the CompletableFuture at this point. > > Possible solutions are: > > #1 put back FRAG2/3 > > advantage: we have multicast flow control. > disadvantage: all messages are fragmented (unicast and multicast), that > probably requires more resources (more messages in NAKACK and UNICAST > tables?) This is my preferred solution, since removing MFC did not work for me! Thanks, Alan > > #2 remove MFC > > advantage: probably low resources usages. TCP will handle any fragmentation. > disadvantage: we don't have multicast flow control. > > #3 alternative? > > Cheers, > Pedro > > [1] actually, I need a thread dump to confirm it. > _______________________________________________ > infinispan-dev mailing list > infinispan-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev > From pedro at infinispan.org Wed Feb 22 14:50:09 2017 From: pedro at infinispan.org (Pedro Ruivo) Date: Wed, 22 Feb 2017 19:50:09 +0000 Subject: [infinispan-dev] Default TCP configuration is broken. In-Reply-To: <685568376.110231956.1487792471372.JavaMail.zimbra@redhat.com> References: <1e296e81-29cb-f9af-7ba0-2badd6c60bd5@infinispan.org> <685568376.110231956.1487792471372.JavaMail.zimbra@redhat.com> Message-ID: One step ahead: https://issues.jboss.org/browse/ISPN-7512 On 22-02-2017 19:41, Alan Field wrote: > > > ----- Original Message ----- >> From: "Pedro Ruivo" >> To: "ispn-dev" >> Sent: Wednesday, February 22, 2017 9:59:21 AM >> Subject: [infinispan-dev] Default TCP configuration is broken. >> >> Hi team, >> >> The 'default-jgroups-tcp.xml" has MFC protocol without the FRAG2/3 >> protocol. This is broken when we send a multicast message larger than >> 'max-credits'. It will block forever in MFC [1]. No timeouts since we >> don't have the CompletableFuture at this point. >> >> Possible solutions are: >> >> #1 put back FRAG2/3 >> >> advantage: we have multicast flow control. >> disadvantage: all messages are fragmented (unicast and multicast), that >> probably requires more resources (more messages in NAKACK and UNICAST >> tables?) > > This is my preferred solution, since removing MFC did not work for me! > > Thanks, > Alan > >> >> #2 remove MFC >> >> advantage: probably low resources usages. TCP will handle any fragmentation. >> disadvantage: we don't have multicast flow control. >> >> #3 alternative? >> >> Cheers, >> Pedro >> >> [1] actually, I need a thread dump to confirm it. >> _______________________________________________ >> 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 > From dan.berindei at gmail.com Wed Feb 22 15:01:18 2017 From: dan.berindei at gmail.com (Dan Berindei) Date: Wed, 22 Feb 2017 22:01:18 +0200 Subject: [infinispan-dev] Default TCP configuration is broken. In-Reply-To: <685568376.110231956.1487792471372.JavaMail.zimbra@redhat.com> References: <1e296e81-29cb-f9af-7ba0-2badd6c60bd5@infinispan.org> <685568376.110231956.1487792471372.JavaMail.zimbra@redhat.com> Message-ID: +1 to add FRAG3 back in, with frag_size="200k" to make fragmentation less likely, yet stay under max_credits * min_threshold. Dan On Wed, Feb 22, 2017 at 9:41 PM, Alan Field wrote: > > > ----- Original Message ----- >> From: "Pedro Ruivo" >> To: "ispn-dev" >> Sent: Wednesday, February 22, 2017 9:59:21 AM >> Subject: [infinispan-dev] Default TCP configuration is broken. >> >> Hi team, >> >> The 'default-jgroups-tcp.xml" has MFC protocol without the FRAG2/3 >> protocol. This is broken when we send a multicast message larger than >> 'max-credits'. It will block forever in MFC [1]. No timeouts since we >> don't have the CompletableFuture at this point. >> >> Possible solutions are: >> >> #1 put back FRAG2/3 >> >> advantage: we have multicast flow control. >> disadvantage: all messages are fragmented (unicast and multicast), that >> probably requires more resources (more messages in NAKACK and UNICAST >> tables?) > > This is my preferred solution, since removing MFC did not work for me! > > Thanks, > Alan > >> >> #2 remove MFC >> >> advantage: probably low resources usages. TCP will handle any fragmentation. >> disadvantage: we don't have multicast flow control. >> >> #3 alternative? >> >> Cheers, >> Pedro >> >> [1] actually, I need a thread dump to confirm it. >> _______________________________________________ >> 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 From dan.berindei at gmail.com Wed Feb 22 15:09:12 2017 From: dan.berindei at gmail.com (Dan Berindei) Date: Wed, 22 Feb 2017 22:09:12 +0200 Subject: [infinispan-dev] Classloader leaks? In-Reply-To: References: Message-ID: I've been running with an limit of 10240 file descriptors for a while now, and I've never had problems (unless you count the time I upgraded gnome-terminal and it started ignoring my /etc/security/limits.conf). The CI agents also run the full build with a 9999 file descriptors limit. Dan On Wed, Feb 22, 2017 at 9:25 PM, Sanne Grinovero wrote: > Hi all, > > our documentation suggest to raise the file limits to about 16K: > http://infinispan.org/docs/stable/contributing/contributing.html#running_and_writing_tests > > I already have this setup since years, yet I've been noticing errors such as: > > "Caused by: java.io.IOException: Too many open files" > > Today I decided to finally have a look, and I see that while running > the testsuite, my system's consumption of file descriptor raises > continuously, up to more than 2 millions. > (When not running the suite, I'm consuming 200K - that's including > IDEs and other FD hungry systems like Chrome) > > Trying to get some samples of these file descriptors, it looks like > it's really about open files. Jar files to be more precise. > > What puzzles me is that taking just one jar - jgroups for example - I > can count 7852 open instances of it, but distributed among a handful > of processes only. > > My guess is classloaders aren't being closed? > > Also: why did nobody else notice problems? Do you all have > reconfigured your system for unlimited FDs? > > Thanks, > Sanne > _______________________________________________ > infinispan-dev mailing list > infinispan-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev From dereed at redhat.com Wed Feb 22 16:20:35 2017 From: dereed at redhat.com (Dennis Reed) Date: Wed, 22 Feb 2017 16:20:35 -0500 Subject: [infinispan-dev] Classloader leaks? In-Reply-To: References: Message-ID: <9e126eed-63a2-757d-c240-dcd224d04248@redhat.com> Are those actually 2 million *unique* descriptors? I've seen lsof output that listed many duplicates for the same file descriptor (one for each thread?), making the list appear much larger than it really was. -Dennis On 02/22/2017 02:25 PM, Sanne Grinovero wrote: > Hi all, > > our documentation suggest to raise the file limits to about 16K: > http://infinispan.org/docs/stable/contributing/contributing.html#running_and_writing_tests > > I already have this setup since years, yet I've been noticing errors such as: > > "Caused by: java.io.IOException: Too many open files" > > Today I decided to finally have a look, and I see that while running > the testsuite, my system's consumption of file descriptor raises > continuously, up to more than 2 millions. > (When not running the suite, I'm consuming 200K - that's including > IDEs and other FD hungry systems like Chrome) > > Trying to get some samples of these file descriptors, it looks like > it's really about open files. Jar files to be more precise. > > What puzzles me is that taking just one jar - jgroups for example - I > can count 7852 open instances of it, but distributed among a handful > of processes only. > > My guess is classloaders aren't being closed? > > Also: why did nobody else notice problems? Do you all have > reconfigured your system for unlimited FDs? > > Thanks, > Sanne > _______________________________________________ > infinispan-dev mailing list > infinispan-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev > From sanne at infinispan.org Wed Feb 22 18:31:55 2017 From: sanne at infinispan.org (Sanne Grinovero) Date: Wed, 22 Feb 2017 23:31:55 +0000 Subject: [infinispan-dev] Classloader leaks? In-Reply-To: <9e126eed-63a2-757d-c240-dcd224d04248@redhat.com> References: <9e126eed-63a2-757d-c240-dcd224d04248@redhat.com> Message-ID: On 22 February 2017 at 21:20, Dennis Reed wrote: > Are those actually 2 million *unique* descriptors? > > I've seen lsof output that listed many duplicates for the same file > descriptor (one for each thread?), making the list appear much larger > than it really was. Good point! You're right, I verified and all instances of e.g. the jgroups jar were using the same FD, just a different thread id. This is the full error I'm having, when running the tests from the "infinispan-compatibility-mode-it" maven module: java.lang.IllegalStateException: failed to create a child event loop at io.netty.util.concurrent.MultithreadEventExecutorGroup.(MultithreadEventExecutorGroup.java:88) at io.netty.util.concurrent.MultithreadEventExecutorGroup.(MultithreadEventExecutorGroup.java:58) at io.netty.channel.MultithreadEventLoopGroup.(MultithreadEventLoopGroup.java:51) at io.netty.channel.nio.NioEventLoopGroup.(NioEventLoopGroup.java:87) at io.netty.channel.nio.NioEventLoopGroup.(NioEventLoopGroup.java:82) at io.netty.channel.nio.NioEventLoopGroup.(NioEventLoopGroup.java:63) at io.netty.channel.nio.NioEventLoopGroup.(NioEventLoopGroup.java:51) at org.jboss.resteasy.plugins.server.netty.NettyJaxrsServer.start(NettyJaxrsServer.java:239) at org.infinispan.rest.NettyRestServer.start(NettyRestServer.java:81) at org.infinispan.it.compatibility.CompatibilityCacheFactory.createRestCache(CompatibilityCacheFactory.java:199) at org.infinispan.it.compatibility.CompatibilityCacheFactory.createRestMemcachedCaches(CompatibilityCacheFactory.java:137) at org.infinispan.it.compatibility.CompatibilityCacheFactory.setup(CompatibilityCacheFactory.java:123) at org.infinispan.it.compatibility.ByteArrayKeyReplEmbeddedHotRodTest.setup(ByteArrayKeyReplEmbeddedHotRodTest.java:87) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:84) at org.testng.internal.Invoker.invokeConfigurationMethod(Invoker.java:564) at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:213) at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:138) at org.testng.internal.TestMethodWorker.invokeBeforeClassMethods(TestMethodWorker.java:175) at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:107) at org.testng.TestRunner.privateRun(TestRunner.java:767) at org.testng.TestRunner.run(TestRunner.java:617) at org.testng.SuiteRunner.runTest(SuiteRunner.java:348) at org.testng.SuiteRunner.access$000(SuiteRunner.java:38) at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:382) at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) Caused by: io.netty.channel.ChannelException: failed to open a new selector at io.netty.channel.nio.NioEventLoop.openSelector(NioEventLoop.java:157) at io.netty.channel.nio.NioEventLoop.(NioEventLoop.java:148) at io.netty.channel.nio.NioEventLoopGroup.newChild(NioEventLoopGroup.java:126) at io.netty.channel.nio.NioEventLoopGroup.newChild(NioEventLoopGroup.java:36) at io.netty.util.concurrent.MultithreadEventExecutorGroup.(MultithreadEventExecutorGroup.java:84) ... 32 more Caused by: java.io.IOException: Too many open files at sun.nio.ch.IOUtil.makePipe(Native Method) at sun.nio.ch.EPollSelectorImpl.(EPollSelectorImpl.java:65) at sun.nio.ch.EPollSelectorProvider.openSelector(EPollSelectorProvider.java:36) at io.netty.channel.nio.NioEventLoop.openSelector(NioEventLoop.java:155) ... 36 more Now that I know which metrics to look at, I see that before running this specific module my system is consuming about 12K FDs, and occasionally it just stays around that same level and the integration tests will pass w/o any failure. However most of the times when I run this module specifically, I see the FD consumption increase during the test run and eventually fail with the above error. The last sample I could take before failing was around 15,5K, and not surprising as my limit is set to 16384.. so I guess it could have attempted to grow further. Tomorrow I'll try with higher limits, to see if I'm running with barely enough for this testsuite or if I see it growing more. Still sounds like a leak though, as the increase is quite significant.. Thanks, Sanne > > -Dennis > > > On 02/22/2017 02:25 PM, Sanne Grinovero wrote: >> Hi all, >> >> our documentation suggest to raise the file limits to about 16K: >> http://infinispan.org/docs/stable/contributing/contributing.html#running_and_writing_tests >> >> I already have this setup since years, yet I've been noticing errors such as: >> >> "Caused by: java.io.IOException: Too many open files" >> >> Today I decided to finally have a look, and I see that while running >> the testsuite, my system's consumption of file descriptor raises >> continuously, up to more than 2 millions. >> (When not running the suite, I'm consuming 200K - that's including >> IDEs and other FD hungry systems like Chrome) >> >> Trying to get some samples of these file descriptors, it looks like >> it's really about open files. Jar files to be more precise. >> >> What puzzles me is that taking just one jar - jgroups for example - I >> can count 7852 open instances of it, but distributed among a handful >> of processes only. >> >> My guess is classloaders aren't being closed? >> >> Also: why did nobody else notice problems? Do you all have >> reconfigured your system for unlimited FDs? >> >> Thanks, >> Sanne >> _______________________________________________ >> 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 From bban at redhat.com Thu Feb 23 01:13:20 2017 From: bban at redhat.com (Bela Ban) Date: Thu, 23 Feb 2017 07:13:20 +0100 Subject: [infinispan-dev] Default TCP configuration is broken. In-Reply-To: References: <1e296e81-29cb-f9af-7ba0-2badd6c60bd5@infinispan.org> <685568376.110231956.1487792471372.JavaMail.zimbra@redhat.com> Message-ID: Note that FRAG3 is relatively recent... On 22/02/17 21:01, Dan Berindei wrote: > +1 to add FRAG3 back in, with frag_size="200k" to make fragmentation > less likely, yet stay under max_credits * min_threshold. > > Dan > > On Wed, Feb 22, 2017 at 9:41 PM, Alan Field wrote: >> >> >> ----- Original Message ----- >>> From: "Pedro Ruivo" >>> To: "ispn-dev" >>> Sent: Wednesday, February 22, 2017 9:59:21 AM >>> Subject: [infinispan-dev] Default TCP configuration is broken. >>> >>> Hi team, >>> >>> The 'default-jgroups-tcp.xml" has MFC protocol without the FRAG2/3 >>> protocol. This is broken when we send a multicast message larger than >>> 'max-credits'. It will block forever in MFC [1]. No timeouts since we >>> don't have the CompletableFuture at this point. >>> >>> Possible solutions are: >>> >>> #1 put back FRAG2/3 >>> >>> advantage: we have multicast flow control. >>> disadvantage: all messages are fragmented (unicast and multicast), that >>> probably requires more resources (more messages in NAKACK and UNICAST >>> tables?) >> >> This is my preferred solution, since removing MFC did not work for me! >> >> Thanks, >> Alan >> >>> >>> #2 remove MFC >>> >>> advantage: probably low resources usages. TCP will handle any fragmentation. >>> disadvantage: we don't have multicast flow control. >>> >>> #3 alternative? >>> >>> Cheers, >>> Pedro >>> >>> [1] actually, I need a thread dump to confirm it. >>> _______________________________________________ >>> 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 > -- Bela Ban, JGroups lead (http://www.jgroups.org) From dan.berindei at gmail.com Thu Feb 23 02:47:04 2017 From: dan.berindei at gmail.com (Dan Berindei) Date: Thu, 23 Feb 2017 09:47:04 +0200 Subject: [infinispan-dev] Classloader leaks? In-Reply-To: References: <9e126eed-63a2-757d-c240-dcd224d04248@redhat.com> Message-ID: On my system, `cat /proc/sys/fs/file-nr` reports 24838 used FDs, and that goes up to 29030 when running the infinispan-compatibility-mode-it tests. Since there are only 78 tests, a leak is quite possible, but I wouldn't say 4K open files (or sockets, more likely) really is a deal-breaker. Cheers Dan On Thu, Feb 23, 2017 at 1:31 AM, Sanne Grinovero wrote: > On 22 February 2017 at 21:20, Dennis Reed wrote: >> Are those actually 2 million *unique* descriptors? >> >> I've seen lsof output that listed many duplicates for the same file >> descriptor (one for each thread?), making the list appear much larger >> than it really was. > > Good point! You're right, I verified and all instances of e.g. the > jgroups jar were using the same FD, just a different thread id. > > This is the full error I'm having, when running the tests from the > "infinispan-compatibility-mode-it" maven module: > > > java.lang.IllegalStateException: failed to create a child event loop > at io.netty.util.concurrent.MultithreadEventExecutorGroup.(MultithreadEventExecutorGroup.java:88) > at io.netty.util.concurrent.MultithreadEventExecutorGroup.(MultithreadEventExecutorGroup.java:58) > at io.netty.channel.MultithreadEventLoopGroup.(MultithreadEventLoopGroup.java:51) > at io.netty.channel.nio.NioEventLoopGroup.(NioEventLoopGroup.java:87) > at io.netty.channel.nio.NioEventLoopGroup.(NioEventLoopGroup.java:82) > at io.netty.channel.nio.NioEventLoopGroup.(NioEventLoopGroup.java:63) > at io.netty.channel.nio.NioEventLoopGroup.(NioEventLoopGroup.java:51) > at org.jboss.resteasy.plugins.server.netty.NettyJaxrsServer.start(NettyJaxrsServer.java:239) > at org.infinispan.rest.NettyRestServer.start(NettyRestServer.java:81) > at org.infinispan.it.compatibility.CompatibilityCacheFactory.createRestCache(CompatibilityCacheFactory.java:199) > at org.infinispan.it.compatibility.CompatibilityCacheFactory.createRestMemcachedCaches(CompatibilityCacheFactory.java:137) > at org.infinispan.it.compatibility.CompatibilityCacheFactory.setup(CompatibilityCacheFactory.java:123) > at org.infinispan.it.compatibility.ByteArrayKeyReplEmbeddedHotRodTest.setup(ByteArrayKeyReplEmbeddedHotRodTest.java:87) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:84) > at org.testng.internal.Invoker.invokeConfigurationMethod(Invoker.java:564) > at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:213) > at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:138) > at org.testng.internal.TestMethodWorker.invokeBeforeClassMethods(TestMethodWorker.java:175) > at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:107) > at org.testng.TestRunner.privateRun(TestRunner.java:767) > at org.testng.TestRunner.run(TestRunner.java:617) > at org.testng.SuiteRunner.runTest(SuiteRunner.java:348) > at org.testng.SuiteRunner.access$000(SuiteRunner.java:38) > at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:382) > at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Caused by: io.netty.channel.ChannelException: failed to open a new selector > at io.netty.channel.nio.NioEventLoop.openSelector(NioEventLoop.java:157) > at io.netty.channel.nio.NioEventLoop.(NioEventLoop.java:148) > at io.netty.channel.nio.NioEventLoopGroup.newChild(NioEventLoopGroup.java:126) > at io.netty.channel.nio.NioEventLoopGroup.newChild(NioEventLoopGroup.java:36) > at io.netty.util.concurrent.MultithreadEventExecutorGroup.(MultithreadEventExecutorGroup.java:84) > ... 32 more > Caused by: java.io.IOException: Too many open files > at sun.nio.ch.IOUtil.makePipe(Native Method) > at sun.nio.ch.EPollSelectorImpl.(EPollSelectorImpl.java:65) > at sun.nio.ch.EPollSelectorProvider.openSelector(EPollSelectorProvider.java:36) > at io.netty.channel.nio.NioEventLoop.openSelector(NioEventLoop.java:155) > ... 36 more > > Now that I know which metrics to look at, I see that before running > this specific module my system is consuming about 12K FDs, and > occasionally it just stays around that same level and the integration > tests will pass w/o any failure. > However most of the times when I run this module specifically, I see > the FD consumption increase during the test run and eventually fail > with the above error. The last sample I could take before failing was > around 15,5K, and not surprising as my limit is set to 16384.. so I > guess it could have attempted to grow further. > > Tomorrow I'll try with higher limits, to see if I'm running with > barely enough for this testsuite or if I see it growing more. Still > sounds like a leak though, as the increase is quite significant.. > > Thanks, > Sanne > >> >> -Dennis >> >> >> On 02/22/2017 02:25 PM, Sanne Grinovero wrote: >>> Hi all, >>> >>> our documentation suggest to raise the file limits to about 16K: >>> http://infinispan.org/docs/stable/contributing/contributing.html#running_and_writing_tests >>> >>> I already have this setup since years, yet I've been noticing errors such as: >>> >>> "Caused by: java.io.IOException: Too many open files" >>> >>> Today I decided to finally have a look, and I see that while running >>> the testsuite, my system's consumption of file descriptor raises >>> continuously, up to more than 2 millions. >>> (When not running the suite, I'm consuming 200K - that's including >>> IDEs and other FD hungry systems like Chrome) >>> >>> Trying to get some samples of these file descriptors, it looks like >>> it's really about open files. Jar files to be more precise. >>> >>> What puzzles me is that taking just one jar - jgroups for example - I >>> can count 7852 open instances of it, but distributed among a handful >>> of processes only. >>> >>> My guess is classloaders aren't being closed? >>> >>> Also: why did nobody else notice problems? Do you all have >>> reconfigured your system for unlimited FDs? >>> >>> Thanks, >>> Sanne >>> _______________________________________________ >>> 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 From vjuranek at redhat.com Thu Feb 23 02:56:39 2017 From: vjuranek at redhat.com (Vojtech Juranek) Date: Thu, 23 Feb 2017 08:56:39 +0100 Subject: [infinispan-dev] Classloader leaks? In-Reply-To: References: <9e126eed-63a2-757d-c240-dcd224d04248@redhat.com> Message-ID: <2200650.jdol9ruXuT@localhost.localdomain> On st?eda 22. ?nora 2017 23:31:55 CET Sanne Grinovero wrote: > Good point! You're right, I verified and all instances of e.g. the > jgroups jar were using the same FD, just a different thread id. yes, maybe there are some stale threads? Recently (well, actually it quite some time and it's still on my TODO list to investigate it more:-) testsuite started to fail with OOM issue "cannto create native thread" on some machines (rarely on RHEL7, very often on RHEL6). I tried to increase limit on user threads and end up with unlimited, so this sound like some leak to me as well. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. Url : http://lists.jboss.org/pipermail/infinispan-dev/attachments/20170223/942b2d26/attachment.bin From dan.berindei at gmail.com Thu Feb 23 03:29:45 2017 From: dan.berindei at gmail.com (Dan Berindei) Date: Thu, 23 Feb 2017 10:29:45 +0200 Subject: [infinispan-dev] Classloader leaks? In-Reply-To: <2200650.jdol9ruXuT@localhost.localdomain> References: <9e126eed-63a2-757d-c240-dcd224d04248@redhat.com> <2200650.jdol9ruXuT@localhost.localdomain> Message-ID: After looking into this some more... TestNGTestListener does report 1262 leaked HotRodServerWorker and MemcachedServer worker threads at the end of the compatibility-mode-it test suite, so I'd say we probably do have a leak. The tests do seem to shut down their servers at the end, maybe someone more familiar with the server could look into why this happens? And maybe change the thread naming scheme so that we can tell from the thread name which test didn't shut down its servers properly? But I'm pretty sure the leak isn't the problem here, compared to the fact that we run 15 tests in parallel, AND each test starts 2 HotRod/Memcached/REST servers and 2 clients, AND they use the default thread pool sizes instead of the 20x smaller thread pool sizes that we use in the core suite. Cheers Dan On Thu, Feb 23, 2017 at 9:56 AM, Vojtech Juranek wrote: > On st?eda 22. ?nora 2017 23:31:55 CET Sanne Grinovero wrote: >> Good point! You're right, I verified and all instances of e.g. the >> jgroups jar were using the same FD, just a different thread id. > > yes, maybe there are some stale threads? Recently (well, actually it quite > some time and it's still on my TODO list to investigate it more:-) testsuite > started to fail with OOM issue "cannto create native thread" on some machines > (rarely on RHEL7, very often on RHEL6). I tried to increase limit on user > threads and end up with unlimited, so this sound like some leak to me as well. > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev From sanne at infinispan.org Thu Feb 23 05:19:21 2017 From: sanne at infinispan.org (Sanne Grinovero) Date: Thu, 23 Feb 2017 10:19:21 +0000 Subject: [infinispan-dev] Classloader leaks? In-Reply-To: References: <9e126eed-63a2-757d-c240-dcd224d04248@redhat.com> <2200650.jdol9ruXuT@localhost.localdomain> Message-ID: Hi Dan, thanks! Yes I concur: while this module seems to have some high leaks I also suspect now that it's unrelated to the failure. Looks like the "too many files" exception can be thrown for a wide number of reasons, FYI these tests fail "almost consistently" for me: Failed tests: ByteArrayKeyDistEmbeddedHotRodTest.setup:27 ? IllegalState failed to create a ... ByteArrayKeyReplEmbeddedHotRodTest.setup:87 ? IllegalState failed to create a ... ByteArrayValueDistEmbeddedHotRodTest.setup:27 ? IllegalState failed to create ... ByteArrayValueReplEmbeddedHotRodTest.setup:87 ? IllegalState failed to create ... DistEmbeddedHotRodBulkTest.setup:36 ? IllegalState failed to create a child ev... DistEmbeddedRestHotRodTest.setup:25 ? IllegalState failed to create a child ev... DistL1EmbeddedHotRodTest.setup:30 ? IllegalState failed to create a child even... DistMemcachedEmbeddedTest.setup:39 ? Transport Could not fetch transport org.infinispan.it.compatibility.EmbeddedHotRodCacheListenerTest.setup(org.infinispan.it.compatibility.EmbeddedHotRodCacheListenerTest) Run 1: EmbeddedHotRodCacheListenerTest.setup:36 ? IllegalState failed to create a chi... Run 2: PASS Run 3: PASS EmbeddedMemcachedCacheListenerTest.setup:39 ? IllegalState failed to create a ... EmbeddedRestMemcachedHotRodTest.setup:50 ? IllegalState failed to create a chi... ReplEmbeddedRestHotRodTest.setup:38 ? Channel Unable to create Channel from cl... Tests run: 103, Failures: 12, Errors: 0, Skipped: 49 If I run it a dozen times, I get the same report (exactly the same tests failing) in 11 cases, and in one case it just passes all test. I'm pretty sure I'm not running out of FDs anymore. I'll open a JIRA and move on, as I just needed to verify some PRs but need to switch focus to my own projects: I hope someone with more Netty experience will be interested enough to have a look, I can try reproducing eventual fixes. - https://issues.jboss.org/browse/ISPN-7517 Thanks all! Sanne On 23 February 2017 at 08:29, Dan Berindei wrote: > After looking into this some more... > > TestNGTestListener does report 1262 leaked HotRodServerWorker and > MemcachedServer worker threads at the end of the compatibility-mode-it > test suite, so I'd say we probably do have a leak. The tests do seem > to shut down their servers at the end, maybe someone more familiar > with the server could look into why this happens? And maybe change the > thread naming scheme so that we can tell from the thread name which > test didn't shut down its servers properly? > > But I'm pretty sure the leak isn't the problem here, compared to the > fact that we run 15 tests in parallel, AND each test starts 2 > HotRod/Memcached/REST servers and 2 clients, AND they use the default > thread pool sizes instead of the 20x smaller thread pool sizes that we > use in the core suite. > > Cheers > Dan > > On Thu, Feb 23, 2017 at 9:56 AM, Vojtech Juranek wrote: >> On st?eda 22. ?nora 2017 23:31:55 CET Sanne Grinovero wrote: >>> Good point! You're right, I verified and all instances of e.g. the >>> jgroups jar were using the same FD, just a different thread id. >> >> yes, maybe there are some stale threads? Recently (well, actually it quite >> some time and it's still on my TODO list to investigate it more:-) testsuite >> started to fail with OOM issue "cannto create native thread" on some machines >> (rarely on RHEL7, very often on RHEL6). I tried to increase limit on user >> threads and end up with unlimited, so this sound like some leak to me as well. >> >> _______________________________________________ >> 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 From sanne at infinispan.org Thu Feb 23 06:00:38 2017 From: sanne at infinispan.org (Sanne Grinovero) Date: Thu, 23 Feb 2017 11:00:38 +0000 Subject: [infinispan-dev] Concerns about the testsuite state Message-ID: Hi all, I was mentioning on IRC today that I've seen many failures in the past hours, as I was trying to verify a simple PR. Tristan suggested to share some failures, so here are the outcomes of my first attempts to build Infinispan, each time restarting after a module would fail: Failed tests: ClusterListenerDistTest>AbstractClusterListenerNonTxTest.testPrimaryOwnerGoesDownAfterSendingEvent:81 expected [ClusterListenerDistTest-NodeC-54048] but found [ClusterListenerDistTest-NodeA-38805] ClusterListenerDistTest.testPrimaryOwnerGoesDownBeforeSendingEvent:78 expected [ClusterListenerDistTest-NodeDR-1944] but found [ClusterListenerDistTest-NodeDP-23754] Failed tests: LocalModeNoPassivationTest>LocalModePassivationTest.testValuesWithEvictedEntries:219 Value: 295 was not found! InfinispanNodeFailureTest.killedNodeDoesNotBreakReplaceCommand:135 expected: but was: Failed tests: DistL1WriteSkewTest>AbstractClusteredWriteSkewTest.testConditionalPutFailWriteSkewWithPassivation:184->AbstractClusteredWriteSkewTest.doTestWriteSkewWithPassivation:316 The key was not evicted after 10 inserts RecoveryEnabledWriteSkewTest>AbstractClusteredWriteSkewTest.testRemoveFailWriteSkewWithPassivationOnNonOwner:160->AbstractClusteredWriteSkewTest.doTestWriteSkewWithPassivation:316 The key was not evicted after 10 inserts Failed tests: NonTxBackupOwnerBecomingPrimaryOwnerTest.testPrimaryOwnerChangingDuringPutOverwrite:75->doTest:165 ? Runtime ClusteredTxConditionalCommandTest>ClusteredConditionalCommandTest.testPutIfAbsentOnNonOwnerShared:246->ClusteredConditionalCommandTest.doTest:121->assertLoadAfterOperation:46 primary owner load expected:<1> but was:<0> ReplCommandForwardingTest.testForwardToJoinerAsyncPrepare:119->testForwardToJoinerAsyncTx:161 ? IllegalState Failed tests: org.infinispan.functional.FunctionalCachestoreTest.testWriteLoad[passivation=false](org.infinispan.functional.FunctionalCachestoreTest) Run 1: PASS Run 2: PASS Run 3: PASS Run 4: PASS Run 5: PASS Run 6: PASS Run 7: PASS Run 8: PASS Run 9: FunctionalCachestoreTest.testWriteLoad:58->lambda$testWriteLoad$3:58 FunctionalCachestoreTest[passivation=false]-NodeB-46507 expected [false] but found [true] Run 10: PASS Run 11: PASS Run 12: PASS Run 13: PASS Run 14: PASS Run 15: PASS Run 16: PASS org.infinispan.functional.FunctionalCachestoreTest.testWriteLoad[passivation=true](org.infinispan.functional.FunctionalCachestoreTest) Run 1: PASS Run 2: PASS Run 3: PASS Run 4: PASS Run 5: PASS Run 6: PASS Run 7: PASS Run 8: PASS Run 9: PASS Run 10: PASS Run 11: PASS Run 12: PASS Run 13: PASS Run 14: FunctionalCachestoreTest.testWriteLoad:58->lambda$testWriteLoad$3:58 FunctionalCachestoreTest[passivation=true]-NodeB-39167 expected [false] but found [true] Run 15: PASS Run 16: PASS DistTotalOrderL1WriteSkewTest>AbstractClusteredWriteSkewTest.testConditionalPutFailWriteSkewWithPassivation:184->AbstractClusteredWriteSkewTest.doTestWriteSkewWithPassivation:316 The key was not evicted after 10 inserts DistTotalOrderWriteSkewTest>AbstractClusteredWriteSkewTest.testConditionalRemoveFailWriteSkewWithPassivation:200->AbstractClusteredWriteSkewTest.doTestWriteSkewWithPassivation:316 The key was not evicted after 10 inserts Tests run: 8427, Failures: 4, Errors: 0, Skipped: 0 Failed tests: SecureServerFailureRetryTest>HitsAwareCacheManagersTest.createBeforeMethod:114->MultipleCacheManagersTest.createBeforeMethod:119->MultipleCacheManagersTest.callCreateCacheManagers:109->AbstractRetryTest.createCacheManagers:63->createStartHotRodServer:27 ? IllegalState Failed tests: DistWriteSkewTest>AbstractClusteredWriteSkewTest.testConditionalPutFailWriteSkewWithPassivationOnNonOwner:192->AbstractClusteredWriteSkewTest.doTestWriteSkewWithPassivation:316 The key was not evicted after 10 inserts DistWriteSkewTest>AbstractClusteredWriteSkewTest.testConditionalReplaceWriteSkewWithPassivationOnNonOwner:220->AbstractClusteredWriteSkewTest.doTestWriteSkewWithPassivation:316 The key was not evicted after 10 inserts Tests run: 8457, Failures: 2, Errors: 0, Skipped: 0 AFAIR in one case it was able to go beyond infinispan-core, in all others these are failures in core. Thanks, Sanne From mudokonman at gmail.com Thu Feb 23 07:28:16 2017 From: mudokonman at gmail.com (William Burns) Date: Thu, 23 Feb 2017 12:28:16 +0000 Subject: [infinispan-dev] Concerns about the testsuite state In-Reply-To: References: Message-ID: All of the tests that failed with "The key was not evicted after 10 inserts" should be fixed. The PR was integrated this morning [1]. That was half of your failures :-) The cluster listener one I have been taking with some guys about. Unfortunately I am not familiar with the others. [1] https://github.com/infinispan/infinispan/pull/4886 On Thu, Feb 23, 2017, 6:01 AM Sanne Grinovero wrote: > Hi all, > I was mentioning on IRC today that I've seen many failures in the past > hours, as I was trying to verify a simple PR. > > Tristan suggested to share some failures, so here are the outcomes of > my first attempts to build Infinispan, each time restarting after a > module would fail: > > Failed tests: > > ClusterListenerDistTest>AbstractClusterListenerNonTxTest.testPrimaryOwnerGoesDownAfterSendingEvent:81 > expected [ClusterListenerDistTest-NodeC-54048] but found > [ClusterListenerDistTest-NodeA-38805] > ClusterListenerDistTest.testPrimaryOwnerGoesDownBeforeSendingEvent:78 > expected [ClusterListenerDistTest-NodeDR-1944] but found > [ClusterListenerDistTest-NodeDP-23754] > > Failed tests: > > LocalModeNoPassivationTest>LocalModePassivationTest.testValuesWithEvictedEntries:219 > Value: 295 was not found! > InfinispanNodeFailureTest.killedNodeDoesNotBreakReplaceCommand:135 > expected: but was: Failed tests: > > DistL1WriteSkewTest>AbstractClusteredWriteSkewTest.testConditionalPutFailWriteSkewWithPassivation:184->AbstractClusteredWriteSkewTest.doTestWriteSkewWithPassivation:316 > The key was not evicted after 10 inserts > RecoveryEnabledWriteSkewTest>AbstractClusteredWriteSkewTest.testRemoveFailWriteSkewWithPassivationOnNonOwner:160->AbstractClusteredWriteSkewTest.doTestWriteSkewWithPassivation:316 > The key was not evicted after 10 inserts > Failed tests: > > NonTxBackupOwnerBecomingPrimaryOwnerTest.testPrimaryOwnerChangingDuringPutOverwrite:75->doTest:165 > ? Runtime > > ClusteredTxConditionalCommandTest>ClusteredConditionalCommandTest.testPutIfAbsentOnNonOwnerShared:246->ClusteredConditionalCommandTest.doTest:121->assertLoadAfterOperation:46 > primary owner load expected:<1> but was:<0> > > ReplCommandForwardingTest.testForwardToJoinerAsyncPrepare:119->testForwardToJoinerAsyncTx:161 > ? IllegalState > > Failed tests: > > org.infinispan.functional.FunctionalCachestoreTest.testWriteLoad[passivation=false](org.infinispan.functional.FunctionalCachestoreTest) > Run 1: PASS > Run 2: PASS > Run 3: PASS > Run 4: PASS > Run 5: PASS > Run 6: PASS > Run 7: PASS > Run 8: PASS > Run 9: > FunctionalCachestoreTest.testWriteLoad:58->lambda$testWriteLoad$3:58 > FunctionalCachestoreTest[passivation=false]-NodeB-46507 expected > [false] but found [true] > Run 10: PASS > Run 11: PASS > Run 12: PASS > Run 13: PASS > Run 14: PASS > Run 15: PASS > Run 16: PASS > > > org.infinispan.functional.FunctionalCachestoreTest.testWriteLoad[passivation=true](org.infinispan.functional.FunctionalCachestoreTest) > Run 1: PASS > Run 2: PASS > Run 3: PASS > Run 4: PASS > Run 5: PASS > Run 6: PASS > Run 7: PASS > Run 8: PASS > Run 9: PASS > Run 10: PASS > Run 11: PASS > Run 12: PASS > Run 13: PASS > Run 14: > FunctionalCachestoreTest.testWriteLoad:58->lambda$testWriteLoad$3:58 > FunctionalCachestoreTest[passivation=true]-NodeB-39167 expected > [false] but found [true] > Run 15: PASS > Run 16: PASS > > > DistTotalOrderL1WriteSkewTest>AbstractClusteredWriteSkewTest.testConditionalPutFailWriteSkewWithPassivation:184->AbstractClusteredWriteSkewTest.doTestWriteSkewWithPassivation:316 > The key was not evicted after 10 inserts > > DistTotalOrderWriteSkewTest>AbstractClusteredWriteSkewTest.testConditionalRemoveFailWriteSkewWithPassivation:200->AbstractClusteredWriteSkewTest.doTestWriteSkewWithPassivation:316 > The key was not evicted after 10 inserts > > Tests run: 8427, Failures: 4, Errors: 0, Skipped: 0 > > Failed tests: > > SecureServerFailureRetryTest>HitsAwareCacheManagersTest.createBeforeMethod:114->MultipleCacheManagersTest.createBeforeMethod:119->MultipleCacheManagersTest.callCreateCacheManagers:109->AbstractRetryTest.createCacheManagers:63->createStartHotRodServer:27 > ? IllegalState > > Failed tests: > > DistWriteSkewTest>AbstractClusteredWriteSkewTest.testConditionalPutFailWriteSkewWithPassivationOnNonOwner:192->AbstractClusteredWriteSkewTest.doTestWriteSkewWithPassivation:316 > The key was not evicted after 10 inserts > > DistWriteSkewTest>AbstractClusteredWriteSkewTest.testConditionalReplaceWriteSkewWithPassivationOnNonOwner:220->AbstractClusteredWriteSkewTest.doTestWriteSkewWithPassivation:316 > The key was not evicted after 10 inserts > > Tests run: 8457, Failures: 2, Errors: 0, Skipped: 0 > > AFAIR in one case it was able to go beyond infinispan-core, in all > others these are failures in core. > > Thanks, > Sanne > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20170223/41a1d679/attachment.html From rvansa at redhat.com Thu Feb 23 09:11:21 2017 From: rvansa at redhat.com (Radim Vansa) Date: Thu, 23 Feb 2017 15:11:21 +0100 Subject: [infinispan-dev] Default TCP configuration is broken. In-Reply-To: <1e296e81-29cb-f9af-7ba0-2badd6c60bd5@infinispan.org> References: <1e296e81-29cb-f9af-7ba0-2badd6c60bd5@infinispan.org> Message-ID: <3dcb7eb7-f93a-43c1-48dc-1d54834c5d9a@redhat.com> On 02/22/2017 03:59 PM, Pedro Ruivo wrote: > Hi team, > > The 'default-jgroups-tcp.xml" has MFC protocol without the FRAG2/3 > protocol. This is broken when we send a multicast message larger than > 'max-credits'. It will block forever in MFC [1]. No timeouts since we > don't have the CompletableFuture at this point. > > Possible solutions are: > > #1 put back FRAG2/3 > > advantage: we have multicast flow control. > disadvantage: all messages are fragmented (unicast and multicast), that > probably requires more resources (more messages in NAKACK and UNICAST > tables?) > > #2 remove MFC > > advantage: probably low resources usages. TCP will handle any fragmentation. > disadvantage: we don't have multicast flow control. > > #3 alternative? Let MFC go one message beyond the limit? I don't know if that's desirable, but it's about having less messages on the wire = in some buffers. I've seen FRAG2 buffering a many parts of a big StateResponseCommand. So it might have similar effect if we allow one big message to be sent, rather than splitting it into parts and buffering that anyway on the receiver side. Just my 2c Radim > > Cheers, > Pedro > > [1] actually, I need a thread dump to confirm it. > _______________________________________________ > infinispan-dev mailing list > infinispan-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Radim Vansa JBoss Performance Team From dan.berindei at gmail.com Thu Feb 23 10:04:11 2017 From: dan.berindei at gmail.com (Dan Berindei) Date: Thu, 23 Feb 2017 17:04:11 +0200 Subject: [infinispan-dev] Concerns about the testsuite state In-Reply-To: References: Message-ID: Finally! ;) Superficially the LocalModeNoPassivationTest and FunctionalCachestoreTest failures also look like they're caused by the data container change. Dan On Thu, Feb 23, 2017 at 2:28 PM, William Burns wrote: > All of the tests that failed with "The key was not evicted after 10 inserts" > should be fixed. The PR was integrated this morning [1]. That was half of > your failures :-) > > The cluster listener one I have been taking with some guys about. > Unfortunately I am not familiar with the others. > > [1] https://github.com/infinispan/infinispan/pull/4886 > > > On Thu, Feb 23, 2017, 6:01 AM Sanne Grinovero wrote: >> >> Hi all, >> I was mentioning on IRC today that I've seen many failures in the past >> hours, as I was trying to verify a simple PR. >> >> Tristan suggested to share some failures, so here are the outcomes of >> my first attempts to build Infinispan, each time restarting after a >> module would fail: >> >> Failed tests: >> >> ClusterListenerDistTest>AbstractClusterListenerNonTxTest.testPrimaryOwnerGoesDownAfterSendingEvent:81 >> expected [ClusterListenerDistTest-NodeC-54048] but found >> [ClusterListenerDistTest-NodeA-38805] >> ClusterListenerDistTest.testPrimaryOwnerGoesDownBeforeSendingEvent:78 >> expected [ClusterListenerDistTest-NodeDR-1944] but found >> [ClusterListenerDistTest-NodeDP-23754] >> >> Failed tests: >> >> LocalModeNoPassivationTest>LocalModePassivationTest.testValuesWithEvictedEntries:219 >> Value: 295 was not found! >> InfinispanNodeFailureTest.killedNodeDoesNotBreakReplaceCommand:135 >> expected: but was: >> >> Failed tests: >> >> DistL1WriteSkewTest>AbstractClusteredWriteSkewTest.testConditionalPutFailWriteSkewWithPassivation:184->AbstractClusteredWriteSkewTest.doTestWriteSkewWithPassivation:316 >> The key was not evicted after 10 inserts >> >> >> RecoveryEnabledWriteSkewTest>AbstractClusteredWriteSkewTest.testRemoveFailWriteSkewWithPassivationOnNonOwner:160->AbstractClusteredWriteSkewTest.doTestWriteSkewWithPassivation:316 >> The key was not evicted after 10 inserts >> >> >> Failed tests: >> >> NonTxBackupOwnerBecomingPrimaryOwnerTest.testPrimaryOwnerChangingDuringPutOverwrite:75->doTest:165 >> ? Runtime >> >> ClusteredTxConditionalCommandTest>ClusteredConditionalCommandTest.testPutIfAbsentOnNonOwnerShared:246->ClusteredConditionalCommandTest.doTest:121->assertLoadAfterOperation:46 >> primary owner load expected:<1> but was:<0> >> >> ReplCommandForwardingTest.testForwardToJoinerAsyncPrepare:119->testForwardToJoinerAsyncTx:161 >> ? IllegalState >> >> Failed tests: >> >> org.infinispan.functional.FunctionalCachestoreTest.testWriteLoad[passivation=false](org.infinispan.functional.FunctionalCachestoreTest) >> Run 1: PASS >> Run 2: PASS >> Run 3: PASS >> Run 4: PASS >> Run 5: PASS >> Run 6: PASS >> Run 7: PASS >> Run 8: PASS >> Run 9: >> FunctionalCachestoreTest.testWriteLoad:58->lambda$testWriteLoad$3:58 >> FunctionalCachestoreTest[passivation=false]-NodeB-46507 expected >> [false] but found [true] >> Run 10: PASS >> Run 11: PASS >> Run 12: PASS >> Run 13: PASS >> Run 14: PASS >> Run 15: PASS >> Run 16: PASS >> >> >> org.infinispan.functional.FunctionalCachestoreTest.testWriteLoad[passivation=true](org.infinispan.functional.FunctionalCachestoreTest) >> Run 1: PASS >> Run 2: PASS >> Run 3: PASS >> Run 4: PASS >> Run 5: PASS >> Run 6: PASS >> Run 7: PASS >> Run 8: PASS >> Run 9: PASS >> Run 10: PASS >> Run 11: PASS >> Run 12: PASS >> Run 13: PASS >> Run 14: >> FunctionalCachestoreTest.testWriteLoad:58->lambda$testWriteLoad$3:58 >> FunctionalCachestoreTest[passivation=true]-NodeB-39167 expected >> [false] but found [true] >> Run 15: PASS >> Run 16: PASS >> >> >> DistTotalOrderL1WriteSkewTest>AbstractClusteredWriteSkewTest.testConditionalPutFailWriteSkewWithPassivation:184->AbstractClusteredWriteSkewTest.doTestWriteSkewWithPassivation:316 >> The key was not evicted after 10 inserts >> >> DistTotalOrderWriteSkewTest>AbstractClusteredWriteSkewTest.testConditionalRemoveFailWriteSkewWithPassivation:200->AbstractClusteredWriteSkewTest.doTestWriteSkewWithPassivation:316 >> The key was not evicted after 10 inserts >> >> Tests run: 8427, Failures: 4, Errors: 0, Skipped: 0 >> >> Failed tests: >> >> SecureServerFailureRetryTest>HitsAwareCacheManagersTest.createBeforeMethod:114->MultipleCacheManagersTest.createBeforeMethod:119->MultipleCacheManagersTest.callCreateCacheManagers:109->AbstractRetryTest.createCacheManagers:63->createStartHotRodServer:27 >> ? IllegalState >> >> Failed tests: >> >> DistWriteSkewTest>AbstractClusteredWriteSkewTest.testConditionalPutFailWriteSkewWithPassivationOnNonOwner:192->AbstractClusteredWriteSkewTest.doTestWriteSkewWithPassivation:316 >> The key was not evicted after 10 inserts >> >> DistWriteSkewTest>AbstractClusteredWriteSkewTest.testConditionalReplaceWriteSkewWithPassivationOnNonOwner:220->AbstractClusteredWriteSkewTest.doTestWriteSkewWithPassivation:316 >> The key was not evicted after 10 inserts >> >> Tests run: 8457, Failures: 2, Errors: 0, Skipped: 0 >> >> AFAIR in one case it was able to go beyond infinispan-core, in all >> others these are failures in core. >> >> Thanks, >> Sanne >> >> _______________________________________________ >> 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 From mudokonman at gmail.com Thu Feb 23 11:14:15 2017 From: mudokonman at gmail.com (William Burns) Date: Thu, 23 Feb 2017 16:14:15 +0000 Subject: [infinispan-dev] Concerns about the testsuite state In-Reply-To: References: Message-ID: On Thu, Feb 23, 2017 at 10:06 AM Dan Berindei wrote: > Finally! ;) > > Superficially the LocalModeNoPassivationTest and > Looking more closely this one seems like a pretty bad bug actually (not just test failure) :P > FunctionalCachestoreTest failures also look like they're caused by the > data container change. > > Dan > > On Thu, Feb 23, 2017 at 2:28 PM, William Burns > wrote: > > All of the tests that failed with "The key was not evicted after 10 > inserts" > > should be fixed. The PR was integrated this morning [1]. That was half of > > your failures :-) > > > > The cluster listener one I have been taking with some guys about. > > Unfortunately I am not familiar with the others. > > > > [1] https://github.com/infinispan/infinispan/pull/4886 > > > > > > On Thu, Feb 23, 2017, 6:01 AM Sanne Grinovero > wrote: > >> > >> Hi all, > >> I was mentioning on IRC today that I've seen many failures in the past > >> hours, as I was trying to verify a simple PR. > >> > >> Tristan suggested to share some failures, so here are the outcomes of > >> my first attempts to build Infinispan, each time restarting after a > >> module would fail: > >> > >> Failed tests: > >> > >> > ClusterListenerDistTest>AbstractClusterListenerNonTxTest.testPrimaryOwnerGoesDownAfterSendingEvent:81 > >> expected [ClusterListenerDistTest-NodeC-54048] but found > >> [ClusterListenerDistTest-NodeA-38805] > >> ClusterListenerDistTest.testPrimaryOwnerGoesDownBeforeSendingEvent:78 > >> expected [ClusterListenerDistTest-NodeDR-1944] but found > >> [ClusterListenerDistTest-NodeDP-23754] > >> > >> Failed tests: > >> > >> > LocalModeNoPassivationTest>LocalModePassivationTest.testValuesWithEvictedEntries:219 > >> Value: 295 was not found! > >> InfinispanNodeFailureTest.killedNodeDoesNotBreakReplaceCommand:135 > >> expected: but was: > >> > >> Failed tests: > >> > >> > DistL1WriteSkewTest>AbstractClusteredWriteSkewTest.testConditionalPutFailWriteSkewWithPassivation:184->AbstractClusteredWriteSkewTest.doTestWriteSkewWithPassivation:316 > >> The key was not evicted after 10 inserts > >> > >> > >> > RecoveryEnabledWriteSkewTest>AbstractClusteredWriteSkewTest.testRemoveFailWriteSkewWithPassivationOnNonOwner:160->AbstractClusteredWriteSkewTest.doTestWriteSkewWithPassivation:316 > >> The key was not evicted after 10 inserts > >> > >> > >> Failed tests: > >> > >> > NonTxBackupOwnerBecomingPrimaryOwnerTest.testPrimaryOwnerChangingDuringPutOverwrite:75->doTest:165 > >> ? Runtime > >> > >> > ClusteredTxConditionalCommandTest>ClusteredConditionalCommandTest.testPutIfAbsentOnNonOwnerShared:246->ClusteredConditionalCommandTest.doTest:121->assertLoadAfterOperation:46 > >> primary owner load expected:<1> but was:<0> > >> > >> > ReplCommandForwardingTest.testForwardToJoinerAsyncPrepare:119->testForwardToJoinerAsyncTx:161 > >> ? IllegalState > >> > >> Failed tests: > >> > >> > org.infinispan.functional.FunctionalCachestoreTest.testWriteLoad[passivation=false](org.infinispan.functional.FunctionalCachestoreTest) > >> Run 1: PASS > >> Run 2: PASS > >> Run 3: PASS > >> Run 4: PASS > >> Run 5: PASS > >> Run 6: PASS > >> Run 7: PASS > >> Run 8: PASS > >> Run 9: > >> FunctionalCachestoreTest.testWriteLoad:58->lambda$testWriteLoad$3:58 > >> FunctionalCachestoreTest[passivation=false]-NodeB-46507 expected > >> [false] but found [true] > >> Run 10: PASS > >> Run 11: PASS > >> Run 12: PASS > >> Run 13: PASS > >> Run 14: PASS > >> Run 15: PASS > >> Run 16: PASS > >> > >> > >> > org.infinispan.functional.FunctionalCachestoreTest.testWriteLoad[passivation=true](org.infinispan.functional.FunctionalCachestoreTest) > >> Run 1: PASS > >> Run 2: PASS > >> Run 3: PASS > >> Run 4: PASS > >> Run 5: PASS > >> Run 6: PASS > >> Run 7: PASS > >> Run 8: PASS > >> Run 9: PASS > >> Run 10: PASS > >> Run 11: PASS > >> Run 12: PASS > >> Run 13: PASS > >> Run 14: > >> FunctionalCachestoreTest.testWriteLoad:58->lambda$testWriteLoad$3:58 > >> FunctionalCachestoreTest[passivation=true]-NodeB-39167 expected > >> [false] but found [true] > >> Run 15: PASS > >> Run 16: PASS > >> > >> > >> > DistTotalOrderL1WriteSkewTest>AbstractClusteredWriteSkewTest.testConditionalPutFailWriteSkewWithPassivation:184->AbstractClusteredWriteSkewTest.doTestWriteSkewWithPassivation:316 > >> The key was not evicted after 10 inserts > >> > >> > DistTotalOrderWriteSkewTest>AbstractClusteredWriteSkewTest.testConditionalRemoveFailWriteSkewWithPassivation:200->AbstractClusteredWriteSkewTest.doTestWriteSkewWithPassivation:316 > >> The key was not evicted after 10 inserts > >> > >> Tests run: 8427, Failures: 4, Errors: 0, Skipped: 0 > >> > >> Failed tests: > >> > >> > SecureServerFailureRetryTest>HitsAwareCacheManagersTest.createBeforeMethod:114->MultipleCacheManagersTest.createBeforeMethod:119->MultipleCacheManagersTest.callCreateCacheManagers:109->AbstractRetryTest.createCacheManagers:63->createStartHotRodServer:27 > >> ? IllegalState > >> > >> Failed tests: > >> > >> > DistWriteSkewTest>AbstractClusteredWriteSkewTest.testConditionalPutFailWriteSkewWithPassivationOnNonOwner:192->AbstractClusteredWriteSkewTest.doTestWriteSkewWithPassivation:316 > >> The key was not evicted after 10 inserts > >> > >> > DistWriteSkewTest>AbstractClusteredWriteSkewTest.testConditionalReplaceWriteSkewWithPassivationOnNonOwner:220->AbstractClusteredWriteSkewTest.doTestWriteSkewWithPassivation:316 > >> The key was not evicted after 10 inserts > >> > >> Tests run: 8457, Failures: 2, Errors: 0, Skipped: 0 > >> > >> AFAIR in one case it was able to go beyond infinispan-core, in all > >> others these are failures in core. > >> > >> Thanks, > >> Sanne > >> > >> _______________________________________________ > >> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20170223/0569790d/attachment.html From pedro at infinispan.org Thu Feb 23 18:52:41 2017 From: pedro at infinispan.org (Pedro Ruivo) Date: Thu, 23 Feb 2017 23:52:41 +0000 Subject: [infinispan-dev] Infinispan 9.0.0.CR2 has been released! Message-ID: Hi everybody, Infinispan 9.0.0.CR2 is finally released. Read about it in the announcement here: https://goo.gl/wVzdZB. Regards, Infinispan Team From rvansa at redhat.com Fri Feb 24 08:53:33 2017 From: rvansa at redhat.com (Radim Vansa) Date: Fri, 24 Feb 2017 14:53:33 +0100 Subject: [infinispan-dev] Repeatable reads and WSC as default Message-ID: <9801e8ae-994a-b23b-e45d-5d60a2ce3181@redhat.com> Hi all, I am writing a bit too late in 9.0 cycle, but since I've found couple of bugs [1][2] and spaces for improvement [3][4] in WSC implementation, I was wondering about confirming the performance effect of fixes. And I am wondering if the current defaults for transactional cache, being READ_COMMITTED and WSC off are the best options. During 8.0 cycle Tristan raised a discussion [5] including WSC defaults and I think that the general opinion was "make it default", which requires RR isolation and simple versioning scheme. But I think that the whole thing [6] went a bit forgotten and all that was done is [7]. Do we want to do this, at least using current API? (we most likely don't want to refactor ConfigurationBuilder when CR2 is out) Radim [1] https://issues.jboss.org/browse/ISPN-7526 [2] https://issues.jboss.org/browse/ISPN-7527 [3] https://issues.jboss.org/browse/ISPN-7528 [4] https://github.com/infinispan/infinispan/blob/master/core/src/main/java/org/infinispan/container/entries/ClusteredRepeatableReadEntry.java#L30 could be a contention point [5] http://infinispan.markmail.org/message/rasqqkojwdboql7y?q=write+skew+list:org%2Ejboss%2Elists%2Einfinispan-dev+order:date-backward [6] https://issues.jboss.org/browse/ISPN-3927 [7] https://issues.jboss.org/browse/ISPN-7507 -- Radim Vansa JBoss Performance Team From dan.berindei at gmail.com Fri Feb 24 10:45:59 2017 From: dan.berindei at gmail.com (Dan Berindei) Date: Fri, 24 Feb 2017 17:45:59 +0200 Subject: [infinispan-dev] Repeatable reads and WSC as default In-Reply-To: <9801e8ae-994a-b23b-e45d-5d60a2ce3181@redhat.com> References: <9801e8ae-994a-b23b-e45d-5d60a2ce3181@redhat.com> Message-ID: I still think WSC should be enabled by default, but we probably missed the 9.0 train. I see the 8.0 discussion also included batching, i.e. hiding the WSC options and forcing batching to use optimistic locking w/out WSC (currently batching allows any locking type, but batch transactions are isolated from external transactions). That would be at odds with Sanne's suggestions in the "major version cleaning" thread, because those would require a batch to join any external transaction. Cheers Dan On Fri, Feb 24, 2017 at 3:53 PM, Radim Vansa wrote: > Hi all, > > I am writing a bit too late in 9.0 cycle, but since I've found couple of > bugs [1][2] and spaces for improvement [3][4] in WSC implementation, I > was wondering about confirming the performance effect of fixes. And I am > wondering if the current defaults for transactional cache, being > READ_COMMITTED and WSC off are the best options. > > During 8.0 cycle Tristan raised a discussion [5] including WSC defaults > and I think that the general opinion was "make it default", which > requires RR isolation and simple versioning scheme. But I think that the > whole thing [6] went a bit forgotten and all that was done is [7]. > > Do we want to do this, at least using current API? (we most likely don't > want to refactor ConfigurationBuilder when CR2 is out) > > Radim > > [1] https://issues.jboss.org/browse/ISPN-7526 > [2] https://issues.jboss.org/browse/ISPN-7527 > [3] https://issues.jboss.org/browse/ISPN-7528 > [4] > https://github.com/infinispan/infinispan/blob/master/core/src/main/java/org/infinispan/container/entries/ClusteredRepeatableReadEntry.java#L30 > could be a contention point > [5] > http://infinispan.markmail.org/message/rasqqkojwdboql7y?q=write+skew+list:org%2Ejboss%2Elists%2Einfinispan-dev+order:date-backward > [6] https://issues.jboss.org/browse/ISPN-3927 > [7] https://issues.jboss.org/browse/ISPN-7507 > > -- > Radim Vansa > JBoss Performance Team > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev From galder at redhat.com Mon Feb 27 05:57:33 2017 From: galder at redhat.com (=?utf-8?Q?Galder_Zamarre=C3=B1o?=) Date: Mon, 27 Feb 2017 10:57:33 +0000 Subject: [infinispan-dev] Repeatable reads and WSC as default In-Reply-To: References: <9801e8ae-994a-b23b-e45d-5d60a2ce3181@redhat.com> Message-ID: <6E978A3B-9052-461E-8621-A1A2848B7654@redhat.com> We keep missing the train :( Enabling WSC by default is something we've discussed before (JIRA & dev list), e.g. https://issues.jboss.org/browse/ISPN-3655 Cheers, -- Galder Zamarre?o Infinispan, Red Hat > On 24 Feb 2017, at 15:45, Dan Berindei wrote: > > I still think WSC should be enabled by default, but we probably missed > the 9.0 train. > > I see the 8.0 discussion also included batching, i.e. hiding the WSC > options and forcing batching to use optimistic locking w/out WSC > (currently batching allows any locking type, but batch transactions > are isolated from external transactions). That would be at odds with > Sanne's suggestions in the "major version cleaning" thread, because > those would require a batch to join any external transaction. > > Cheers > Dan > > > On Fri, Feb 24, 2017 at 3:53 PM, Radim Vansa wrote: >> Hi all, >> >> I am writing a bit too late in 9.0 cycle, but since I've found couple of >> bugs [1][2] and spaces for improvement [3][4] in WSC implementation, I >> was wondering about confirming the performance effect of fixes. And I am >> wondering if the current defaults for transactional cache, being >> READ_COMMITTED and WSC off are the best options. >> >> During 8.0 cycle Tristan raised a discussion [5] including WSC defaults >> and I think that the general opinion was "make it default", which >> requires RR isolation and simple versioning scheme. But I think that the >> whole thing [6] went a bit forgotten and all that was done is [7]. >> >> Do we want to do this, at least using current API? (we most likely don't >> want to refactor ConfigurationBuilder when CR2 is out) >> >> Radim >> >> [1] https://issues.jboss.org/browse/ISPN-7526 >> [2] https://issues.jboss.org/browse/ISPN-7527 >> [3] https://issues.jboss.org/browse/ISPN-7528 >> [4] >> https://github.com/infinispan/infinispan/blob/master/core/src/main/java/org/infinispan/container/entries/ClusteredRepeatableReadEntry.java#L30 >> could be a contention point >> [5] >> http://infinispan.markmail.org/message/rasqqkojwdboql7y?q=write+skew+list:org%2Ejboss%2Elists%2Einfinispan-dev+order:date-backward >> [6] https://issues.jboss.org/browse/ISPN-3927 >> [7] https://issues.jboss.org/browse/ISPN-7507 >> >> -- >> Radim Vansa >> JBoss Performance Team >> >> _______________________________________________ >> 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 From rvansa at redhat.com Mon Feb 27 06:18:51 2017 From: rvansa at redhat.com (Radim Vansa) Date: Mon, 27 Feb 2017 12:18:51 +0100 Subject: [infinispan-dev] Repeatable reads and WSC as default In-Reply-To: <6E978A3B-9052-461E-8621-A1A2848B7654@redhat.com> References: <9801e8ae-994a-b23b-e45d-5d60a2ce3181@redhat.com> <6E978A3B-9052-461E-8621-A1A2848B7654@redhat.com> Message-ID: Why is that JIRA closed? I was about to suggest that a complete JIRA triage in Alpha -> Beta stage could help, but that wouldn't notice closed ones. R. On 02/27/2017 11:57 AM, Galder Zamarre?o wrote: > We keep missing the train :( > > Enabling WSC by default is something we've discussed before (JIRA & dev list), e.g. > > https://issues.jboss.org/browse/ISPN-3655 > > Cheers, > -- > Galder Zamarre?o > Infinispan, Red Hat > >> On 24 Feb 2017, at 15:45, Dan Berindei wrote: >> >> I still think WSC should be enabled by default, but we probably missed >> the 9.0 train. >> >> I see the 8.0 discussion also included batching, i.e. hiding the WSC >> options and forcing batching to use optimistic locking w/out WSC >> (currently batching allows any locking type, but batch transactions >> are isolated from external transactions). That would be at odds with >> Sanne's suggestions in the "major version cleaning" thread, because >> those would require a batch to join any external transaction. >> >> Cheers >> Dan >> >> >> On Fri, Feb 24, 2017 at 3:53 PM, Radim Vansa wrote: >>> Hi all, >>> >>> I am writing a bit too late in 9.0 cycle, but since I've found couple of >>> bugs [1][2] and spaces for improvement [3][4] in WSC implementation, I >>> was wondering about confirming the performance effect of fixes. And I am >>> wondering if the current defaults for transactional cache, being >>> READ_COMMITTED and WSC off are the best options. >>> >>> During 8.0 cycle Tristan raised a discussion [5] including WSC defaults >>> and I think that the general opinion was "make it default", which >>> requires RR isolation and simple versioning scheme. But I think that the >>> whole thing [6] went a bit forgotten and all that was done is [7]. >>> >>> Do we want to do this, at least using current API? (we most likely don't >>> want to refactor ConfigurationBuilder when CR2 is out) >>> >>> Radim >>> >>> [1] https://issues.jboss.org/browse/ISPN-7526 >>> [2] https://issues.jboss.org/browse/ISPN-7527 >>> [3] https://issues.jboss.org/browse/ISPN-7528 >>> [4] >>> https://github.com/infinispan/infinispan/blob/master/core/src/main/java/org/infinispan/container/entries/ClusteredRepeatableReadEntry.java#L30 >>> could be a contention point >>> [5] >>> http://infinispan.markmail.org/message/rasqqkojwdboql7y?q=write+skew+list:org%2Ejboss%2Elists%2Einfinispan-dev+order:date-backward >>> [6] https://issues.jboss.org/browse/ISPN-3927 >>> [7] https://issues.jboss.org/browse/ISPN-7507 >>> >>> -- >>> Radim Vansa >>> JBoss Performance Team >>> >>> _______________________________________________ >>> 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 -- Radim Vansa JBoss Performance Team From rvansa at redhat.com Mon Feb 27 09:01:18 2017 From: rvansa at redhat.com (Radim Vansa) Date: Mon, 27 Feb 2017 15:01:18 +0100 Subject: [infinispan-dev] GetKeyValueCommand NPE with CR1 in Hibernate 2LC - ISPN-7029 In-Reply-To: <324cb4ad-8e90-a83e-f98a-9b11852bbb7b@redhat.com> References: <6F4EF3D8-2509-4209-9CD1-A3D65F195681@redhat.com> <12BF89EA-E18A-4116-B9B8-43B13CAF7BE1@redhat.com> <324cb4ad-8e90-a83e-f98a-9b11852bbb7b@redhat.com> Message-ID: <76d564c8-cd2f-3ef6-f043-e185180f67ed@redhat.com> Hi Galder, another solution came upon my mind (actually after finding this SO question [1]): we could check if (this.key == key || this.key.equals(key)) in SingleKeyNonTxInvocation context instead of just this.key.equals(key) and that could do the trick. Plus, such check maybe needed in couple of other places, haven't tried that. Seems that HashMap already does so, so the other types of contexts should work OOTB. Radim [1] http://stackoverflow.com/questions/13521184/equals-returns-false-yet-object-is-found-in-map On 02/20/2017 05:22 PM, Radim Vansa wrote: > On 02/20/2017 03:52 PM, Galder Zamarre?o wrote: >> I've just verified the problem and the NPE can be reproduced with Infinispan alone. >> >> More replies below: >> >> -- >> Galder Zamarre?o >> Infinispan, Red Hat >> >>> On 16 Feb 2017, at 10:44, Radim Vansa wrote: >>> >>> On 02/15/2017 06:07 PM, Galder Zamarre?o wrote: >>>> -- >>>> Galder Zamarre?o >>>> Infinispan, Red Hat >>>> >>>>> On 15 Feb 2017, at 12:21, Radim Vansa wrote: >>>>> >>>>> On 02/15/2017 11:28 AM, Galder Zamarre?o wrote: >>>>>> Hey Radim, >>>>>> >>>>>> Your changes in ISPN-7029 are causing issues with Hibernate 2LC. >>>>>> >>>>>> In particular [2]. Name.equals() always returns false, so it'll never be found in the context. So entry is null. >>>>> That's obviously a bug in the 2LC testsuite, isn't it? >>>> LOL, is it? You added the class and the javadoc clearly states that this entity defines equals incorrectly. You must have added it for a reason? >>>> >>>> https://github.com/hibernate/hibernate-orm/blob/master/hibernate-infinispan/src/test/java/org/hibernate/test/cache/infinispan/functional/entities/Name.java >>>> >>>> In any case, an object with an incorrect equals impl should not result in an NPE within Infinispan :| >>>> >>>>> Object used as @EmbeddedId needs to have the equals correctly defined. How else would you compare ids? I wonder how could that work in the past. >>>> ROFL... it's your baby so you tell me ;) >>> Okay, okay - I haven't checked the javadoc, so I just assumed that it's an oversight :) >>> >>>>>> Moreover, if EntryLookup.lookupEntry javadoc (and some implementations) can and do return null. Are you expecting that somehow that method will never return null? >>>>> With ISPN-7029 in, the entry should be wrapped in the context after EntryWrappingInterceptor if the key is in readCH, otherwise it should be null. In case that xDistributionInterceptor finds out that it needs to work on that value despite not being able to read it (e.g. in case that it's in writeCH during unfinished rebalance), it should wrap NullCacheEntry.getInstance() using EntryFactory. wrapExternalEntry. More info about the logic is in o.i.c.EntryFactory javadoc [3]. >>>> Not sure I understand what you're trying to imply above... so, is lookupEntry() allowed to return null or not? >>> It is allowed to return null, but: >>> >>> 1. If the node is an owner according to readCH, the entry must be wrapped into context in EWI (possibly as NullCacheEntry). >>> 2. The code can reach the GKVC.perform() iff this node is an owner of given key. >>> >>> The problem here is that I've assumed that if the entry was wrapped, it can be fetched. With incorrectly defined equals, as we see here, this does not hold. So we can >>> >>> a) check if the entry is null and throw more explanatory exception - more code in perform() >>> b) do the lookup after wrapping and throw there - unnecessary map lookup for such annoying problem >>> c) ostrich approach >>> >>> I think that b) in assert could do, otherwise I'd suggest c) >> Hmmmmm, what about not throwing an exception at all? >> >> IOW, e.g. in SingleKeyNonTxInvocationContext.lookupEntry(), if the key is not equals to the one cached, but the cached one is NullCacheEntry, couldn't it return that instead of null? What I'm trying to achieve here is that if the equals is not correctly implemented, the get() returns null, rather than throwing an exception. >> >> We'd also need to verify whether other context implementations could deal with it. >> >> Wouldn't that be better :\ ? I can see the point of throwing an exception (other than NPE of course), but it feels a little abrupt... particularly since seems like previously we've just returned null in such situations. > You're right that Cache.get(x) should ideally return null. > > InvocationContext.lookupEntry() returning NullCacheEntry and null has a > different meaning, though: > > * NullCacheEntry means that we are supposed to be able to read that > entry (according to readCH) but we haven't found that in DC. This is > used for example in CacheLoaderInterceptor, where we skip entries that > aren't in the context as opposed to recomputing the hash of the key. > * null means that this entry cannot be read on this node because the > segment this key belongs to is not in readCH, and therefore the command > shouldn't get past distribution interceptor. > > I don't mind changing the 'design' as long as it follows some simple > rules. I don't see how returning NCE for *any* key could be incorporated > into the rules, and how should that behave on multi-key contexts. > > In all but distribution mode, during read the key must be always wrapped > for read, because there's either no readCH (local) or replicated CH > (repl/invalidation). But in invalidation/local mode we can't handle that > in distribution interceptor as this is not present. > > I would really prefer to see this handled in > EntryWrappingInterceptor/EntryWrappingFactory rather than in each > command - in #4564 [2] I wanted to narrow the possible situations to be > handled in perform(), and other pieces (e.g. return handlers - see > dataReadReturnHandler, that will throw NPE as well in TX RR right now). > Note that some commands do the check ATM (e.g. functional commands) - I > think that those are leftovers and should be gone. > > I was about to suggest adding > > if (!key.equals(key)) return null; > > to all EWI.visitXXX methods as proper implemenations of equals should do the > > if (other == this) return true; > > anyway as a shortcut, so such check shouldn't affect performance. > However, this is not as simple with functional commands which should > operate on the null entry (on some node), we have to run these, and you > can't even ignore the value, you need some entry in there. > > I hate not finding my socks in the drawer where I definitely put those. > This just breaks too many things :-( > > Btw., it seems that SingleTxContextInvocationContext [1] will fail when > the entry is loaded from cache store - this is the place where you could > put the entry into invocation context twice. So the use case was > somewhat broken before, too. > > > [1] > https://github.com/infinispan/infinispan/blob/master/core/src/main/java/org/infinispan/context/SingleKeyNonTxInvocationContext.java#L114 > [2] https://github.com/infinispan/infinispan/pull/4564 > > >> Cheers, >> >>> Radim >>> >>>> To be more specific, SingleKeyNonTxInvocationContext.lookupEntry() can return null, so GetKeyValueCommand should be able to handle it? Or should SingleKeyNonTxInvocationContext.lookupEntry return NullCacheEntry.getInstance instead of null? >>>> >>>> To provide more specifics, SingleKeyNonTxInvocationContext has NullCacheEntry.getInstance in cacheEntry variable when it's returning null. Should it maybe return NullCacheEntry.getInstance instead of null from lookupEntry() ? >>>> >>>> Cheers, >>>> >>>>> Radim >>>>> >>>>> [3] https://github.com/infinispan/infinispan/blob/master/core/src/main/java/org/infinispan/container/EntryFactory.java >>>>> >>>>>> I'll create a JIRA to track all issues arising from Hibernate 2LC in a minute, but wanted to get your thoughts firts. >>>>>> >>>>>> Cheers, >>>>>> >>>>>> [1] https://issues.jboss.org/browse/ISPN-7029 >>>>>> [2] https://github.com/hibernate/hibernate-orm/blob/master/hibernate-infinispan/src/test/java/org/hibernate/test/cache/infinispan/CacheKeysFactoryTest.java#L58 >>>>>> -- >>>>>> Galder Zamarre?o >>>>>> Infinispan, Red Hat >>>>>> >>>>> -- >>>>> Radim Vansa >>>>> JBoss Performance Team >>> -- >>> Radim Vansa >>> JBoss Performance Team >>> > -- Radim Vansa JBoss Performance Team From mudokonman at gmail.com Mon Feb 27 09:31:09 2017 From: mudokonman at gmail.com (William Burns) Date: Mon, 27 Feb 2017 14:31:09 +0000 Subject: [infinispan-dev] Calling getCache with a template and defined configuration Message-ID: When working on another project using Infinispan the code being used was a bit interesting and I don't think our template configuration handling was expecting it do so in such a way. Essentially the code defined a template for a distributed cache as well as some named caches. Then whenever a cache is retrieved it would pass the given name and always the distributed cache template. Unfortunately with the way templates work they essentially redefine a cache first so the actual cache configuration was wiped out. In this example I was able to get the code to change to using a default cache instead, which is the behavior that is needed. The issue though at hand is whether we should allow a user to call getCache in such a way. My initial thought is to have it throw some sort of configuration exception when this is invoked. But there are some possible options. 1. Throw a configuration exception not allowing a user to use a template with an already defined cache. This has a slight disconnect between configuration and runtime, since if a user adds a new definition it could cause runtime issues. 2. Log an error/warning message when this occurs. Is this enough though? Still could have runtime issues that are possibly undetected. 3. Merge the configurations together applying the template first. This would be akin to how default cache works currently, but you would get to define your default template configuration at runtime. This sounded like the best option to me, but the problem is what if someone calls getCache using the same cache name but a different template. This could get hairy as well. Really thinking about the future, disconnecting the cache definition and retrieval would be the best option, but we can't do that this late in the game. What do you guys think? - Will -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20170227/e318eabf/attachment.html From rvansa at redhat.com Mon Feb 27 09:48:50 2017 From: rvansa at redhat.com (Radim Vansa) Date: Mon, 27 Feb 2017 15:48:50 +0100 Subject: [infinispan-dev] Calling getCache with a template and defined configuration In-Reply-To: References: Message-ID: <1df9cc6b-9358-75f9-3240-ba133376bff2@redhat.com> While we could define the behaviour as in 3), I think that this is most likely a configuration error. Therefore, I'd go with 1), and ideally provide a link to FAQ/docs where you'd explain what exactly happened in the exception message. R. On 02/27/2017 03:31 PM, William Burns wrote: > When working on another project using Infinispan the code being used > was a bit interesting and I don't think our template configuration > handling was expecting it do so in such a way. > > Essentially the code defined a template for a distributed cache as > well as some named caches. Then whenever a cache is retrieved it would > pass the given name and always the distributed cache template. > Unfortunately with the way templates work they essentially redefine a > cache first so the actual cache configuration was wiped out. In this > example I was able to get the code to change to using a default cache > instead, which is the behavior that is needed. > > The issue though at hand is whether we should allow a user to call > getCache in such a way. My initial thought is to have it throw some > sort of configuration exception when this is invoked. But there are > some possible options. > > 1. Throw a configuration exception not allowing a user to use a > template with an already defined cache. This has a slight disconnect > between configuration and runtime, since if a user adds a new > definition it could cause runtime issues. > 2. Log an error/warning message when this occurs. Is this enough > though? Still could have runtime issues that are possibly undetected. > 3. Merge the configurations together applying the template first. > This would be akin to how default cache works currently, but you would > get to define your default template configuration at runtime. This > sounded like the best option to me, but the problem is what if someone > calls getCache using the same cache name but a different template. > This could get hairy as well. > > Really thinking about the future, disconnecting the cache definition > and retrieval would be the best option, but we can't do that this late > in the game. > > What do you guys think? > > - Will > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Radim Vansa JBoss Performance Team From dan.berindei at gmail.com Mon Feb 27 09:52:15 2017 From: dan.berindei at gmail.com (Dan Berindei) Date: Mon, 27 Feb 2017 16:52:15 +0200 Subject: [infinispan-dev] Calling getCache with a template and defined configuration In-Reply-To: References: Message-ID: I would go for option 2. We already started disconnecting the cache definition and retrieval, at least `getCache(name)` doesn't define a new cache based on the default configuration any more. So I don't think it would be too much, even at this point, to deprecate all the overloads of `getCache` that can define a new cache and advise users to use `defineConfiguration` instead. Cheers Dan On Mon, Feb 27, 2017 at 4:31 PM, William Burns wrote: > When working on another project using Infinispan the code being used was a > bit interesting and I don't think our template configuration handling was > expecting it do so in such a way. > > Essentially the code defined a template for a distributed cache as well as > some named caches. Then whenever a cache is retrieved it would pass the > given name and always the distributed cache template. Unfortunately with > the way templates work they essentially redefine a cache first so the actual > cache configuration was wiped out. In this example I was able to get the > code to change to using a default cache instead, which is the behavior that > is needed. > > The issue though at hand is whether we should allow a user to call getCache > in such a way. My initial thought is to have it throw some sort of > configuration exception when this is invoked. But there are some possible > options. > > 1. Throw a configuration exception not allowing a user to use a template > with an already defined cache. This has a slight disconnect between > configuration and runtime, since if a user adds a new definition it could > cause runtime issues. > 2. Log an error/warning message when this occurs. Is this enough though? > Still could have runtime issues that are possibly undetected. > 3. Merge the configurations together applying the template first. This > would be akin to how default cache works currently, but you would get to > define your default template configuration at runtime. This sounded like the > best option to me, but the problem is what if someone calls getCache using > the same cache name but a different template. This could get hairy as well. > > Really thinking about the future, disconnecting the cache definition and > retrieval would be the best option, but we can't do that this late in the > game. > > What do you guys think? > > - Will > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev From dan.berindei at gmail.com Mon Feb 27 09:55:00 2017 From: dan.berindei at gmail.com (Dan Berindei) Date: Mon, 27 Feb 2017 16:55:00 +0200 Subject: [infinispan-dev] Calling getCache with a template and defined configuration In-Reply-To: References: Message-ID: I forgot to mention users can define their caches with ... if they want inheritance. So we don't need a way to merge configurations at this level. On Mon, Feb 27, 2017 at 4:52 PM, Dan Berindei wrote: > I would go for option 2. > > We already started disconnecting the cache definition and retrieval, > at least `getCache(name)` doesn't define a new cache based on the > default configuration any more. So I don't think it would be too much, > even at this point, to deprecate all the overloads of `getCache` that > can define a new cache and advise users to use `defineConfiguration` > instead. > > > > Cheers > Dan > > > On Mon, Feb 27, 2017 at 4:31 PM, William Burns wrote: >> When working on another project using Infinispan the code being used was a >> bit interesting and I don't think our template configuration handling was >> expecting it do so in such a way. >> >> Essentially the code defined a template for a distributed cache as well as >> some named caches. Then whenever a cache is retrieved it would pass the >> given name and always the distributed cache template. Unfortunately with >> the way templates work they essentially redefine a cache first so the actual >> cache configuration was wiped out. In this example I was able to get the >> code to change to using a default cache instead, which is the behavior that >> is needed. >> >> The issue though at hand is whether we should allow a user to call getCache >> in such a way. My initial thought is to have it throw some sort of >> configuration exception when this is invoked. But there are some possible >> options. >> >> 1. Throw a configuration exception not allowing a user to use a template >> with an already defined cache. This has a slight disconnect between >> configuration and runtime, since if a user adds a new definition it could >> cause runtime issues. >> 2. Log an error/warning message when this occurs. Is this enough though? >> Still could have runtime issues that are possibly undetected. >> 3. Merge the configurations together applying the template first. This >> would be akin to how default cache works currently, but you would get to >> define your default template configuration at runtime. This sounded like the >> best option to me, but the problem is what if someone calls getCache using >> the same cache name but a different template. This could get hairy as well. >> >> Really thinking about the future, disconnecting the cache definition and >> retrieval would be the best option, but we can't do that this late in the >> game. >> >> What do you guys think? >> >> - Will >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev From mudokonman at gmail.com Mon Feb 27 09:59:41 2017 From: mudokonman at gmail.com (William Burns) Date: Mon, 27 Feb 2017 14:59:41 +0000 Subject: [infinispan-dev] Calling getCache with a template and defined configuration In-Reply-To: <1df9cc6b-9358-75f9-3240-ba133376bff2@redhat.com> References: <1df9cc6b-9358-75f9-3240-ba133376bff2@redhat.com> Message-ID: On Mon, Feb 27, 2017 at 9:50 AM Radim Vansa wrote: > While we could define the behaviour as in 3), I think that this is most > Yeah rereading what I wrote again, it was definitely misleading. 3) was what I wanted when I first found the issue. > likely a configuration error. Therefore, I'd go with 1), and ideally > That is what I was leaning towards as well. > provide a link to FAQ/docs where you'd explain what exactly happened in > the exception message. > Yeah I will make sure we have some stuff added to the template section of the user guide. > > R. > > On 02/27/2017 03:31 PM, William Burns wrote: > > When working on another project using Infinispan the code being used > > was a bit interesting and I don't think our template configuration > > handling was expecting it do so in such a way. > > > > Essentially the code defined a template for a distributed cache as > > well as some named caches. Then whenever a cache is retrieved it would > > pass the given name and always the distributed cache template. > > Unfortunately with the way templates work they essentially redefine a > > cache first so the actual cache configuration was wiped out. In this > > example I was able to get the code to change to using a default cache > > instead, which is the behavior that is needed. > > > > The issue though at hand is whether we should allow a user to call > > getCache in such a way. My initial thought is to have it throw some > > sort of configuration exception when this is invoked. But there are > > some possible options. > > > > 1. Throw a configuration exception not allowing a user to use a > > template with an already defined cache. This has a slight disconnect > > between configuration and runtime, since if a user adds a new > > definition it could cause runtime issues. > > 2. Log an error/warning message when this occurs. Is this enough > > though? Still could have runtime issues that are possibly undetected. > > 3. Merge the configurations together applying the template first. > > This would be akin to how default cache works currently, but you would > > get to define your default template configuration at runtime. This > > sounded like the best option to me, but the problem is what if someone > > calls getCache using the same cache name but a different template. > > This could get hairy as well. > > > > Really thinking about the future, disconnecting the cache definition > > and retrieval would be the best option, but we can't do that this late > > in the game. > > > > What do you guys think? > > > > - Will > > > > > > _______________________________________________ > > infinispan-dev mailing list > > infinispan-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/infinispan-dev > > > -- > Radim Vansa > JBoss Performance Team > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20170227/c30308b7/attachment.html From mudokonman at gmail.com Mon Feb 27 10:09:02 2017 From: mudokonman at gmail.com (William Burns) Date: Mon, 27 Feb 2017 15:09:02 +0000 Subject: [infinispan-dev] Calling getCache with a template and defined configuration In-Reply-To: References: Message-ID: On Mon, Feb 27, 2017 at 9:55 AM Dan Berindei wrote: > I would go for option 2. > Do you think a WARN message will be enough? I am a bit weary about this option myself. > > We already started disconnecting the cache definition and retrieval, > at least `getCache(name)` doesn't define a new cache based on the > default configuration any more. So I don't think it would be too much, > even at this point, to deprecate all the overloads of `getCache` that > can define a new cache and advise users to use `defineConfiguration` > instead. > Hrmm I like the idea of deprecating the overloads :) > > > > Cheers > Dan > > > On Mon, Feb 27, 2017 at 4:31 PM, William Burns > wrote: > > When working on another project using Infinispan the code being used was > a > > bit interesting and I don't think our template configuration handling was > > expecting it do so in such a way. > > > > Essentially the code defined a template for a distributed cache as well > as > > some named caches. Then whenever a cache is retrieved it would pass the > > given name and always the distributed cache template. Unfortunately with > > the way templates work they essentially redefine a cache first so the > actual > > cache configuration was wiped out. In this example I was able to get the > > code to change to using a default cache instead, which is the behavior > that > > is needed. > > > > The issue though at hand is whether we should allow a user to call > getCache > > in such a way. My initial thought is to have it throw some sort of > > configuration exception when this is invoked. But there are some possible > > options. > > > > 1. Throw a configuration exception not allowing a user to use a template > > with an already defined cache. This has a slight disconnect between > > configuration and runtime, since if a user adds a new definition it could > > cause runtime issues. > > 2. Log an error/warning message when this occurs. Is this enough though? > > Still could have runtime issues that are possibly undetected. > > 3. Merge the configurations together applying the template first. This > > would be akin to how default cache works currently, but you would get to > > define your default template configuration at runtime. This sounded like > the > > best option to me, but the problem is what if someone calls getCache > using > > the same cache name but a different template. This could get hairy as > well. > > > > Really thinking about the future, disconnecting the cache definition and > > retrieval would be the best option, but we can't do that this late in the > > game. > > > > What do you guys think? > > > > - Will > > > > _______________________________________________ > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20170227/47249079/attachment-0001.html From ttarrant at redhat.com Mon Feb 27 11:31:50 2017 From: ttarrant at redhat.com (Tristan Tarrant) Date: Mon, 27 Feb 2017 17:31:50 +0100 Subject: [infinispan-dev] Weekly IRC meeting logs 2017-02-27 Message-ID: Hi all, the logs for the meeting we held today are available at http://transcripts.jboss.org/meeting/irc.freenode.org/infinispan/2017/infinispan.2017-02-27-15.00.log.html Tristan -- Tristan Tarrant Infinispan Lead JBoss, a division of Red Hat From mudokonman at gmail.com Tue Feb 28 16:51:44 2017 From: mudokonman at gmail.com (William Burns) Date: Tue, 28 Feb 2017 21:51:44 +0000 Subject: [infinispan-dev] Calling getCache with a template and defined configuration In-Reply-To: References: Message-ID: So while I was trying to work on this, I have to admit I am even more torn in regards to what to do. Looking at [1] it looks like the template should only be applied if the cache configuration is not currently defined. Unfortunately it doesn't work this way and always applies this template to any existing configuration. So I am thinking an alternative is to instead make it work as the documentation states, only using the template if the cache is not currently defined. This seems more logical to me at least. With that change the getCache(String, String) could stay as long as it is documented that a template is only applied if no cache configuration exists. What do you guys think? [1] https://github.com/infinispan/infinispan/blob/master/core/src/main/java/org/infinispan/manager/EmbeddedCacheManager.java#L84 On Mon, Feb 27, 2017 at 10:09 AM William Burns wrote: > On Mon, Feb 27, 2017 at 9:55 AM Dan Berindei > wrote: > > I would go for option 2. > > > Do you think a WARN message will be enough? I am a bit weary about this > option myself. > > > > We already started disconnecting the cache definition and retrieval, > at least `getCache(name)` doesn't define a new cache based on the > default configuration any more. So I don't think it would be too much, > even at this point, to deprecate all the overloads of `getCache` that > can define a new cache and advise users to use `defineConfiguration` > instead. > > > Hrmm I like the idea of deprecating the overloads :) > > > > > > Cheers > Dan > > > On Mon, Feb 27, 2017 at 4:31 PM, William Burns > wrote: > > When working on another project using Infinispan the code being used was > a > > bit interesting and I don't think our template configuration handling was > > expecting it do so in such a way. > > > > Essentially the code defined a template for a distributed cache as well > as > > some named caches. Then whenever a cache is retrieved it would pass the > > given name and always the distributed cache template. Unfortunately with > > the way templates work they essentially redefine a cache first so the > actual > > cache configuration was wiped out. In this example I was able to get the > > code to change to using a default cache instead, which is the behavior > that > > is needed. > > > > The issue though at hand is whether we should allow a user to call > getCache > > in such a way. My initial thought is to have it throw some sort of > > configuration exception when this is invoked. But there are some possible > > options. > > > > 1. Throw a configuration exception not allowing a user to use a template > > with an already defined cache. This has a slight disconnect between > > configuration and runtime, since if a user adds a new definition it could > > cause runtime issues. > > 2. Log an error/warning message when this occurs. Is this enough though? > > Still could have runtime issues that are possibly undetected. > > 3. Merge the configurations together applying the template first. This > > would be akin to how default cache works currently, but you would get to > > define your default template configuration at runtime. This sounded like > the > > best option to me, but the problem is what if someone calls getCache > using > > the same cache name but a different template. This could get hairy as > well. > > > > Really thinking about the future, disconnecting the cache definition and > > retrieval would be the best option, but we can't do that this late in the > > game. > > > > What do you guys think? > > > > - Will > > > > _______________________________________________ > > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20170228/93395038/attachment.html