From ttarrant at redhat.com Wed Jun 3 06:04:28 2015 From: ttarrant at redhat.com (Tristan Tarrant) Date: Wed, 03 Jun 2015 12:04:28 +0200 Subject: [infinispan-dev] Infinispan Weekly IRC meeting 2015-06-01 Message-ID: <556ED12C.2050905@redhat.com> Here are the meeting minutes for this week's meeting: http://transcripts.jboss.org/meeting/irc.freenode.org/infinispan/2015/infinispan.2015-06-01-14.02.log.html Tristan -- Tristan Tarrant Infinispan Lead JBoss, a division of Red Hat From rory.odonnell at oracle.com Fri Jun 5 05:07:03 2015 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Fri, 05 Jun 2015 10:07:03 +0100 Subject: [infinispan-dev] Early Access builds for JDK 9 b66 and JDK 8u60 b18 are available on java.net Message-ID: <557166B7.2040104@oracle.com> Hi Galder, Early Access build for JDK 8u60 b18 is available on java.net, summary of changes are listed here. As we enter the later phases of development for JDK 8u60, please log any show stoppers as soon as possible. Early Access build for JDK 9 b66 is available on java.net, summary of changes are listed here . The JDK 9 schedule of record is available on the JDK 9 Project page: http://openjdk.java.net/projects/jdk9 At https://wiki.openjdk.java.net/display/Adoption/JDK+9+Outreach you can find a (preliminary) list of other changes that might affect your project's code in JDK 9, and other things to consider when testing with JDK 9. I'd be curious to know if there is anything on that list you'd consider to have an effect on your project. Please keep in mind that as JEPs and others changes are integrated into (or out of) JDK 9, the list will change over time. 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/20150605/93ecc5d4/attachment.html From galder at redhat.com Fri Jun 5 05:44:03 2015 From: galder at redhat.com (=?utf-8?Q?Galder_Zamarre=C3=B1o?=) Date: Fri, 5 Jun 2015 11:44:03 +0200 Subject: [infinispan-dev] Cache Java 8 API proposal - 2nd draft Message-ID: <7E78289F-731F-4741-9AAD-71827CBCC537@redhat.com> Hi all, Thanks to all who contributed to the 1st draft revision. We've taken all that input and created a separate Github project where we have prototytped the 2nd draft of the advanced Java 8 based Infinispan API. The starting point for you should be FunctionalMap [1]. Here's a brief summary the major changes since the 1st draft: 1. FunctionalMap has been separated into 3 sub-interfaces, one for read only operations, one for write only operations, and a final one for read-write operations. This separation makes it clear the purpouse of each operation and adds a nice layer of type safety, e.g. you can't write with a read-only map, or you can't read with a write-only map. 2. Param has been added, which is equivalent to Infinispan Flag with the added benefit that it can carry values. There's no such example right now but we could have in the future. 3. MetaParam has been added. This is a much more flexible and extensible option compared to the current Infinispan's Metadata. 4. For operations returning mutiple returns, or working on multiple elements, we've exposed something called Traversable, which is a subset of Java's Stream. See its javadoc to find out more. Kudos to Will for his work on distributed streams which has helped hugely with the design of Traversable. 5. Listeners have been added, again separating between read-write and write-only listeners (JCache does not offer read-only listeners, e.g. cache entry visited, and hence I think we'll drop our cache entry visited listener at some point). 6. Will and I have explored marshalling aspects of lambdas, and there are some interesting ways to reduce their costs by +90%! See MarshallingTest for different options to marshall both capturing and non-capturing lambdas and their cost in terms of payload sizes. Some final notes: * Please do read the javadocs, they contain a lot of information on the reasons behind the design. * To find out how the different functional map variants are used, look at ConcurrentMapDecorator and JCacheDecorator who use them to implement the ConcurrentMap and javax.cache.Cache APIs respectively. * FunctionalMapTest contains examples on how to use functional map variants for other operations which we deeply care about, e.g. Hot Rod atomic version-based replace function. Special thanks to Mario Fusco (Java 8 In Action book co-author) for his feedback throughout this 2nd draft design process. Cheers, [1] https://github.com/infinispan/proto8/blob/master/src/main/java/org/infinispan/api/v8/FunctionalMap.java -- Galder Zamarre?o galder at redhat.com From rvansa at redhat.com Fri Jun 5 08:15:12 2015 From: rvansa at redhat.com (Radim Vansa) Date: Fri, 05 Jun 2015 14:15:12 +0200 Subject: [infinispan-dev] Cache Java 8 API proposal - 2nd draft In-Reply-To: <7E78289F-731F-4741-9AAD-71827CBCC537@redhat.com> References: <7E78289F-731F-4741-9AAD-71827CBCC537@redhat.com> Message-ID: <557192D0.5070503@redhat.com> Is the marshalling comparison really fair? The lambda-table-based approach removes the need for serializing the class definition, but in practice - is the class definition always send around with each RPC? If it is so, it seems like a serious flaw of the current codebase, and not something occurring only for the functional interface. In case that we keep the marshallers around, we should marshall second RPC (with the same lambda and another instance of the same captured class), and look on the diff rather than on the first serialized instance. Radim On 06/05/2015 11:44 AM, Galder Zamarre?o wrote: > Hi all, > > Thanks to all who contributed to the 1st draft revision. We've taken all that input and created a separate Github project where we have prototytped the 2nd draft of the advanced Java 8 based Infinispan API. The starting point for you should be FunctionalMap [1]. > > Here's a brief summary the major changes since the 1st draft: > > 1. FunctionalMap has been separated into 3 sub-interfaces, one for read only operations, one for write only operations, and a final one for read-write operations. This separation makes it clear the purpouse of each operation and adds a nice layer of type safety, e.g. you can't write with a read-only map, or you can't read with a write-only map. > > 2. Param has been added, which is equivalent to Infinispan Flag with the added benefit that it can carry values. There's no such example right now but we could have in the future. > > 3. MetaParam has been added. This is a much more flexible and extensible option compared to the current Infinispan's Metadata. > > 4. For operations returning mutiple returns, or working on multiple elements, we've exposed something called Traversable, which is a subset of Java's Stream. See its javadoc to find out more. Kudos to Will for his work on distributed streams which has helped hugely with the design of Traversable. > > 5. Listeners have been added, again separating between read-write and write-only listeners (JCache does not offer read-only listeners, e.g. cache entry visited, and hence I think we'll drop our cache entry visited listener at some point). > > 6. Will and I have explored marshalling aspects of lambdas, and there are some interesting ways to reduce their costs by +90%! See MarshallingTest for different options to marshall both capturing and non-capturing lambdas and their cost in terms of payload sizes. > > Some final notes: > > * Please do read the javadocs, they contain a lot of information on the reasons behind the design. > > * To find out how the different functional map variants are used, look at ConcurrentMapDecorator and JCacheDecorator who use them to implement the ConcurrentMap and javax.cache.Cache APIs respectively. > > * FunctionalMapTest contains examples on how to use functional map variants for other operations which we deeply care about, e.g. Hot Rod atomic version-based replace function. > > Special thanks to Mario Fusco (Java 8 In Action book co-author) for his feedback throughout this 2nd draft design process. > > Cheers, > > [1] https://github.com/infinispan/proto8/blob/master/src/main/java/org/infinispan/api/v8/FunctionalMap.java > -- > Galder Zamarre?o > galder at redhat.com > > > > > > _______________________________________________ > 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 Fri Jun 5 11:46:36 2015 From: galder at redhat.com (=?utf-8?Q?Galder_Zamarre=C3=B1o?=) Date: Fri, 5 Jun 2015 17:46:36 +0200 Subject: [infinispan-dev] Mysterious "java.net.SocketException: Socket closed" Message-ID: Hi all, Re: https://issues.jboss.org/browse/ISPN-5506 I'm encountering an odd issue with the Apache Http Commons client when talking to a Netty-based RESTEasy server. I'm randomly getting "java.net.SocketException: Socket closed" when constructing a brand new Socket to talk to the server 1/2ms after starting the process of connecting a new socket [1]. This is happening with both client and server in my MBP, and running our testsuite which uses localhost addresses. The log attached shows log for both the server and client which run on same JVM. Any ideas could be causing it? If the server was not up, the exception would be different, like connection refused or something like that. I've seen "Socket closed" before but that normally means that a Socket that's been closed is being reused, but that doesn't seem to be the case here since DefaultProtocolSocketFactory always creates a brand new Socket. I was wondering about using Byteman to trace so particular calls to JDK methods maybe? Also, this only seems to happen in my OSX env. In our CI env, it seems to run fine all the time. Cheers, -- Galder Zamarre?o galder at redhat.com From dan.berindei at gmail.com Fri Jun 5 12:01:07 2015 From: dan.berindei at gmail.com (Dan Berindei) Date: Fri, 5 Jun 2015 19:01:07 +0300 Subject: [infinispan-dev] Mysterious "java.net.SocketException: Socket closed" In-Reply-To: References: Message-ID: I would start with dtrace, to see the actual error code returned by the socket() system call. Dan On Fri, Jun 5, 2015 at 6:46 PM, Galder Zamarre?o wrote: > Hi all, > > Re: https://issues.jboss.org/browse/ISPN-5506 > > I'm encountering an odd issue with the Apache Http Commons client when talking to a Netty-based RESTEasy server. I'm randomly getting "java.net.SocketException: Socket closed" when constructing a brand new Socket to talk to the server 1/2ms after starting the process of connecting a new socket [1]. This is happening with both client and server in my MBP, and running our testsuite which uses localhost addresses. The log attached shows log for both the server and client which run on same JVM. > > Any ideas could be causing it? If the server was not up, the exception would be different, like connection refused or something like that. I've seen "Socket closed" before but that normally means that a Socket that's been closed is being reused, but that doesn't seem to be the case here since DefaultProtocolSocketFactory always creates a brand new Socket. > > I was wondering about using Byteman to trace so particular calls to JDK methods maybe? > > Also, this only seems to happen in my OSX env. In our CI env, it seems to run fine all the time. > > Cheers, > -- > Galder Zamarre?o > galder at redhat.com > > > > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev From galder at redhat.com Fri Jun 5 12:22:45 2015 From: galder at redhat.com (=?utf-8?Q?Galder_Zamarre=C3=B1o?=) Date: Fri, 5 Jun 2015 18:22:45 +0200 Subject: [infinispan-dev] Infinispan Weekly IRC meeting 2015-06-01 In-Reply-To: <556ED12C.2050905@redhat.com> References: <556ED12C.2050905@redhat.com> Message-ID: <92A0B6D6-ACD3-4D3B-B581-EEFC8DEF572B@redhat.com> Thanks for sending that, forgot about it! :) > On 3 Jun 2015, at 12:04, Tristan Tarrant wrote: > > Here are the meeting minutes for this week's meeting: > > http://transcripts.jboss.org/meeting/irc.freenode.org/infinispan/2015/infinispan.2015-06-01-14.02.log.html > > 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 -- Galder Zamarre?o galder at redhat.com From duzc2dtw at gmail.com Sun Jun 7 23:30:48 2015 From: duzc2dtw at gmail.com (=?UTF-8?B?5p2c5aSp5b6u?=) Date: Mon, 8 Jun 2015 11:30:48 +0800 Subject: [infinispan-dev] How to make Snapshot of whole data saved in infinispan ? Message-ID: I put all my data in infinispan , within some servers. Some time , I hope I could take a snapshot of data in infinispan , so that I could roll back to any point of time I made the snapshot. Could any one tell me how to make it come true ? Thanks for reading my poor english . -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20150608/dc577280/attachment.html From galder at redhat.com Mon Jun 8 03:37:33 2015 From: galder at redhat.com (=?utf-8?Q?Galder_Zamarre=C3=B1o?=) Date: Mon, 8 Jun 2015 09:37:33 +0200 Subject: [infinispan-dev] Cache Java 8 API proposal - 2nd draft In-Reply-To: <557192D0.5070503@redhat.com> References: <7E78289F-731F-4741-9AAD-71827CBCC537@redhat.com> <557192D0.5070503@redhat.com> Message-ID: <667C5F67-0178-44B0-BE0C-4BE790E9F6A0@redhat.com> > On 5 Jun 2015, at 14:15, Radim Vansa wrote: > > Is the marshalling comparison really fair? The lambda-table-based > approach removes the need for serializing the class definition, but in > practice - is the class definition always send around with each RPC? ^ We've extensively added Infinispan Externalizers (which use the Object Table approach shown in MarshallingTests) to reduce the size of our payloads, and indeed for all those, no class definitions are sent around. So, as long as the types of those are known to us, we can use such approach and avoid expensive serialization. NOTE: JBoss Marshalling's Externalizers are more expensive than ObjectTable based approach but I can't remember why, it might be cos when you use those, it might send the externalizer class' class definition around, but not sure. > If > it is so, it seems like a serious flaw of the current codebase, and not > something occurring only for the functional interface. In case that we > keep the marshallers around, we should marshall second RPC (with the > same lambda and another instance of the same captured class), and look > on the diff rather than on the first serialized instance. ^ Hmmm, not sure what you mean there exactly. > > Radim > > On 06/05/2015 11:44 AM, Galder Zamarre?o wrote: >> Hi all, >> >> Thanks to all who contributed to the 1st draft revision. We've taken all that input and created a separate Github project where we have prototytped the 2nd draft of the advanced Java 8 based Infinispan API. The starting point for you should be FunctionalMap [1]. >> >> Here's a brief summary the major changes since the 1st draft: >> >> 1. FunctionalMap has been separated into 3 sub-interfaces, one for read only operations, one for write only operations, and a final one for read-write operations. This separation makes it clear the purpouse of each operation and adds a nice layer of type safety, e.g. you can't write with a read-only map, or you can't read with a write-only map. >> >> 2. Param has been added, which is equivalent to Infinispan Flag with the added benefit that it can carry values. There's no such example right now but we could have in the future. >> >> 3. MetaParam has been added. This is a much more flexible and extensible option compared to the current Infinispan's Metadata. >> >> 4. For operations returning mutiple returns, or working on multiple elements, we've exposed something called Traversable, which is a subset of Java's Stream. See its javadoc to find out more. Kudos to Will for his work on distributed streams which has helped hugely with the design of Traversable. >> >> 5. Listeners have been added, again separating between read-write and write-only listeners (JCache does not offer read-only listeners, e.g. cache entry visited, and hence I think we'll drop our cache entry visited listener at some point). >> >> 6. Will and I have explored marshalling aspects of lambdas, and there are some interesting ways to reduce their costs by +90%! See MarshallingTest for different options to marshall both capturing and non-capturing lambdas and their cost in terms of payload sizes. >> >> Some final notes: >> >> * Please do read the javadocs, they contain a lot of information on the reasons behind the design. >> >> * To find out how the different functional map variants are used, look at ConcurrentMapDecorator and JCacheDecorator who use them to implement the ConcurrentMap and javax.cache.Cache APIs respectively. >> >> * FunctionalMapTest contains examples on how to use functional map variants for other operations which we deeply care about, e.g. Hot Rod atomic version-based replace function. >> >> Special thanks to Mario Fusco (Java 8 In Action book co-author) for his feedback throughout this 2nd draft design process. >> >> Cheers, >> >> [1] https://github.com/infinispan/proto8/blob/master/src/main/java/org/infinispan/api/v8/FunctionalMap.java >> -- >> Galder Zamarre?o >> galder at redhat.com >> >> >> >> >> >> _______________________________________________ >> 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 -- Galder Zamarre?o galder at redhat.com From slaskawi at redhat.com Mon Jun 8 04:09:49 2015 From: slaskawi at redhat.com (=?UTF-8?B?U2ViYXN0aWFuIMWBYXNrYXdpZWM=?=) Date: Mon, 08 Jun 2015 10:09:49 +0200 Subject: [infinispan-dev] How to make Snapshot of whole data saved in infinispan ? In-Reply-To: References: Message-ID: <55754DCD.2050101@redhat.com> Hi! I would recommend looking into Persistence part of Infinispan's documentation [1] especially write-behind section [2]. Maybe this solution would work even better than flushing cache data into store at fixed time rate. If not, you may write your own custom cache store and implement your logic there. In that case I recommend looking at Custom Cache Store Archetype [3], which might be used for generating implementation draft. Thanks Sebastian [1] http://infinispan.org/docs/7.2.x/user_guide/user_guide.html#_persistence [2] http://infinispan.org/docs/7.2.x/user_guide/user_guide.html#_write_behind_asynchronous [3] https://github.com/infinispan/infinispan-cachestore-archetype On 06/08/2015 05:30 AM, ??? wrote: > I put all my data in infinispan , within some servers. > Some time , I hope I could take a snapshot of data in infinispan , > so that I could roll back to any point of time I made the snapshot. > > Could any one tell me how to make it come true ? > > Thanks for reading my poor english . > > > > _______________________________________________ > 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/20150608/6d7507b3/attachment.html From dan.berindei at gmail.com Mon Jun 8 04:41:34 2015 From: dan.berindei at gmail.com (Dan Berindei) Date: Mon, 8 Jun 2015 11:41:34 +0300 Subject: [infinispan-dev] Cache Java 8 API proposal - 2nd draft In-Reply-To: <667C5F67-0178-44B0-BE0C-4BE790E9F6A0@redhat.com> References: <7E78289F-731F-4741-9AAD-71827CBCC537@redhat.com> <557192D0.5070503@redhat.com> <667C5F67-0178-44B0-BE0C-4BE790E9F6A0@redhat.com> Message-ID: On Mon, Jun 8, 2015 at 10:37 AM, Galder Zamarre?o wrote: > >> On 5 Jun 2015, at 14:15, Radim Vansa wrote: >> >> Is the marshalling comparison really fair? The lambda-table-based >> approach removes the need for serializing the class definition, but in >> practice - is the class definition always send around with each RPC? > > ^ We've extensively added Infinispan Externalizers (which use the Object Table approach shown in MarshallingTests) to reduce the size of our payloads, and indeed for all those, no class definitions are sent around. So, as long as the types of those are known to us, we can use such approach and avoid expensive serialization. > > NOTE: JBoss Marshalling's Externalizers are more expensive than ObjectTable based approach but I can't remember why, it might be cos when you use those, it might send the externalizer class' class definition around, but not sure. I think the Simple/DynamicClassTable classes in WildFly take care of writing only a class id in the stream, instead of the class name, same as our ExternalizerTable but using JBoss Marshalling's Externalizers. I don't know if there's any performance difference between the two approaches, but I assume they must be pretty similar. > >> If >> it is so, it seems like a serious flaw of the current codebase, and not >> something occurring only for the functional interface. In case that we >> keep the marshallers around, we should marshall second RPC (with the >> same lambda and another instance of the same captured class), and look >> on the diff rather than on the first serialized instance. > > ^ Hmmm, not sure what you mean there exactly. > >> >> Radim >> >> On 06/05/2015 11:44 AM, Galder Zamarre?o wrote: >>> Hi all, >>> >>> Thanks to all who contributed to the 1st draft revision. We've taken all that input and created a separate Github project where we have prototytped the 2nd draft of the advanced Java 8 based Infinispan API. The starting point for you should be FunctionalMap [1]. >>> >>> Here's a brief summary the major changes since the 1st draft: >>> >>> 1. FunctionalMap has been separated into 3 sub-interfaces, one for read only operations, one for write only operations, and a final one for read-write operations. This separation makes it clear the purpouse of each operation and adds a nice layer of type safety, e.g. you can't write with a read-only map, or you can't read with a write-only map. >>> >>> 2. Param has been added, which is equivalent to Infinispan Flag with the added benefit that it can carry values. There's no such example right now but we could have in the future. >>> >>> 3. MetaParam has been added. This is a much more flexible and extensible option compared to the current Infinispan's Metadata. >>> >>> 4. For operations returning mutiple returns, or working on multiple elements, we've exposed something called Traversable, which is a subset of Java's Stream. See its javadoc to find out more. Kudos to Will for his work on distributed streams which has helped hugely with the design of Traversable. >>> >>> 5. Listeners have been added, again separating between read-write and write-only listeners (JCache does not offer read-only listeners, e.g. cache entry visited, and hence I think we'll drop our cache entry visited listener at some point). >>> >>> 6. Will and I have explored marshalling aspects of lambdas, and there are some interesting ways to reduce their costs by +90%! See MarshallingTest for different options to marshall both capturing and non-capturing lambdas and their cost in terms of payload sizes. >>> >>> Some final notes: >>> >>> * Please do read the javadocs, they contain a lot of information on the reasons behind the design. >>> >>> * To find out how the different functional map variants are used, look at ConcurrentMapDecorator and JCacheDecorator who use them to implement the ConcurrentMap and javax.cache.Cache APIs respectively. >>> >>> * FunctionalMapTest contains examples on how to use functional map variants for other operations which we deeply care about, e.g. Hot Rod atomic version-based replace function. >>> >>> Special thanks to Mario Fusco (Java 8 In Action book co-author) for his feedback throughout this 2nd draft design process. >>> >>> Cheers, >>> >>> [1] https://github.com/infinispan/proto8/blob/master/src/main/java/org/infinispan/api/v8/FunctionalMap.java >>> -- >>> Galder Zamarre?o >>> galder at redhat.com >>> >>> >>> >>> >>> >>> _______________________________________________ >>> 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 > > > -- > Galder Zamarre?o > galder at redhat.com > > > > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev From rvansa at redhat.com Mon Jun 8 04:57:41 2015 From: rvansa at redhat.com (Radim Vansa) Date: Mon, 08 Jun 2015 10:57:41 +0200 Subject: [infinispan-dev] Cache Java 8 API proposal - 2nd draft In-Reply-To: References: <7E78289F-731F-4741-9AAD-71827CBCC537@redhat.com> <557192D0.5070503@redhat.com> <667C5F67-0178-44B0-BE0C-4BE790E9F6A0@redhat.com> Message-ID: <55755905.9030001@redhat.com> On 06/08/2015 10:41 AM, Dan Berindei wrote: > On Mon, Jun 8, 2015 at 10:37 AM, Galder Zamarre?o wrote: >>> On 5 Jun 2015, at 14:15, Radim Vansa wrote: >>> >>> Is the marshalling comparison really fair? The lambda-table-based >>> approach removes the need for serializing the class definition, but in >>> practice - is the class definition always send around with each RPC? >> ^ We've extensively added Infinispan Externalizers (which use the Object Table approach shown in MarshallingTests) to reduce the size of our payloads, and indeed for all those, no class definitions are sent around. So, as long as the types of those are known to us, we can use such approach and avoid expensive serialization. >> >> NOTE: JBoss Marshalling's Externalizers are more expensive than ObjectTable based approach but I can't remember why, it might be cos when you use those, it might send the externalizer class' class definition around, but not sure. > > I think the Simple/DynamicClassTable classes in WildFly take care of > writing only a class id in the stream, instead of the class name, same > as our ExternalizerTable but using JBoss Marshalling's Externalizers. > I don't know if there's any performance difference between the two > approaches, but I assume they must be pretty similar. > >>> If >>> it is so, it seems like a serious flaw of the current codebase, and not >>> something occurring only for the functional interface. In case that we >>> keep the marshallers around, we should marshall second RPC (with the >>> same lambda and another instance of the same captured class), and look >>> on the diff rather than on the first serialized instance. >> ^ Hmmm, not sure what you mean there exactly. I meant that in case that the class definition is not sent with each RPC but only once/few times, we should not pay attention to the cost of sending the definition. As the test marshalls single RPC, the definition is always marshalled and accounted. So, if I understand that correctly, for user classes that do not register externalizers (I guess the registration is not automatic), the definition is sent around with each RPC, right? Radim >> >>> Radim >>> >>> On 06/05/2015 11:44 AM, Galder Zamarre?o wrote: >>>> Hi all, >>>> >>>> Thanks to all who contributed to the 1st draft revision. We've taken all that input and created a separate Github project where we have prototytped the 2nd draft of the advanced Java 8 based Infinispan API. The starting point for you should be FunctionalMap [1]. >>>> >>>> Here's a brief summary the major changes since the 1st draft: >>>> >>>> 1. FunctionalMap has been separated into 3 sub-interfaces, one for read only operations, one for write only operations, and a final one for read-write operations. This separation makes it clear the purpouse of each operation and adds a nice layer of type safety, e.g. you can't write with a read-only map, or you can't read with a write-only map. >>>> >>>> 2. Param has been added, which is equivalent to Infinispan Flag with the added benefit that it can carry values. There's no such example right now but we could have in the future. >>>> >>>> 3. MetaParam has been added. This is a much more flexible and extensible option compared to the current Infinispan's Metadata. >>>> >>>> 4. For operations returning mutiple returns, or working on multiple elements, we've exposed something called Traversable, which is a subset of Java's Stream. See its javadoc to find out more. Kudos to Will for his work on distributed streams which has helped hugely with the design of Traversable. >>>> >>>> 5. Listeners have been added, again separating between read-write and write-only listeners (JCache does not offer read-only listeners, e.g. cache entry visited, and hence I think we'll drop our cache entry visited listener at some point). >>>> >>>> 6. Will and I have explored marshalling aspects of lambdas, and there are some interesting ways to reduce their costs by +90%! See MarshallingTest for different options to marshall both capturing and non-capturing lambdas and their cost in terms of payload sizes. >>>> >>>> Some final notes: >>>> >>>> * Please do read the javadocs, they contain a lot of information on the reasons behind the design. >>>> >>>> * To find out how the different functional map variants are used, look at ConcurrentMapDecorator and JCacheDecorator who use them to implement the ConcurrentMap and javax.cache.Cache APIs respectively. >>>> >>>> * FunctionalMapTest contains examples on how to use functional map variants for other operations which we deeply care about, e.g. Hot Rod atomic version-based replace function. >>>> >>>> Special thanks to Mario Fusco (Java 8 In Action book co-author) for his feedback throughout this 2nd draft design process. >>>> >>>> Cheers, >>>> >>>> [1] https://github.com/infinispan/proto8/blob/master/src/main/java/org/infinispan/api/v8/FunctionalMap.java >>>> -- >>>> Galder Zamarre?o >>>> galder at redhat.com >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 >> >> -- >> Galder Zamarre?o >> galder at redhat.com >> >> >> >> >> >> _______________________________________________ >> 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 Jun 8 05:02:40 2015 From: rvansa at redhat.com (Radim Vansa) Date: Mon, 08 Jun 2015 11:02:40 +0200 Subject: [infinispan-dev] How to make Snapshot of whole data saved in infinispan ? In-Reply-To: <55754DCD.2050101@redhat.com> References: <55754DCD.2050101@redhat.com> Message-ID: <55755A30.7070101@redhat.com> I believe that such discussion (on Infinispan use, not development) should take place on forums instead. However, if you're looking for a way to get consistent snapshot of all data of running cache (where writes can still take place), such functionality is not currently available. For iterating over all data (however without that snapshot guarantees) you can use Distributed Entry Retrievers [1]. Radim [1] http://infinispan.org/docs/7.2.x/user_guide/user_guide.html#_entry_retrieval On 06/08/2015 10:09 AM, Sebastian ?askawiec wrote: > Hi! > > I would recommend looking into Persistence part of Infinispan's > documentation [1] especially write-behind section [2]. Maybe this > solution would work even better than flushing cache data into store at > fixed time rate. > > If not, you may write your own custom cache store and implement your > logic there. In that case I recommend looking at Custom Cache Store > Archetype [3], which might be used for generating implementation draft. > > Thanks > Sebastian > > [1] > http://infinispan.org/docs/7.2.x/user_guide/user_guide.html#_persistence > [2] > http://infinispan.org/docs/7.2.x/user_guide/user_guide.html#_write_behind_asynchronous > [3] https://github.com/infinispan/infinispan-cachestore-archetype > > On 06/08/2015 05:30 AM, ??? wrote: >> I put all my data in infinispan , within some servers. >> Some time , I hope I could take a snapshot of data in infinispan , >> so that I could roll back to any point of time I made the snapshot. >> >> Could any one tell me how to make it come true ? >> >> Thanks for reading my poor english . >> >> >> >> _______________________________________________ >> 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 Mon Jun 8 11:37:57 2015 From: galder at redhat.com (=?utf-8?Q?Galder_Zamarre=C3=B1o?=) Date: Mon, 8 Jun 2015 17:37:57 +0200 Subject: [infinispan-dev] Cache Java 8 API proposal - 2nd draft In-Reply-To: <55755905.9030001@redhat.com> References: <7E78289F-731F-4741-9AAD-71827CBCC537@redhat.com> <557192D0.5070503@redhat.com> <667C5F67-0178-44B0-BE0C-4BE790E9F6A0@redhat.com> <55755905.9030001@redhat.com> Message-ID: > On 8 Jun 2015, at 10:57, Radim Vansa wrote: > > On 06/08/2015 10:41 AM, Dan Berindei wrote: >> On Mon, Jun 8, 2015 at 10:37 AM, Galder Zamarre?o wrote: >>>> On 5 Jun 2015, at 14:15, Radim Vansa wrote: >>>> >>>> Is the marshalling comparison really fair? The lambda-table-based >>>> approach removes the need for serializing the class definition, but in >>>> practice - is the class definition always send around with each RPC? >>> ^ We've extensively added Infinispan Externalizers (which use the Object Table approach shown in MarshallingTests) to reduce the size of our payloads, and indeed for all those, no class definitions are sent around. So, as long as the types of those are known to us, we can use such approach and avoid expensive serialization. >>> >>> NOTE: JBoss Marshalling's Externalizers are more expensive than ObjectTable based approach but I can't remember why, it might be cos when you use those, it might send the externalizer class' class definition around, but not sure. >> >> I think the Simple/DynamicClassTable classes in WildFly take care of >> writing only a class id in the stream, instead of the class name, same >> as our ExternalizerTable but using JBoss Marshalling's Externalizers. >> I don't know if there's any performance difference between the two >> approaches, but I assume they must be pretty similar. >> >>>> If >>>> it is so, it seems like a serious flaw of the current codebase, and not >>>> something occurring only for the functional interface. In case that we >>>> keep the marshallers around, we should marshall second RPC (with the >>>> same lambda and another instance of the same captured class), and look >>>> on the diff rather than on the first serialized instance. >>> ^ Hmmm, not sure what you mean there exactly. > > > I meant that in case that the class definition is not sent with each RPC > but only once/few times, we should not pay attention to the cost of > sending the definition. As the test marshalls single RPC, the definition > is always marshalled and accounted. ^ There are multiple tests in MarshallingTests, some of which marshall the definition and others not, and I printed payload sizes: -> testObjectTableCapturingLambda payload is 43 bytes testSerializableApplyLambda payload is 587 bytes testExternalizerNonCapturingLambda payload is 160 bytes testExternalizerCapturingLambda payload is 192 bytes testNonCapturingLambdaAndSerializable payload is 501 bytes testSerializableNonCapturingLambda payload is 597 byt -> testObjectTableNonCapturingLambda payload is 3 bytes We're not going to go with any of the approaches that are over 100 bytes. The most efficient one, as you'd expect, is the Object Table approach with a Non-Capturing lambda where the size of the payload is 3 bytes. Clearly here no definition is marshalled at all. Second one is the one where the lambda captures an external element and hence that needs to be shipped every time. > So, if I understand that correctly, for user classes that do not > register externalizers (I guess the registration is not automatic), the > definition is sent around with each RPC, right? In that case yeah, to get that to work, you'd have to extend Serializable and then you pay the penalty. This is the whole point why we came up with Externalizers and the framework around it. If you want get running as quickly as possible, make whatever you want to ship around extend Serializable but for ultimate performance, pre-registration of externalizers is the way to go, and the same approach works just as well with function/predicates...etc. Cheers, > > Radim > >>> >>>> Radim >>>> >>>> On 06/05/2015 11:44 AM, Galder Zamarre?o wrote: >>>>> Hi all, >>>>> >>>>> Thanks to all who contributed to the 1st draft revision. We've taken all that input and created a separate Github project where we have prototytped the 2nd draft of the advanced Java 8 based Infinispan API. The starting point for you should be FunctionalMap [1]. >>>>> >>>>> Here's a brief summary the major changes since the 1st draft: >>>>> >>>>> 1. FunctionalMap has been separated into 3 sub-interfaces, one for read only operations, one for write only operations, and a final one for read-write operations. This separation makes it clear the purpouse of each operation and adds a nice layer of type safety, e.g. you can't write with a read-only map, or you can't read with a write-only map. >>>>> >>>>> 2. Param has been added, which is equivalent to Infinispan Flag with the added benefit that it can carry values. There's no such example right now but we could have in the future. >>>>> >>>>> 3. MetaParam has been added. This is a much more flexible and extensible option compared to the current Infinispan's Metadata. >>>>> >>>>> 4. For operations returning mutiple returns, or working on multiple elements, we've exposed something called Traversable, which is a subset of Java's Stream. See its javadoc to find out more. Kudos to Will for his work on distributed streams which has helped hugely with the design of Traversable. >>>>> >>>>> 5. Listeners have been added, again separating between read-write and write-only listeners (JCache does not offer read-only listeners, e.g. cache entry visited, and hence I think we'll drop our cache entry visited listener at some point). >>>>> >>>>> 6. Will and I have explored marshalling aspects of lambdas, and there are some interesting ways to reduce their costs by +90%! See MarshallingTest for different options to marshall both capturing and non-capturing lambdas and their cost in terms of payload sizes. >>>>> >>>>> Some final notes: >>>>> >>>>> * Please do read the javadocs, they contain a lot of information on the reasons behind the design. >>>>> >>>>> * To find out how the different functional map variants are used, look at ConcurrentMapDecorator and JCacheDecorator who use them to implement the ConcurrentMap and javax.cache.Cache APIs respectively. >>>>> >>>>> * FunctionalMapTest contains examples on how to use functional map variants for other operations which we deeply care about, e.g. Hot Rod atomic version-based replace function. >>>>> >>>>> Special thanks to Mario Fusco (Java 8 In Action book co-author) for his feedback throughout this 2nd draft design process. >>>>> >>>>> Cheers, >>>>> >>>>> [1] https://github.com/infinispan/proto8/blob/master/src/main/java/org/infinispan/api/v8/FunctionalMap.java >>>>> -- >>>>> Galder Zamarre?o >>>>> galder at redhat.com >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >>> -- >>> Galder Zamarre?o >>> galder at redhat.com >>> >>> >>> >>> >>> >>> _______________________________________________ >>> 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 -- Galder Zamarre?o galder at redhat.com From mudokonman at gmail.com Tue Jun 9 22:08:32 2015 From: mudokonman at gmail.com (William Burns) Date: Wed, 10 Jun 2015 02:08:32 +0000 Subject: [infinispan-dev] Cache Java 8 API proposal - 2nd draft In-Reply-To: References: <7E78289F-731F-4741-9AAD-71827CBCC537@redhat.com> <557192D0.5070503@redhat.com> <667C5F67-0178-44B0-BE0C-4BE790E9F6A0@redhat.com> <55755905.9030001@redhat.com> Message-ID: On Tue, Jun 9, 2015 at 2:12 AM Galder Zamarre?o wrote: > > > On 8 Jun 2015, at 10:57, Radim Vansa wrote: > > > > On 06/08/2015 10:41 AM, Dan Berindei wrote: > >> On Mon, Jun 8, 2015 at 10:37 AM, Galder Zamarre?o > wrote: > >>>> On 5 Jun 2015, at 14:15, Radim Vansa wrote: > >>>> > >>>> Is the marshalling comparison really fair? The lambda-table-based > >>>> approach removes the need for serializing the class definition, but in > >>>> practice - is the class definition always send around with each RPC? > >>> ^ We've extensively added Infinispan Externalizers (which use the > Object Table approach shown in MarshallingTests) to reduce the size of our > payloads, and indeed for all those, no class definitions are sent around. > So, as long as the types of those are known to us, we can use such approach > and avoid expensive serialization. > >>> > >>> NOTE: JBoss Marshalling's Externalizers are more expensive than > ObjectTable based approach but I can't remember why, it might be cos when > you use those, it might send the externalizer class' class definition > around, but not sure. > Yeah I believe that is correct. If we used the Infinispan Externalizers in conjunction with the ObjectTable it should only pass around an Integer instead I thought, so it should be much more favorable. > >> > >> I think the Simple/DynamicClassTable classes in WildFly take care of > >> writing only a class id in the stream, instead of the class name, same > >> as our ExternalizerTable but using JBoss Marshalling's Externalizers. > >> I don't know if there's any performance difference between the two > >> approaches, but I assume they must be pretty similar. > >> > >>>> If > >>>> it is so, it seems like a serious flaw of the current codebase, and > not > >>>> something occurring only for the functional interface. In case that we > >>>> keep the marshallers around, we should marshall second RPC (with the > >>>> same lambda and another instance of the same captured class), and look > >>>> on the diff rather than on the first serialized instance. > >>> ^ Hmmm, not sure what you mean there exactly. > > > > > > I meant that in case that the class definition is not sent with each RPC > > but only once/few times, we should not pay attention to the cost of > > sending the definition. As the test marshalls single RPC, the definition > > is always marshalled and accounted. > > ^ There are multiple tests in MarshallingTests, some of which marshall the > definition and others not, and I printed payload sizes: > > -> testObjectTableCapturingLambda payload is 43 bytes > testSerializableApplyLambda payload is 587 bytes > testExternalizerNonCapturingLambda payload is 160 bytes > testExternalizerCapturingLambda payload is 192 bytes > testNonCapturingLambdaAndSerializable payload is 501 bytes > testSerializableNonCapturingLambda payload is 597 byt > -> testObjectTableNonCapturingLambda payload is 3 bytes > > We're not going to go with any of the approaches that are over 100 bytes. > I thought you could only have 1 ObjectTable defined per Marshalling Configuration? Also it seems we would need to introduce a new facility for users to register their own lambdas then, since they wouldn't be able to use our Externalizers? > > The most efficient one, as you'd expect, is the Object Table approach with > a Non-Capturing lambda where the size of the payload is 3 bytes. Clearly > here no definition is marshalled at all. Second one is the one where the > lambda captures an external element and hence that needs to be shipped > every time. > > > So, if I understand that correctly, for user classes that do not > > register externalizers (I guess the registration is not automatic), the > > definition is sent around with each RPC, right? > > In that case yeah, to get that to work, you'd have to extend Serializable > and then you pay the penalty. > > This is the whole point why we came up with Externalizers and the > framework around it. If you want get running as quickly as possible, make > whatever you want to ship around extend Serializable but for ultimate > performance, pre-registration of externalizers is the way to go, and the > same approach works just as well with function/predicates...etc. > > Cheers, > > > > > Radim > > > >>> > >>>> Radim > >>>> > >>>> On 06/05/2015 11:44 AM, Galder Zamarre?o wrote: > >>>>> Hi all, > >>>>> > >>>>> Thanks to all who contributed to the 1st draft revision. We've taken > all that input and created a separate Github project where we have > prototytped the 2nd draft of the advanced Java 8 based Infinispan API. The > starting point for you should be FunctionalMap [1]. > >>>>> > >>>>> Here's a brief summary the major changes since the 1st draft: > >>>>> > >>>>> 1. FunctionalMap has been separated into 3 sub-interfaces, one for > read only operations, one for write only operations, and a final one for > read-write operations. This separation makes it clear the purpouse of each > operation and adds a nice layer of type safety, e.g. you can't write with a > read-only map, or you can't read with a write-only map. > >>>>> > >>>>> 2. Param has been added, which is equivalent to Infinispan Flag with > the added benefit that it can carry values. There's no such example right > now but we could have in the future. > >>>>> > >>>>> 3. MetaParam has been added. This is a much more flexible and > extensible option compared to the current Infinispan's Metadata. > >>>>> > >>>>> 4. For operations returning mutiple returns, or working on multiple > elements, we've exposed something called Traversable, which is a subset of > Java's Stream. See its javadoc to find out more. Kudos to Will for his work > on distributed streams which has helped hugely with the design of > Traversable. > >>>>> > >>>>> 5. Listeners have been added, again separating between read-write > and write-only listeners (JCache does not offer read-only listeners, e.g. > cache entry visited, and hence I think we'll drop our cache entry visited > listener at some point). > >>>>> > >>>>> 6. Will and I have explored marshalling aspects of lambdas, and > there are some interesting ways to reduce their costs by +90%! See > MarshallingTest for different options to marshall both capturing and > non-capturing lambdas and their cost in terms of payload sizes. > >>>>> > >>>>> Some final notes: > >>>>> > >>>>> * Please do read the javadocs, they contain a lot of information on > the reasons behind the design. > >>>>> > >>>>> * To find out how the different functional map variants are used, > look at ConcurrentMapDecorator and JCacheDecorator who use them to > implement the ConcurrentMap and javax.cache.Cache APIs respectively. > >>>>> > >>>>> * FunctionalMapTest contains examples on how to use functional map > variants for other operations which we deeply care about, e.g. Hot Rod > atomic version-based replace function. > >>>>> > >>>>> Special thanks to Mario Fusco (Java 8 In Action book co-author) for > his feedback throughout this 2nd draft design process. > >>>>> > >>>>> Cheers, > >>>>> > >>>>> [1] > https://github.com/infinispan/proto8/blob/master/src/main/java/org/infinispan/api/v8/FunctionalMap.java > >>>>> -- > >>>>> Galder Zamarre?o > >>>>> galder at redhat.com > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> 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 > >>> > >>> -- > >>> Galder Zamarre?o > >>> galder at redhat.com > >>> > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> 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 > > > -- > Galder Zamarre?o > galder at redhat.com > > > > > > _______________________________________________ > 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/20150610/2ce84047/attachment-0001.html From galder at redhat.com Mon Jun 15 04:19:28 2015 From: galder at redhat.com (=?utf-8?Q?Galder_Zamarre=C3=B1o?=) Date: Mon, 15 Jun 2015 10:19:28 +0200 Subject: [infinispan-dev] Cache Java 8 API proposal - 2nd draft In-Reply-To: References: <7E78289F-731F-4741-9AAD-71827CBCC537@redhat.com> <557192D0.5070503@redhat.com> <667C5F67-0178-44B0-BE0C-4BE790E9F6A0@redhat.com> <55755905.9030001@redhat.com> Message-ID: <8EBBB0BC-01EB-4E6C-B499-2782FF9D8A99@redhat.com> > On 10 Jun 2015, at 04:08, William Burns wrote: > > > > On Tue, Jun 9, 2015 at 2:12 AM Galder Zamarre?o wrote: > > > On 8 Jun 2015, at 10:57, Radim Vansa wrote: > > > > On 06/08/2015 10:41 AM, Dan Berindei wrote: > >> On Mon, Jun 8, 2015 at 10:37 AM, Galder Zamarre?o wrote: > >>>> On 5 Jun 2015, at 14:15, Radim Vansa wrote: > >>>> > >>>> Is the marshalling comparison really fair? The lambda-table-based > >>>> approach removes the need for serializing the class definition, but in > >>>> practice - is the class definition always send around with each RPC? > >>> ^ We've extensively added Infinispan Externalizers (which use the Object Table approach shown in MarshallingTests) to reduce the size of our payloads, and indeed for all those, no class definitions are sent around. So, as long as the types of those are known to us, we can use such approach and avoid expensive serialization. > >>> > >>> NOTE: JBoss Marshalling's Externalizers are more expensive than ObjectTable based approach but I can't remember why, it might be cos when you use those, it might send the externalizer class' class definition around, but not sure. > > Yeah I believe that is correct. If we used the Infinispan Externalizers in conjunction with the ObjectTable it should only pass around an Integer instead I thought, so it should be much more favorable. > > >> > >> I think the Simple/DynamicClassTable classes in WildFly take care of > >> writing only a class id in the stream, instead of the class name, same > >> as our ExternalizerTable but using JBoss Marshalling's Externalizers. > >> I don't know if there's any performance difference between the two > >> approaches, but I assume they must be pretty similar. > >> > >>>> If > >>>> it is so, it seems like a serious flaw of the current codebase, and not > >>>> something occurring only for the functional interface. In case that we > >>>> keep the marshallers around, we should marshall second RPC (with the > >>>> same lambda and another instance of the same captured class), and look > >>>> on the diff rather than on the first serialized instance. > >>> ^ Hmmm, not sure what you mean there exactly. > > > > > > I meant that in case that the class definition is not sent with each RPC > > but only once/few times, we should not pay attention to the cost of > > sending the definition. As the test marshalls single RPC, the definition > > is always marshalled and accounted. > > ^ There are multiple tests in MarshallingTests, some of which marshall the definition and others not, and I printed payload sizes: > > -> testObjectTableCapturingLambda payload is 43 bytes > testSerializableApplyLambda payload is 587 bytes > testExternalizerNonCapturingLambda payload is 160 bytes > testExternalizerCapturingLambda payload is 192 bytes > testNonCapturingLambdaAndSerializable payload is 501 bytes > testSerializableNonCapturingLambda payload is 597 byt > -> testObjectTableNonCapturingLambda payload is 3 bytes > > We're not going to go with any of the approaches that are over 100 bytes. > > I thought you could only have 1 ObjectTable defined per Marshalling Configuration? Also it seems we would need to introduce a new facility for users to register their own lambdas then, since they wouldn't be able to use our Externalizers? Yeah, there can only be 1 ObjectTable. I haven't looked at in great detail the integration part, but the examples show you can produce JBoss Marshalling Externalizers for lambdas, so I don't see why we would not able to provide Infinispan Externalizers for those and integrate into the current architecture. The only requirement would be that we'd need a fully defined class for the lambda (as done in the example) we want to register, as oppose to be able to support on the fly defined lambdas. > > > The most efficient one, as you'd expect, is the Object Table approach with a Non-Capturing lambda where the size of the payload is 3 bytes. Clearly here no definition is marshalled at all. Second one is the one where the lambda captures an external element and hence that needs to be shipped every time. > > > So, if I understand that correctly, for user classes that do not > > register externalizers (I guess the registration is not automatic), the > > definition is sent around with each RPC, right? > > In that case yeah, to get that to work, you'd have to extend Serializable and then you pay the penalty. > > This is the whole point why we came up with Externalizers and the framework around it. If you want get running as quickly as possible, make whatever you want to ship around extend Serializable but for ultimate performance, pre-registration of externalizers is the way to go, and the same approach works just as well with function/predicates...etc. > > Cheers, > > > > > Radim > > > >>> > >>>> Radim > >>>> > >>>> On 06/05/2015 11:44 AM, Galder Zamarre?o wrote: > >>>>> Hi all, > >>>>> > >>>>> Thanks to all who contributed to the 1st draft revision. We've taken all that input and created a separate Github project where we have prototytped the 2nd draft of the advanced Java 8 based Infinispan API. The starting point for you should be FunctionalMap [1]. > >>>>> > >>>>> Here's a brief summary the major changes since the 1st draft: > >>>>> > >>>>> 1. FunctionalMap has been separated into 3 sub-interfaces, one for read only operations, one for write only operations, and a final one for read-write operations. This separation makes it clear the purpouse of each operation and adds a nice layer of type safety, e.g. you can't write with a read-only map, or you can't read with a write-only map. > >>>>> > >>>>> 2. Param has been added, which is equivalent to Infinispan Flag with the added benefit that it can carry values. There's no such example right now but we could have in the future. > >>>>> > >>>>> 3. MetaParam has been added. This is a much more flexible and extensible option compared to the current Infinispan's Metadata. > >>>>> > >>>>> 4. For operations returning mutiple returns, or working on multiple elements, we've exposed something called Traversable, which is a subset of Java's Stream. See its javadoc to find out more. Kudos to Will for his work on distributed streams which has helped hugely with the design of Traversable. > >>>>> > >>>>> 5. Listeners have been added, again separating between read-write and write-only listeners (JCache does not offer read-only listeners, e.g. cache entry visited, and hence I think we'll drop our cache entry visited listener at some point). > >>>>> > >>>>> 6. Will and I have explored marshalling aspects of lambdas, and there are some interesting ways to reduce their costs by +90%! See MarshallingTest for different options to marshall both capturing and non-capturing lambdas and their cost in terms of payload sizes. > >>>>> > >>>>> Some final notes: > >>>>> > >>>>> * Please do read the javadocs, they contain a lot of information on the reasons behind the design. > >>>>> > >>>>> * To find out how the different functional map variants are used, look at ConcurrentMapDecorator and JCacheDecorator who use them to implement the ConcurrentMap and javax.cache.Cache APIs respectively. > >>>>> > >>>>> * FunctionalMapTest contains examples on how to use functional map variants for other operations which we deeply care about, e.g. Hot Rod atomic version-based replace function. > >>>>> > >>>>> Special thanks to Mario Fusco (Java 8 In Action book co-author) for his feedback throughout this 2nd draft design process. > >>>>> > >>>>> Cheers, > >>>>> > >>>>> [1] https://github.com/infinispan/proto8/blob/master/src/main/java/org/infinispan/api/v8/FunctionalMap.java > >>>>> -- > >>>>> Galder Zamarre?o > >>>>> galder at redhat.com > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> 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 > >>> > >>> -- > >>> Galder Zamarre?o > >>> galder at redhat.com > >>> > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> 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 > > > -- > Galder Zamarre?o > galder at redhat.com > > > > > > _______________________________________________ > 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 -- Galder Zamarre?o galder at redhat.com From sanne at infinispan.org Tue Jun 16 08:22:55 2015 From: sanne at infinispan.org (Sanne Grinovero) Date: Tue, 16 Jun 2015 13:22:55 +0100 Subject: [infinispan-dev] Threads, Quasar, Fibers and DSLs Message-ID: Hi all, we recently discussed about the problem of modelling locks as Java locks, and blocking our actual threads - or have to delegate to internal large threadpools - to model the "parking" of a thread which is visiting the interceptor chain, when all we want is to model a lock as a boolean with possibly some metadata like owners and timestamps. We all agreed that it needs to change, and we proposed some high-level basic ideas about how to store the "on stack" state in some container object. We know what we want to achieve, but I haven't seen yet much progress on details about how exactly get there. One basic first step we discussed is to split the internal contract of the visitor chain between separate methods "up" and "down" (very much in JGroups style). That would force us to highlight local variables, which need to be moved within an appropriate container. We then briefly discussed how such a container should model a stack, to allow for different visitors to avoid name clashing, and do it efficiently: we wouldn't like to allocate a vector for the stack, nor use a dictionary for the names-object variables, but at every least a custom payload object would need to be coded for each visitor, and appended to the chain.. that would have the allocation costs of a linked list and a container object to allow field access pointers be allocated for each visitor in the chain. Pooling is also an option.. but really it's all just looking horrible :-) I was now reading about Quasar and Fibers (credit to Mark Little and Tim Fox for the pointer) : - http://docs.paralleluniverse.co/quasar/ It seems very interesting, and relevant to our Infinispan discussion. Although it does much more than what we need and the prospect of supporting production systems which extensively rely on ASM and modify definitions like threads and lock owners scares me a bit, so I'm not advocating we use Fibers directly but it would be very nice to: - be able to experiment with it - see if something similar could be done without needing the bytecode manipulation - maybe use it? The overall impression I get, is that it's a very complex task for us to split the visitor chain at this point, and it's equally expensive to make any such experiment viable, so embarking in an experiment to evaluate something like Fiber gets the "Epic" JIRA level.. but there might be better ways! If you look at our RPC Commands, a lot of code is very repetitive, following established patterns and conventions. The component of the Visitor chain are a bit less repetitive, but still there are some patterns. So, what if we had some basic templates for all this repeating code, and used a custom DSL to define what a Command or a Visitor is supposed to do? I'm not suggesting we invent yet another general purpose programming language, but something very ad-hoc which takes the input we need and generates Java sources which we all understand, so issues in the code generation should be easy to spot (better so than ASM!). If we had such a tool, it would be sustainable to make cross-the-board changes to the threading model, experiment with things like Fibers, generate the visitor code and the correct stack handling w/o getting dirty with very boring code which we don't even know how it will work out. In addition such a tool could optionally be enhanced to generate metadata for tooling, like correctness evaluations, model checkers, inject correct trace logging w/o polluting our design, output to visualizers or other debugging helpers. More importantly, it would significantly reduce the manpower needed to experiment with model changes which would otherwise affect a too large code base. For example, for some configurations one might not need the InvocationContext at all, and to push the performance level to the extreme it would be better handled by generating an alternative set of visitors (or use bytecode manipulation). Thanks, Sanne From dan.berindei at gmail.com Tue Jun 16 08:36:51 2015 From: dan.berindei at gmail.com (Dan Berindei) Date: Tue, 16 Jun 2015 15:36:51 +0300 Subject: [infinispan-dev] Cache Java 8 API proposal - 2nd draft In-Reply-To: <8EBBB0BC-01EB-4E6C-B499-2782FF9D8A99@redhat.com> References: <7E78289F-731F-4741-9AAD-71827CBCC537@redhat.com> <557192D0.5070503@redhat.com> <667C5F67-0178-44B0-BE0C-4BE790E9F6A0@redhat.com> <55755905.9030001@redhat.com> <8EBBB0BC-01EB-4E6C-B499-2782FF9D8A99@redhat.com> Message-ID: Hey Galder I have finally read the proto8 code, and it looks quite good. I do have some concerns about how the lambdas will interact with distribution, because not every node performs conditional updates the same way (at least not without total order): 1. In non-transactional caches, we will retry an operation if the cache topology changes, and the second time around we don't want to fail the operation if the key already has the correct value on the primary owner. 2. In transactional caches, the conditional commands are only checked on the originator - all other owners apply the update unconditionally. This makes the modifications idempotent, which then allows us to retry the prepare as many times as necessary. Are you thinking of handling these differences in the lambdas themselves, or maybe you have something else in mind? For optimistic caches we also have the write skew check, is that going to be in the lambda? It's also be performed only on the primary owner without TO, and on all the owners with TO... I also have some questions about the MetaParams: 1. Do we really need MetaParam.Id? Couldn't we index the MetaParams by their class? 2. Do we really want such fine granularity? We could at least pair Created/Lifespan and LastUsed/MaxIdle... Cheers Dan On Mon, Jun 15, 2015 at 11:19 AM, Galder Zamarre?o wrote: > >> On 10 Jun 2015, at 04:08, William Burns wrote: >> >> >> >> On Tue, Jun 9, 2015 at 2:12 AM Galder Zamarre?o wrote: >> >> > On 8 Jun 2015, at 10:57, Radim Vansa wrote: >> > >> > On 06/08/2015 10:41 AM, Dan Berindei wrote: >> >> On Mon, Jun 8, 2015 at 10:37 AM, Galder Zamarre?o wrote: >> >>>> On 5 Jun 2015, at 14:15, Radim Vansa wrote: >> >>>> >> >>>> Is the marshalling comparison really fair? The lambda-table-based >> >>>> approach removes the need for serializing the class definition, but in >> >>>> practice - is the class definition always send around with each RPC? >> >>> ^ We've extensively added Infinispan Externalizers (which use the Object Table approach shown in MarshallingTests) to reduce the size of our payloads, and indeed for all those, no class definitions are sent around. So, as long as the types of those are known to us, we can use such approach and avoid expensive serialization. >> >>> >> >>> NOTE: JBoss Marshalling's Externalizers are more expensive than ObjectTable based approach but I can't remember why, it might be cos when you use those, it might send the externalizer class' class definition around, but not sure. >> >> Yeah I believe that is correct. If we used the Infinispan Externalizers in conjunction with the ObjectTable it should only pass around an Integer instead I thought, so it should be much more favorable. >> >> >> >> >> I think the Simple/DynamicClassTable classes in WildFly take care of >> >> writing only a class id in the stream, instead of the class name, same >> >> as our ExternalizerTable but using JBoss Marshalling's Externalizers. >> >> I don't know if there's any performance difference between the two >> >> approaches, but I assume they must be pretty similar. >> >> >> >>>> If >> >>>> it is so, it seems like a serious flaw of the current codebase, and not >> >>>> something occurring only for the functional interface. In case that we >> >>>> keep the marshallers around, we should marshall second RPC (with the >> >>>> same lambda and another instance of the same captured class), and look >> >>>> on the diff rather than on the first serialized instance. >> >>> ^ Hmmm, not sure what you mean there exactly. >> > >> > >> > I meant that in case that the class definition is not sent with each RPC >> > but only once/few times, we should not pay attention to the cost of >> > sending the definition. As the test marshalls single RPC, the definition >> > is always marshalled and accounted. >> >> ^ There are multiple tests in MarshallingTests, some of which marshall the definition and others not, and I printed payload sizes: >> >> -> testObjectTableCapturingLambda payload is 43 bytes >> testSerializableApplyLambda payload is 587 bytes >> testExternalizerNonCapturingLambda payload is 160 bytes >> testExternalizerCapturingLambda payload is 192 bytes >> testNonCapturingLambdaAndSerializable payload is 501 bytes >> testSerializableNonCapturingLambda payload is 597 byt >> -> testObjectTableNonCapturingLambda payload is 3 bytes >> >> We're not going to go with any of the approaches that are over 100 bytes. >> >> I thought you could only have 1 ObjectTable defined per Marshalling Configuration? Also it seems we would need to introduce a new facility for users to register their own lambdas then, since they wouldn't be able to use our Externalizers? > > Yeah, there can only be 1 ObjectTable. I haven't looked at in great detail the integration part, but the examples show you can produce JBoss Marshalling Externalizers for lambdas, so I don't see why we would not able to provide Infinispan Externalizers for those and integrate into the current architecture. > > The only requirement would be that we'd need a fully defined class for the lambda (as done in the example) we want to register, as oppose to be able to support on the fly defined lambdas. > >> >> >> The most efficient one, as you'd expect, is the Object Table approach with a Non-Capturing lambda where the size of the payload is 3 bytes. Clearly here no definition is marshalled at all. Second one is the one where the lambda captures an external element and hence that needs to be shipped every time. >> >> > So, if I understand that correctly, for user classes that do not >> > register externalizers (I guess the registration is not automatic), the >> > definition is sent around with each RPC, right? >> >> In that case yeah, to get that to work, you'd have to extend Serializable and then you pay the penalty. >> >> This is the whole point why we came up with Externalizers and the framework around it. If you want get running as quickly as possible, make whatever you want to ship around extend Serializable but for ultimate performance, pre-registration of externalizers is the way to go, and the same approach works just as well with function/predicates...etc. >> >> Cheers, >> >> > >> > Radim >> > >> >>> >> >>>> Radim >> >>>> >> >>>> On 06/05/2015 11:44 AM, Galder Zamarre?o wrote: >> >>>>> Hi all, >> >>>>> >> >>>>> Thanks to all who contributed to the 1st draft revision. We've taken all that input and created a separate Github project where we have prototytped the 2nd draft of the advanced Java 8 based Infinispan API. The starting point for you should be FunctionalMap [1]. >> >>>>> >> >>>>> Here's a brief summary the major changes since the 1st draft: >> >>>>> >> >>>>> 1. FunctionalMap has been separated into 3 sub-interfaces, one for read only operations, one for write only operations, and a final one for read-write operations. This separation makes it clear the purpouse of each operation and adds a nice layer of type safety, e.g. you can't write with a read-only map, or you can't read with a write-only map. >> >>>>> >> >>>>> 2. Param has been added, which is equivalent to Infinispan Flag with the added benefit that it can carry values. There's no such example right now but we could have in the future. >> >>>>> >> >>>>> 3. MetaParam has been added. This is a much more flexible and extensible option compared to the current Infinispan's Metadata. >> >>>>> >> >>>>> 4. For operations returning mutiple returns, or working on multiple elements, we've exposed something called Traversable, which is a subset of Java's Stream. See its javadoc to find out more. Kudos to Will for his work on distributed streams which has helped hugely with the design of Traversable. >> >>>>> >> >>>>> 5. Listeners have been added, again separating between read-write and write-only listeners (JCache does not offer read-only listeners, e.g. cache entry visited, and hence I think we'll drop our cache entry visited listener at some point). >> >>>>> >> >>>>> 6. Will and I have explored marshalling aspects of lambdas, and there are some interesting ways to reduce their costs by +90%! See MarshallingTest for different options to marshall both capturing and non-capturing lambdas and their cost in terms of payload sizes. >> >>>>> >> >>>>> Some final notes: >> >>>>> >> >>>>> * Please do read the javadocs, they contain a lot of information on the reasons behind the design. >> >>>>> >> >>>>> * To find out how the different functional map variants are used, look at ConcurrentMapDecorator and JCacheDecorator who use them to implement the ConcurrentMap and javax.cache.Cache APIs respectively. >> >>>>> >> >>>>> * FunctionalMapTest contains examples on how to use functional map variants for other operations which we deeply care about, e.g. Hot Rod atomic version-based replace function. >> >>>>> >> >>>>> Special thanks to Mario Fusco (Java 8 In Action book co-author) for his feedback throughout this 2nd draft design process. >> >>>>> >> >>>>> Cheers, >> >>>>> >> >>>>> [1] https://github.com/infinispan/proto8/blob/master/src/main/java/org/infinispan/api/v8/FunctionalMap.java >> >>>>> -- >> >>>>> Galder Zamarre?o >> >>>>> galder at redhat.com >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> _______________________________________________ >> >>>>> 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 >> >>> >> >>> -- >> >>> Galder Zamarre?o >> >>> galder at redhat.com >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> _______________________________________________ >> >>> 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 >> >> >> -- >> Galder Zamarre?o >> galder at redhat.com >> >> >> >> >> >> _______________________________________________ >> 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 > > > -- > Galder Zamarre?o > galder at redhat.com > > > > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev From mudokonman at gmail.com Wed Jun 17 09:07:09 2015 From: mudokonman at gmail.com (William Burns) Date: Wed, 17 Jun 2015 13:07:09 +0000 Subject: [infinispan-dev] Infinispan 8.0.0.Alpha2 Message-ID: Hello community, Infinispan 8.0.0.Alpha2 is now available! Please check the blog [1] for all the yummy details. Cheers, - Will [1] http://blog.infinispan.org/2015/06/infinispan-800alpha2.html -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20150617/70e7e99b/attachment.html From mudokonman at gmail.com Wed Jun 17 14:32:36 2015 From: mudokonman at gmail.com (William Burns) Date: Wed, 17 Jun 2015 18:32:36 +0000 Subject: [infinispan-dev] State Transfer & Invalidation Caches Message-ID: Recently [1] was found. The underlying cause is that now initial state transfer is enabled by default including invalidation caches. When thinking about this I didn't even realize that we utilize a Replicated consistent hash for invalidation mode. This all strikes me as just wrong. To me an invalidation cache is just a local cache that sends broadcasted invalidation messages to other members. It shouldn't have any need for a consistent hash. Currently though we have an invalidation cache that will try to acquire remote locks [2], reports ownership of keys by the consistent hash (instead of each node owning every key as it would be in a local cache [3]), which will participate in initial state transfer (REPL based) [4] among other things. We even have invalidation commands that are tied to given topologies [5]. I was originally planning on cutting the cord between invalidation caches and state transfer, but I am finding so many places that assume we have a topology that it requires more code that I would have thought. So I wanted to check if anyone had any objections. If there are objections I can end up taking the quick and easy route of just forcing disabling of initial state transfer and leaving everything as it is otherwise. I personally feel we should completely separate these concepts to guarantee what I would think as proper behavior. Thanks, - Will [1] https://issues.jboss.org/browse/ISPN-5560 [2] https://github.com/infinispan/infinispan/blob/master/core/src/test/java/org/infinispan/lock/InvalidationModePessimisticLockReleaseTest.java [3] https://github.com/infinispan/infinispan/blob/master/core/src/main/java/org/infinispan/interceptors/locking/ClusteringDependentLogic.java#L300 [4] https://github.com/infinispan/infinispan/blob/master/core/src/test/java/org/infinispan/statetransfer/NonTxStateTransferInvalidationTest.java#L56 [5] https://issues.jboss.org/browse/ISPN-4016 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20150617/11b0de36/attachment.html From sanne at infinispan.org Wed Jun 17 15:07:43 2015 From: sanne at infinispan.org (Sanne Grinovero) Date: Wed, 17 Jun 2015 20:07:43 +0100 Subject: [infinispan-dev] State Transfer & Invalidation Caches In-Reply-To: References: Message-ID: Hi Will, thanks for asking! It's a big decision indeed, and I might have some objections :) although I can be easily persuaded otherwise as I'm not really sure how it's currently implemented. My doubts would be around cache state consistency across nodes. I agree with you that state transfer is unexpected in the scope of invalidation, but the consistent hash distribution is also used to identify the "primary owner" for each entry - which I think still is an essential role for example to implement atomic operations and locking. One might say that such things are not needed for some use cases, but I think the contract of Invalidation with a client is around the lines of "it's ok to return null if you don't have a local copy" but it's not relaxing the consistency and transactional guarantees which we normally provide with other cache modes. We could of course argue if it could be useful to provide a relaxed consistency mode, but I'd really not drop the stronger model. -- Sanne On 17 June 2015 at 19:32, William Burns wrote: > Recently [1] was found. The underlying cause is that now initial state > transfer is enabled by default including invalidation caches. > > When thinking about this I didn't even realize that we utilize a Replicated > consistent hash for invalidation mode. This all strikes me as just wrong. > To me an invalidation cache is just a local cache that sends broadcasted > invalidation messages to other members. It shouldn't have any need for a > consistent hash. > > Currently though we have an invalidation cache that will try to acquire > remote locks [2], reports ownership of keys by the consistent hash (instead > of each node owning every key as it would be in a local cache [3]), which > will participate in initial state transfer (REPL based) [4] among other > things. We even have invalidation commands that are tied to given > topologies [5]. > > I was originally planning on cutting the cord between invalidation caches > and state transfer, but I am finding so many places that assume we have a > topology that it requires more code that I would have thought. So I wanted > to check if anyone had any objections. If there are objections I can end up > taking the quick and easy route of just forcing disabling of initial state > transfer and leaving everything as it is otherwise. I personally feel we > should completely separate these concepts to guarantee what I would think as > proper behavior. > > Thanks, > > - Will > > [1] https://issues.jboss.org/browse/ISPN-5560 > [2] > https://github.com/infinispan/infinispan/blob/master/core/src/test/java/org/infinispan/lock/InvalidationModePessimisticLockReleaseTest.java > [3] > https://github.com/infinispan/infinispan/blob/master/core/src/main/java/org/infinispan/interceptors/locking/ClusteringDependentLogic.java#L300 > [4] > https://github.com/infinispan/infinispan/blob/master/core/src/test/java/org/infinispan/statetransfer/NonTxStateTransferInvalidationTest.java#L56 > [5] https://issues.jboss.org/browse/ISPN-4016 > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev From mudokonman at gmail.com Wed Jun 17 15:12:39 2015 From: mudokonman at gmail.com (William Burns) Date: Wed, 17 Jun 2015 19:12:39 +0000 Subject: [infinispan-dev] Threads, Quasar, Fibers and DSLs In-Reply-To: References: Message-ID: On Tue, Jun 16, 2015 at 8:23 AM Sanne Grinovero wrote: > Hi all, > > we recently discussed about the problem of modelling locks as Java > locks, and blocking our actual threads - or have to delegate to > internal large threadpools - to model the "parking" of a thread which > is visiting the interceptor chain, when all we want is to model a lock > as a boolean with possibly some metadata like owners and timestamps. > > We all agreed that it needs to change, and we proposed some high-level > basic ideas about how to store the "on stack" state in some container > object. We know what we want to achieve, but I haven't seen yet much > progress on details about how exactly get there. > Dan has started with a handful of JIRAs [1]. It looks like this issue in particular is the one to explore that information. I am guessing he will have a design thought out for that in a bit, is that what you are looking for? > > One basic first step we discussed is to split the internal contract of > the visitor chain between separate methods "up" and "down" (very much > in JGroups style). That would force us to highlight local variables, > which need to be moved within an appropriate container. > We then briefly discussed how such a container should model a stack, > to allow for different visitors to avoid name clashing, and do it > efficiently: we wouldn't like to allocate a vector for the stack, nor > use a dictionary for the names-object variables, but at every least a > custom payload object would need to be coded for each visitor, and > appended to the chain.. that would have the allocation costs of a > linked list and a container object to allow field access pointers be > allocated for each visitor in the chain. > Pooling is also an option.. but really it's all just looking horrible :-) > > I was now reading about Quasar and Fibers (credit to Mark Little and > Tim Fox for the pointer) : > - http://docs.paralleluniverse.co/quasar/ > > It seems very interesting, and relevant to our Infinispan discussion. > Although it does much more than what we need and the prospect of > supporting production systems which extensively rely on ASM and modify > definitions like threads and lock owners scares me a bit, so I'm not > advocating we use Fibers directly but it would be very nice to: > - be able to experiment with it > - see if something similar could be done without needing the bytecode > manipulation > - maybe use it? > Yeah I actually brought up Fibers a few times at the F2F last year, but no one else seemed interested. And to be honest the more I looked at it I don't know if I like the idea of having ASM etc as well especially modifying basic Java constructs like thread information. Doing this scares me especially since I have no idea how this would work common tools like jstack or debuggers etc. And actually Fibers does exactly what you were mentioning in the prior paragraph regarding the stack object to store between invocations. It just does it for the entire thread details. > > The overall impression I get, is that it's a very complex task for us > to split the visitor chain at this point, and it's equally expensive > to make any such experiment viable, so embarking in an experiment to > evaluate something like Fiber gets the "Epic" JIRA level.. but there > might be better ways! > Yeah I came to just assume it would be too much for most likely little overall benefit, but maybe not :) > If you look at our RPC Commands, a lot of code is very repetitive, > following established patterns and conventions. The component of the > Visitor chain are a bit less repetitive, but still there are some > patterns. > > So, what if we had some basic templates for all this repeating code, > and used a custom DSL to define what a Command or a Visitor is > supposed to do? > I'm not suggesting we invent yet another general purpose programming > language, but something very ad-hoc which takes the input we need and > generates Java sources which we all understand, so issues in the code > generation should be easy to spot (better so than ASM!). > With all of the different edge cases based on the multitude of configuration options, I wonder how much code this would actually save us though. It seems we need to break it down into up and down methods either way to be able to have something to reuse like this, which would put us close to the interceptor rewrite anyways. > > If we had such a tool, it would be sustainable to make cross-the-board > changes to the threading model, experiment with things like Fibers, > generate the visitor code and the correct stack handling w/o getting > dirty with very boring code which we don't even know how it will work > out. > > In addition such a tool could optionally be enhanced to generate > metadata for tooling, like correctness evaluations, model checkers, > inject correct trace logging w/o polluting our design, output to > visualizers or other debugging helpers. > More importantly, it would significantly reduce the manpower needed to > experiment with model changes which would otherwise affect a too large > code base. For example, for some configurations one might not need the > InvocationContext at all, and to push the performance level to the > extreme it would be better handled by generating an alternative set of > visitors (or use bytecode manipulation). > I hope whether or not a context is required is something Dan has in mind possibly for his design :) > > Thanks, > Sanne > _______________________________________________ > infinispan-dev mailing list > infinispan-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev - Will [1] https://issues.jboss.org/browse/ISPN-5467 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20150617/c0346372/attachment-0001.html From mudokonman at gmail.com Wed Jun 17 15:40:23 2015 From: mudokonman at gmail.com (William Burns) Date: Wed, 17 Jun 2015 19:40:23 +0000 Subject: [infinispan-dev] State Transfer & Invalidation Caches In-Reply-To: References: Message-ID: On Wed, Jun 17, 2015 at 3:08 PM Sanne Grinovero wrote: > Hi Will, > thanks for asking! It's a big decision indeed, and I might have some > objections :) although I can be easily persuaded otherwise as I'm not > really sure how it's currently implemented. > Yeah that is part of it is I am not sure the original intent for invalidation mode. We all know it gets left ignored in regards to our attention, unless something goes wrong :P > > My doubts would be around cache state consistency across nodes. I > agree with you that state transfer is unexpected in the scope of > invalidation, but the consistent hash distribution is also used to > identify the "primary owner" for each entry - which I think still is > an essential role for example to implement atomic operations and > locking. > That is the part that is odd, sorry I didn't go into more details. Atomic operations are only guaranteed for the local node data in nontx or tx mode. For example if you have 2 nodes and only node1 has a value for key1. If a replace(key1, newvalue) is ran on node2 it will fail since only node1 has a value for key1. Locks are the thing that are really weird: - No remote locks are acquired for a nontx cache. - Remote locks are only acquired for tx caches. Since data modification is already protected by just a local lock, this only serves to prevent 2 invalidation messages to be sent from different nodes at the same time. The usefulness of remote locks in tx mode seems dubious as it will slow down uncontended writes since it will require replicating the lock information to all owners (includes backups) and having to include this owner in the tx commit handling to clean up said lock. We also have to handle a topology change to move the lock information between nodes. Maybe there is some use case here I am not aware of with invalidation and tx mode locking on remote nodes? > > One might say that such things are not needed for some use cases, but > I think the contract of Invalidation with a client is around the lines > of "it's ok to return null if you don't have a local copy" but it's > not relaxing the consistency and transactional guarantees which we > normally provide with other cache modes. > We could of course argue if it could be useful to provide a relaxed > consistency mode, but I'd really not drop the stronger model. > > -- Sanne > > > On 17 June 2015 at 19:32, William Burns wrote: > > Recently [1] was found. The underlying cause is that now initial state > > transfer is enabled by default including invalidation caches. > > > > When thinking about this I didn't even realize that we utilize a > Replicated > > consistent hash for invalidation mode. This all strikes me as just > wrong. > > To me an invalidation cache is just a local cache that sends broadcasted > > invalidation messages to other members. It shouldn't have any need for a > > consistent hash. > > > > Currently though we have an invalidation cache that will try to acquire > > remote locks [2], reports ownership of keys by the consistent hash > (instead > > of each node owning every key as it would be in a local cache [3]), which > > will participate in initial state transfer (REPL based) [4] among other > > things. We even have invalidation commands that are tied to given > > topologies [5]. > > > > I was originally planning on cutting the cord between invalidation caches > > and state transfer, but I am finding so many places that assume we have a > > topology that it requires more code that I would have thought. So I > wanted > > to check if anyone had any objections. If there are objections I can > end up > > taking the quick and easy route of just forcing disabling of initial > state > > transfer and leaving everything as it is otherwise. I personally feel we > > should completely separate these concepts to guarantee what I would > think as > > proper behavior. > > > > Thanks, > > > > - Will > > > > [1] https://issues.jboss.org/browse/ISPN-5560 > > [2] > > > https://github.com/infinispan/infinispan/blob/master/core/src/test/java/org/infinispan/lock/InvalidationModePessimisticLockReleaseTest.java > > [3] > > > https://github.com/infinispan/infinispan/blob/master/core/src/main/java/org/infinispan/interceptors/locking/ClusteringDependentLogic.java#L300 > > [4] > > > https://github.com/infinispan/infinispan/blob/master/core/src/test/java/org/infinispan/statetransfer/NonTxStateTransferInvalidationTest.java#L56 > > [5] https://issues.jboss.org/browse/ISPN-4016 > > > > _______________________________________________ > > 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/20150617/38e10931/attachment.html From ttarrant at redhat.com Fri Jun 19 04:29:57 2015 From: ttarrant at redhat.com (Tristan Tarrant) Date: Fri, 19 Jun 2015 10:29:57 +0200 Subject: [infinispan-dev] C++/C# clients bumping to C++11 and .NET 4.5 Message-ID: <5583D305.6070408@redhat.com> Hi all, In the past we've based our C++ code around C++03 so that it would be usable on RHEL5. This however precludes us from using many of the interesting features introduced in C++11 (proper auto_ptr, atomic, etc). I think we should branch the current native clients for 7.x so that master can be updated to more recent compilers: - G++ 4.7 as a minimum - MSVC 2012 and .NET 4.5 Comments ? Tristan -- Tristan Tarrant Infinispan Lead JBoss, a division of Red Hat From dan.berindei at gmail.com Fri Jun 19 05:43:26 2015 From: dan.berindei at gmail.com (Dan Berindei) Date: Fri, 19 Jun 2015 12:43:26 +0300 Subject: [infinispan-dev] C++/C# clients bumping to C++11 and .NET 4.5 In-Reply-To: <5583D305.6070408@redhat.com> References: <5583D305.6070408@redhat.com> Message-ID: +1 from me Dan On Fri, Jun 19, 2015 at 11:29 AM, Tristan Tarrant wrote: > Hi all, > > In the past we've based our C++ code around C++03 so that it would be > usable on RHEL5. This however precludes us from using many of the > interesting features introduced in C++11 (proper auto_ptr, atomic, etc). > I think we should branch the current native clients for 7.x so that > master can be updated to more recent compilers: > > - G++ 4.7 as a minimum > - MSVC 2012 and .NET 4.5 > > Comments ? > > 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 sebastian.laskawiec at gmail.com Fri Jun 19 05:53:38 2015 From: sebastian.laskawiec at gmail.com (=?UTF-8?Q?Sebastian_=C5=81askawiec?=) Date: Fri, 19 Jun 2015 09:53:38 +0000 Subject: [infinispan-dev] C++/C# clients bumping to C++11 and .NET 4.5 In-Reply-To: References: <5583D305.6070408@redhat.com> Message-ID: +1 from me too. New language features will simplify our code a.lot. Thanks Sebastian On Fri, 19 Jun 2015 at 11:44 Dan Berindei wrote: > +1 from me > > Dan > > > On Fri, Jun 19, 2015 at 11:29 AM, Tristan Tarrant > wrote: > > Hi all, > > > > In the past we've based our C++ code around C++03 so that it would be > > usable on RHEL5. This however precludes us from using many of the > > interesting features introduced in C++11 (proper auto_ptr, atomic, etc). > > I think we should branch the current native clients for 7.x so that > > master can be updated to more recent compilers: > > > > - G++ 4.7 as a minimum > > - MSVC 2012 and .NET 4.5 > > > > Comments ? > > > > 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 > _______________________________________________ > 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/20150619/ddb8a532/attachment.html From galder at redhat.com Fri Jun 19 09:51:38 2015 From: galder at redhat.com (=?utf-8?Q?Galder_Zamarre=C3=B1o?=) Date: Fri, 19 Jun 2015 15:51:38 +0200 Subject: [infinispan-dev] Cache Java 8 API proposal - 2nd draft In-Reply-To: References: <7E78289F-731F-4741-9AAD-71827CBCC537@redhat.com> <557192D0.5070503@redhat.com> <667C5F67-0178-44B0-BE0C-4BE790E9F6A0@redhat.com> <55755905.9030001@redhat.com> <8EBBB0BC-01EB-4E6C-B499-2782FF9D8A99@redhat.com> Message-ID: <3D7C335E-7FB0-450A-899A-F4733C6D7847@redhat.com> Hi all, Dan and I had a chat to clarify some of these topics on IRC: > On 16 Jun 2015, at 14:36, Dan Berindei wrote: > > Hey Galder > > I have finally read the proto8 code, and it looks quite good. > > I do have some concerns about how the lambdas will interact with > distribution, because not every node performs conditional updates the > same way (at least not without total order): > > 1. In non-transactional caches, we will retry an operation if the > cache topology changes, and the second time around we don't want to > fail the operation if the key already has the correct value on the > primary owner. ^ Having discussed on IRC, this basically refers to whether NonTxBackupOwnerBecomingPrimaryOwnerTest would work with a concurrent map implemented with functiona map. The issue resolves around ValueMatcher and how it'd work if the Infinispan does not know what the lambda does. For example, right now Infinispan cannot make a difference between a lambda executing replace(K,V) and replace(K,V,V), and knowing the difference between these two is needed to be able to select the correct value matcher. I don't have an answer for this yet. I'm porting the prototype to Infinispan and when it's ready I'll look into NonTxBackupOwnerBecomingPrimaryOwnerTest running with a concurrent map impl based on functional map. > 2. In transactional caches, the conditional commands are only checked > on the originator - all other owners apply the update unconditionally. > This makes the modifications idempotent, which then allows us to retry > the prepare as many times as necessary. Similar issue to the one in the previous point. @Dan, can you pintpoint me to a particular test to see how this would work? > Are you thinking of handling these differences in the lambdas > themselves, or maybe you have something else in mind? ^ Dunno yet. > For optimistic caches we also have the write skew check, is that going > to be in the lambda? It's also be performed only on the primary owner > without TO, and on all the owners with TO... ^ Dunno yet. > I also have some questions about the MetaParams: > > 1. Do we really need MetaParam.Id? Couldn't we index the MetaParams by > their class? We could potentially pass in the type of MetaParam class we are after, and do the array search based on that. That might work without the need to add an extra ID Class. I'll give that a try. In case anyone is wondering, I wouldn't want to change the internal data structure in MetaParams from an array to a hash map with Class and key type. On top of being quite heavyweight, we'd need a weak hash map due to avoid leaking classes. > 2. Do we really want such fine granularity? We could at least pair > Created/Lifespan and LastUsed/MaxIdle... ^ Makes sense, great idea :) > > > Cheers > Dan > > > On Mon, Jun 15, 2015 at 11:19 AM, Galder Zamarre?o wrote: >> >>> On 10 Jun 2015, at 04:08, William Burns wrote: >>> >>> >>> >>> On Tue, Jun 9, 2015 at 2:12 AM Galder Zamarre?o wrote: >>> >>>> On 8 Jun 2015, at 10:57, Radim Vansa wrote: >>>> >>>> On 06/08/2015 10:41 AM, Dan Berindei wrote: >>>>> On Mon, Jun 8, 2015 at 10:37 AM, Galder Zamarre?o wrote: >>>>>>> On 5 Jun 2015, at 14:15, Radim Vansa wrote: >>>>>>> >>>>>>> Is the marshalling comparison really fair? The lambda-table-based >>>>>>> approach removes the need for serializing the class definition, but in >>>>>>> practice - is the class definition always send around with each RPC? >>>>>> ^ We've extensively added Infinispan Externalizers (which use the Object Table approach shown in MarshallingTests) to reduce the size of our payloads, and indeed for all those, no class definitions are sent around. So, as long as the types of those are known to us, we can use such approach and avoid expensive serialization. >>>>>> >>>>>> NOTE: JBoss Marshalling's Externalizers are more expensive than ObjectTable based approach but I can't remember why, it might be cos when you use those, it might send the externalizer class' class definition around, but not sure. >>> >>> Yeah I believe that is correct. If we used the Infinispan Externalizers in conjunction with the ObjectTable it should only pass around an Integer instead I thought, so it should be much more favorable. >>> >>>>> >>>>> I think the Simple/DynamicClassTable classes in WildFly take care of >>>>> writing only a class id in the stream, instead of the class name, same >>>>> as our ExternalizerTable but using JBoss Marshalling's Externalizers. >>>>> I don't know if there's any performance difference between the two >>>>> approaches, but I assume they must be pretty similar. >>>>> >>>>>>> If >>>>>>> it is so, it seems like a serious flaw of the current codebase, and not >>>>>>> something occurring only for the functional interface. In case that we >>>>>>> keep the marshallers around, we should marshall second RPC (with the >>>>>>> same lambda and another instance of the same captured class), and look >>>>>>> on the diff rather than on the first serialized instance. >>>>>> ^ Hmmm, not sure what you mean there exactly. >>>> >>>> >>>> I meant that in case that the class definition is not sent with each RPC >>>> but only once/few times, we should not pay attention to the cost of >>>> sending the definition. As the test marshalls single RPC, the definition >>>> is always marshalled and accounted. >>> >>> ^ There are multiple tests in MarshallingTests, some of which marshall the definition and others not, and I printed payload sizes: >>> >>> -> testObjectTableCapturingLambda payload is 43 bytes >>> testSerializableApplyLambda payload is 587 bytes >>> testExternalizerNonCapturingLambda payload is 160 bytes >>> testExternalizerCapturingLambda payload is 192 bytes >>> testNonCapturingLambdaAndSerializable payload is 501 bytes >>> testSerializableNonCapturingLambda payload is 597 byt >>> -> testObjectTableNonCapturingLambda payload is 3 bytes >>> >>> We're not going to go with any of the approaches that are over 100 bytes. >>> >>> I thought you could only have 1 ObjectTable defined per Marshalling Configuration? Also it seems we would need to introduce a new facility for users to register their own lambdas then, since they wouldn't be able to use our Externalizers? >> >> Yeah, there can only be 1 ObjectTable. I haven't looked at in great detail the integration part, but the examples show you can produce JBoss Marshalling Externalizers for lambdas, so I don't see why we would not able to provide Infinispan Externalizers for those and integrate into the current architecture. >> >> The only requirement would be that we'd need a fully defined class for the lambda (as done in the example) we want to register, as oppose to be able to support on the fly defined lambdas. >> >>> >>> >>> The most efficient one, as you'd expect, is the Object Table approach with a Non-Capturing lambda where the size of the payload is 3 bytes. Clearly here no definition is marshalled at all. Second one is the one where the lambda captures an external element and hence that needs to be shipped every time. >>> >>>> So, if I understand that correctly, for user classes that do not >>>> register externalizers (I guess the registration is not automatic), the >>>> definition is sent around with each RPC, right? >>> >>> In that case yeah, to get that to work, you'd have to extend Serializable and then you pay the penalty. >>> >>> This is the whole point why we came up with Externalizers and the framework around it. If you want get running as quickly as possible, make whatever you want to ship around extend Serializable but for ultimate performance, pre-registration of externalizers is the way to go, and the same approach works just as well with function/predicates...etc. >>> >>> Cheers, >>> >>>> >>>> Radim >>>> >>>>>> >>>>>>> Radim >>>>>>> >>>>>>> On 06/05/2015 11:44 AM, Galder Zamarre?o wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> Thanks to all who contributed to the 1st draft revision. We've taken all that input and created a separate Github project where we have prototytped the 2nd draft of the advanced Java 8 based Infinispan API. The starting point for you should be FunctionalMap [1]. >>>>>>>> >>>>>>>> Here's a brief summary the major changes since the 1st draft: >>>>>>>> >>>>>>>> 1. FunctionalMap has been separated into 3 sub-interfaces, one for read only operations, one for write only operations, and a final one for read-write operations. This separation makes it clear the purpouse of each operation and adds a nice layer of type safety, e.g. you can't write with a read-only map, or you can't read with a write-only map. >>>>>>>> >>>>>>>> 2. Param has been added, which is equivalent to Infinispan Flag with the added benefit that it can carry values. There's no such example right now but we could have in the future. >>>>>>>> >>>>>>>> 3. MetaParam has been added. This is a much more flexible and extensible option compared to the current Infinispan's Metadata. >>>>>>>> >>>>>>>> 4. For operations returning mutiple returns, or working on multiple elements, we've exposed something called Traversable, which is a subset of Java's Stream. See its javadoc to find out more. Kudos to Will for his work on distributed streams which has helped hugely with the design of Traversable. >>>>>>>> >>>>>>>> 5. Listeners have been added, again separating between read-write and write-only listeners (JCache does not offer read-only listeners, e.g. cache entry visited, and hence I think we'll drop our cache entry visited listener at some point). >>>>>>>> >>>>>>>> 6. Will and I have explored marshalling aspects of lambdas, and there are some interesting ways to reduce their costs by +90%! See MarshallingTest for different options to marshall both capturing and non-capturing lambdas and their cost in terms of payload sizes. >>>>>>>> >>>>>>>> Some final notes: >>>>>>>> >>>>>>>> * Please do read the javadocs, they contain a lot of information on the reasons behind the design. >>>>>>>> >>>>>>>> * To find out how the different functional map variants are used, look at ConcurrentMapDecorator and JCacheDecorator who use them to implement the ConcurrentMap and javax.cache.Cache APIs respectively. >>>>>>>> >>>>>>>> * FunctionalMapTest contains examples on how to use functional map variants for other operations which we deeply care about, e.g. Hot Rod atomic version-based replace function. >>>>>>>> >>>>>>>> Special thanks to Mario Fusco (Java 8 In Action book co-author) for his feedback throughout this 2nd draft design process. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> >>>>>>>> [1] https://github.com/infinispan/proto8/blob/master/src/main/java/org/infinispan/api/v8/FunctionalMap.java >>>>>>>> -- >>>>>>>> Galder Zamarre?o >>>>>>>> galder at redhat.com >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>>> >>>>>> -- >>>>>> Galder Zamarre?o >>>>>> galder at redhat.com >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>> >>> >>> -- >>> Galder Zamarre?o >>> galder at redhat.com >>> >>> >>> >>> >>> >>> _______________________________________________ >>> 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 >> >> >> -- >> Galder Zamarre?o >> galder at redhat.com >> >> >> >> >> >> _______________________________________________ >> 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 -- Galder Zamarre?o galder at redhat.com From ttarrant at redhat.com Fri Jun 19 11:39:03 2015 From: ttarrant at redhat.com (Tristan Tarrant) Date: Fri, 19 Jun 2015 17:39:03 +0200 Subject: [infinispan-dev] Infinispan 7.2.3.Final Message-ID: <55843797.3080803@redhat.com> Dear Infinispan users, thanks to your help, a few bugs have been found and fixed in the Infinispan 7.2 branch. So if you are affected by any of the bugs below, now is the time to upgrade. Bug [ISPN-4123] - Remote Query tests random failures [ISPN-5444] - Filter/converters in server can't unmarshall custom cached classes [ISPN-5522] - LIRS BoundedConcurrentHashMapv8 eviction for tree bin missing check [ISPN-5524] - Race condition in SemaphoreCompletionService.executeFront() [ISPN-5527] - Java system properties no longer supported in leveldb expiration path [ISPN-5531] - java.lang.UnsupportedOperationException during remove (using RemoteCacheManager) [ISPN-5543] - Bad tracef arguments are causing IllegalFormatConversionException [ISPN-5560] - NotSerializableException for invalidation-cache [ISPN-5565] - Memory leak in Hot Rod client tests [ISPN-5566] - Listener Observation is not obeyed for non CacheEntryEvents Enhancement [ISPN-5519] - Cannot choose to run index-less query on an indexed cache in compat mode Again, downloads and release notes are at the usual pages, so go and check them out ! Happy hacking. -- Tristan Tarrant Infinispan Lead JBoss, a division of Red Hat From rvansa at redhat.com Mon Jun 22 07:18:27 2015 From: rvansa at redhat.com (Radim Vansa) Date: Mon, 22 Jun 2015 13:18:27 +0200 Subject: [infinispan-dev] Interceptor stack for local caches Message-ID: <5587EF03.7090108@redhat.com> Hi, few weeks ago I was looking into performance of local cache when compared to basic concurrent hash map, or data container. I can't find the exact results now, but the difference was in order of magnitude - IIRC concurrent hash map was about 20x faster than local cache. There was no 'bottleneck', but the versatile Infinispan design of commands traversing through interceptor stack brings some overhead (e.g. allocation costs with each invocation, not only for writes) while in some use cases it is not necessary to keep this complexity. The use case I am looking for is caching in Hibernate ORM, which basically requires only map with eviction, expiration and transactions in some cases. No need for cache stores, statistics etc. So far I've found ways to remove few interceptors [1], but it's few percent, not hundreds of percent where I would ideally aim. Therefore, I was considering about an option to inspect cache configuration and in suitable cases return LocalCacheImpl that would get rid of the burden: no interceptor stack, no commands instantiation. This would be transparent to the user. I understand that it will increase maintenance costs, but it still seems better to me to have it under wings of Infinispan as caching solution rather than separate project, as it can share a lot of the codebase. Do you think that this idea makes sense, or is it just too wild? Do you think I will crash when trying to implement this? Radim [1] https://issues.jboss.org/browse/ISPN-5542 -- Radim Vansa JBoss Performance Team From emmanuel at hibernate.org Mon Jun 22 07:42:37 2015 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Mon, 22 Jun 2015 07:42:37 -0400 Subject: [infinispan-dev] Interceptor stack for local caches In-Reply-To: <5587EF03.7090108@redhat.com> References: <5587EF03.7090108@redhat.com> Message-ID: <8CCC4EB9-7442-4FF5-95FD-70E006565625@hibernate.org> I am no expect at all of the code base. Wouldn't returning LocalCacheImpl happening in very very specific cases and thus not be of quite limited use? And that resonates with the discussion of splitting the interceptor logic into before and after methods. And keeping the state not in the interceptor but in a type less stack passed to these methods. That would probably reduce the unnecessary allocation you are seeing. This also opened the doors for moving locks outside the execution thread AFAIR. Was this approach ever put on paper even as a few paragraphs somewhere ? > On 22 juin 2015, at 07:18, Radim Vansa wrote: > > Hi, > > few weeks ago I was looking into performance of local cache when > compared to basic concurrent hash map, or data container. I can't find > the exact results now, but the difference was in order of magnitude - > IIRC concurrent hash map was about 20x faster than local cache. There > was no 'bottleneck', but the versatile Infinispan design of commands > traversing through interceptor stack brings some overhead (e.g. > allocation costs with each invocation, not only for writes) while in > some use cases it is not necessary to keep this complexity. The use case > I am looking for is caching in Hibernate ORM, which basically requires > only map with eviction, expiration and transactions in some cases. No > need for cache stores, statistics etc. So far I've found ways to remove > few interceptors [1], but it's few percent, not hundreds of percent > where I would ideally aim. > > Therefore, I was considering about an option to inspect cache > configuration and in suitable cases return LocalCacheImpl that would get > rid of the burden: no interceptor stack, no commands instantiation. This > would be transparent to the user. I understand that it will increase > maintenance costs, but it still seems better to me to have it under > wings of Infinispan as caching solution rather than separate project, as > it can share a lot of the codebase. > > Do you think that this idea makes sense, or is it just too wild? Do you > think I will crash when trying to implement this? > > Radim > > [1] https://issues.jboss.org/browse/ISPN-5542 > > -- > Radim Vansa > JBoss Performance Team > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev From emmanuel at hibernate.org Mon Jun 22 07:47:37 2015 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Mon, 22 Jun 2015 07:47:37 -0400 Subject: [infinispan-dev] Interceptor stack for local caches In-Reply-To: <8CCC4EB9-7442-4FF5-95FD-70E006565625@hibernate.org> References: <5587EF03.7090108@redhat.com> <8CCC4EB9-7442-4FF5-95FD-70E006565625@hibernate.org> Message-ID: <7415CF42-E0BD-4285-860B-26527E3C0E9B@hibernate.org> BTW, a generic interface based call to interceptors is hard to optimize by the VM AFAIU. So having a few specialized implementations of CacheImpl that do hard code the calls to specific interceptor implementations (the 2 methods split ones) would make a lot of sense to me for a handful of selected cases like you are describing Radim. > On 22 juin 2015, at 07:42, Emmanuel Bernard wrote: > > I am no expect at all of the code base. > Wouldn't returning LocalCacheImpl happening in very very specific cases and thus not be of quite limited use? > > And that resonates with the discussion of splitting the interceptor logic into before and after methods. And keeping the state not in the interceptor but in a type less stack passed to these methods. That would probably reduce the unnecessary allocation you are seeing. This also opened the doors for moving locks outside the execution thread AFAIR. > > Was this approach ever put on paper even as a few paragraphs somewhere ? > >> On 22 juin 2015, at 07:18, Radim Vansa wrote: >> >> Hi, >> >> few weeks ago I was looking into performance of local cache when >> compared to basic concurrent hash map, or data container. I can't find >> the exact results now, but the difference was in order of magnitude - >> IIRC concurrent hash map was about 20x faster than local cache. There >> was no 'bottleneck', but the versatile Infinispan design of commands >> traversing through interceptor stack brings some overhead (e.g. >> allocation costs with each invocation, not only for writes) while in >> some use cases it is not necessary to keep this complexity. The use case >> I am looking for is caching in Hibernate ORM, which basically requires >> only map with eviction, expiration and transactions in some cases. No >> need for cache stores, statistics etc. So far I've found ways to remove >> few interceptors [1], but it's few percent, not hundreds of percent >> where I would ideally aim. >> >> Therefore, I was considering about an option to inspect cache >> configuration and in suitable cases return LocalCacheImpl that would get >> rid of the burden: no interceptor stack, no commands instantiation. This >> would be transparent to the user. I understand that it will increase >> maintenance costs, but it still seems better to me to have it under >> wings of Infinispan as caching solution rather than separate project, as >> it can share a lot of the codebase. >> >> Do you think that this idea makes sense, or is it just too wild? Do you >> think I will crash when trying to implement this? >> >> Radim >> >> [1] https://issues.jboss.org/browse/ISPN-5542 >> >> -- >> 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 sanne at infinispan.org Mon Jun 22 07:54:40 2015 From: sanne at infinispan.org (Sanne Grinovero) Date: Mon, 22 Jun 2015 12:54:40 +0100 Subject: [infinispan-dev] Interceptor stack for local caches In-Reply-To: <7415CF42-E0BD-4285-860B-26527E3C0E9B@hibernate.org> References: <5587EF03.7090108@redhat.com> <8CCC4EB9-7442-4FF5-95FD-70E006565625@hibernate.org> <7415CF42-E0BD-4285-860B-26527E3C0E9B@hibernate.org> Message-ID: +1 I'd love to see an evolution like that, I guess there should be various use cases which benefit from having no interceptor stack at all. As I see it, implementing the same Cache API as Infinispan would be nice but not necessary, assuming you don't need all of the same features. Mildly related: we sometimes would have benefit in other projects to simply reuse the Infinispan datacontainer and its LIRS implementation, without any of the additional dependencies. In some cases this has been done by copying the couple of relevant classes, as source code in the other project. Having such a thing as a separate, light weight and reusable module would improve maintenance. On 22 June 2015 at 12:47, Emmanuel Bernard wrote: > BTW, a generic interface based call to interceptors is hard to optimize by the VM AFAIU. > So having a few specialized implementations of CacheImpl that do hard code the calls to specific interceptor implementations (the 2 methods split ones) would make a lot of sense to me for a handful of selected cases like you are describing Radim. > >> On 22 juin 2015, at 07:42, Emmanuel Bernard wrote: >> >> I am no expect at all of the code base. >> Wouldn't returning LocalCacheImpl happening in very very specific cases and thus not be of quite limited use? >> >> And that resonates with the discussion of splitting the interceptor logic into before and after methods. And keeping the state not in the interceptor but in a type less stack passed to these methods. That would probably reduce the unnecessary allocation you are seeing. This also opened the doors for moving locks outside the execution thread AFAIR. >> >> Was this approach ever put on paper even as a few paragraphs somewhere ? >> >>> On 22 juin 2015, at 07:18, Radim Vansa wrote: >>> >>> Hi, >>> >>> few weeks ago I was looking into performance of local cache when >>> compared to basic concurrent hash map, or data container. I can't find >>> the exact results now, but the difference was in order of magnitude - >>> IIRC concurrent hash map was about 20x faster than local cache. There >>> was no 'bottleneck', but the versatile Infinispan design of commands >>> traversing through interceptor stack brings some overhead (e.g. >>> allocation costs with each invocation, not only for writes) while in >>> some use cases it is not necessary to keep this complexity. The use case >>> I am looking for is caching in Hibernate ORM, which basically requires >>> only map with eviction, expiration and transactions in some cases. No >>> need for cache stores, statistics etc. So far I've found ways to remove >>> few interceptors [1], but it's few percent, not hundreds of percent >>> where I would ideally aim. >>> >>> Therefore, I was considering about an option to inspect cache >>> configuration and in suitable cases return LocalCacheImpl that would get >>> rid of the burden: no interceptor stack, no commands instantiation. This >>> would be transparent to the user. I understand that it will increase >>> maintenance costs, but it still seems better to me to have it under >>> wings of Infinispan as caching solution rather than separate project, as >>> it can share a lot of the codebase. >>> >>> Do you think that this idea makes sense, or is it just too wild? Do you >>> think I will crash when trying to implement this? >>> >>> Radim >>> >>> [1] https://issues.jboss.org/browse/ISPN-5542 >>> >>> -- >>> 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 From emmanuel at hibernate.org Mon Jun 22 08:09:38 2015 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Mon, 22 Jun 2015 08:09:38 -0400 Subject: [infinispan-dev] Interceptor stack for local caches In-Reply-To: <7415CF42-E0BD-4285-860B-26527E3C0E9B@hibernate.org> References: <5587EF03.7090108@redhat.com> <8CCC4EB9-7442-4FF5-95FD-70E006565625@hibernate.org> <7415CF42-E0BD-4285-860B-26527E3C0E9B@hibernate.org> Message-ID: Pushing the idea further, you can actually make the CacheImpl specifically tailored to the configuration of a given cache by using ASM or anything that lets you build a class at runtime. That way, in this specialized implementation, all the interceptorImpl.before() and interceptorImpl.after() are specific non megamorphic calls that are optimizable and inline-able by the VM. And you don?t suffer for the maintenance overhead that Radim was pointing at. All of these ideas rely on a split of the interceptor logic into before() and after() methods. Emmanuel > On 22 Jun 2015, at 07:47, Emmanuel Bernard wrote: > > BTW, a generic interface based call to interceptors is hard to optimize by the VM AFAIU. > So having a few specialized implementations of CacheImpl that do hard code the calls to specific interceptor implementations (the 2 methods split ones) would make a lot of sense to me for a handful of selected cases like you are describing Radim. > >> On 22 juin 2015, at 07:42, Emmanuel Bernard wrote: >> >> I am no expect at all of the code base. >> Wouldn't returning LocalCacheImpl happening in very very specific cases and thus not be of quite limited use? >> >> And that resonates with the discussion of splitting the interceptor logic into before and after methods. And keeping the state not in the interceptor but in a type less stack passed to these methods. That would probably reduce the unnecessary allocation you are seeing. This also opened the doors for moving locks outside the execution thread AFAIR. >> >> Was this approach ever put on paper even as a few paragraphs somewhere ? >> >>> On 22 juin 2015, at 07:18, Radim Vansa wrote: >>> >>> Hi, >>> >>> few weeks ago I was looking into performance of local cache when >>> compared to basic concurrent hash map, or data container. I can't find >>> the exact results now, but the difference was in order of magnitude - >>> IIRC concurrent hash map was about 20x faster than local cache. There >>> was no 'bottleneck', but the versatile Infinispan design of commands >>> traversing through interceptor stack brings some overhead (e.g. >>> allocation costs with each invocation, not only for writes) while in >>> some use cases it is not necessary to keep this complexity. The use case >>> I am looking for is caching in Hibernate ORM, which basically requires >>> only map with eviction, expiration and transactions in some cases. No >>> need for cache stores, statistics etc. So far I've found ways to remove >>> few interceptors [1], but it's few percent, not hundreds of percent >>> where I would ideally aim. >>> >>> Therefore, I was considering about an option to inspect cache >>> configuration and in suitable cases return LocalCacheImpl that would get >>> rid of the burden: no interceptor stack, no commands instantiation. This >>> would be transparent to the user. I understand that it will increase >>> maintenance costs, but it still seems better to me to have it under >>> wings of Infinispan as caching solution rather than separate project, as >>> it can share a lot of the codebase. >>> >>> Do you think that this idea makes sense, or is it just too wild? Do you >>> think I will crash when trying to implement this? >>> >>> Radim >>> >>> [1] https://issues.jboss.org/browse/ISPN-5542 >>> >>> -- >>> 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 From emmanuel at hibernate.org Mon Jun 22 09:15:12 2015 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Mon, 22 Jun 2015 09:15:12 -0400 Subject: [infinispan-dev] Interceptor stack for local caches In-Reply-To: References: <5587EF03.7090108@redhat.com> <8CCC4EB9-7442-4FF5-95FD-70E006565625@hibernate.org> <7415CF42-E0BD-4285-860B-26527E3C0E9B@hibernate.org> Message-ID: <83F5C3A3-667E-49B6-9D25-738D9ACEEAEC@hibernate.org> Ah. Tristan told me these plans are already in motion in stages. > On 22 juin 2015, at 08:09, Emmanuel Bernard wrote: > > Pushing the idea further, you can actually make the CacheImpl specifically tailored to the configuration of a given cache by using ASM or anything that lets you build a class at runtime. > That way, in this specialized implementation, all the interceptorImpl.before() and interceptorImpl.after() are specific non megamorphic calls that are optimizable and inline-able by the VM. > > And you don?t suffer for the maintenance overhead that Radim was pointing at. > > All of these ideas rely on a split of the interceptor logic into before() and after() methods. > > Emmanuel > >> On 22 Jun 2015, at 07:47, Emmanuel Bernard wrote: >> >> BTW, a generic interface based call to interceptors is hard to optimize by the VM AFAIU. >> So having a few specialized implementations of CacheImpl that do hard code the calls to specific interceptor implementations (the 2 methods split ones) would make a lot of sense to me for a handful of selected cases like you are describing Radim. >> >>> On 22 juin 2015, at 07:42, Emmanuel Bernard wrote: >>> >>> I am no expect at all of the code base. >>> Wouldn't returning LocalCacheImpl happening in very very specific cases and thus not be of quite limited use? >>> >>> And that resonates with the discussion of splitting the interceptor logic into before and after methods. And keeping the state not in the interceptor but in a type less stack passed to these methods. That would probably reduce the unnecessary allocation you are seeing. This also opened the doors for moving locks outside the execution thread AFAIR. >>> >>> Was this approach ever put on paper even as a few paragraphs somewhere ? >>> >>>> On 22 juin 2015, at 07:18, Radim Vansa wrote: >>>> >>>> Hi, >>>> >>>> few weeks ago I was looking into performance of local cache when >>>> compared to basic concurrent hash map, or data container. I can't find >>>> the exact results now, but the difference was in order of magnitude - >>>> IIRC concurrent hash map was about 20x faster than local cache. There >>>> was no 'bottleneck', but the versatile Infinispan design of commands >>>> traversing through interceptor stack brings some overhead (e.g. >>>> allocation costs with each invocation, not only for writes) while in >>>> some use cases it is not necessary to keep this complexity. The use case >>>> I am looking for is caching in Hibernate ORM, which basically requires >>>> only map with eviction, expiration and transactions in some cases. No >>>> need for cache stores, statistics etc. So far I've found ways to remove >>>> few interceptors [1], but it's few percent, not hundreds of percent >>>> where I would ideally aim. >>>> >>>> Therefore, I was considering about an option to inspect cache >>>> configuration and in suitable cases return LocalCacheImpl that would get >>>> rid of the burden: no interceptor stack, no commands instantiation. This >>>> would be transparent to the user. I understand that it will increase >>>> maintenance costs, but it still seems better to me to have it under >>>> wings of Infinispan as caching solution rather than separate project, as >>>> it can share a lot of the codebase. >>>> >>>> Do you think that this idea makes sense, or is it just too wild? Do you >>>> think I will crash when trying to implement this? >>>> >>>> Radim >>>> >>>> [1] https://issues.jboss.org/browse/ISPN-5542 >>>> >>>> -- >>>> 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 > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev From rvansa at redhat.com Mon Jun 22 09:28:02 2015 From: rvansa at redhat.com (Radim Vansa) Date: Mon, 22 Jun 2015 15:28:02 +0200 Subject: [infinispan-dev] Interceptor stack for local caches In-Reply-To: References: <5587EF03.7090108@redhat.com> <8CCC4EB9-7442-4FF5-95FD-70E006565625@hibernate.org> <7415CF42-E0BD-4285-860B-26527E3C0E9B@hibernate.org> Message-ID: <55880D62.4090605@redhat.com> @ 'very very specific cases': yes, given the plethora of options Infinispan gives you, it is specific. However that does not say that these use cases are not the most common. I don't think this has really too much common with the interceptor stack rework discussion - there the move is from vars on thread stack to vars in programmatic structure. Still, commands will be allocated and the interceptor stack with megamorphic calls as well. Not sure if I understand the second response, but naturally the lightweight implementation would reuse some of the building blocks from the reactive Infinispan initiative, if that suits the purpose. Radim On 06/22/2015 02:09 PM, Emmanuel Bernard wrote: > Pushing the idea further, you can actually make the CacheImpl specifically tailored to the configuration of a given cache by using ASM or anything that lets you build a class at runtime. > That way, in this specialized implementation, all the interceptorImpl.before() and interceptorImpl.after() are specific non megamorphic calls that are optimizable and inline-able by the VM. > > And you don?t suffer for the maintenance overhead that Radim was pointing at. > > All of these ideas rely on a split of the interceptor logic into before() and after() methods. > > Emmanuel > >> On 22 Jun 2015, at 07:47, Emmanuel Bernard wrote: >> >> BTW, a generic interface based call to interceptors is hard to optimize by the VM AFAIU. >> So having a few specialized implementations of CacheImpl that do hard code the calls to specific interceptor implementations (the 2 methods split ones) would make a lot of sense to me for a handful of selected cases like you are describing Radim. >> >>> On 22 juin 2015, at 07:42, Emmanuel Bernard wrote: >>> >>> I am no expect at all of the code base. >>> Wouldn't returning LocalCacheImpl happening in very very specific cases and thus not be of quite limited use? >>> >>> And that resonates with the discussion of splitting the interceptor logic into before and after methods. And keeping the state not in the interceptor but in a type less stack passed to these methods. That would probably reduce the unnecessary allocation you are seeing. This also opened the doors for moving locks outside the execution thread AFAIR. >>> >>> Was this approach ever put on paper even as a few paragraphs somewhere ? >>> >>>> On 22 juin 2015, at 07:18, Radim Vansa wrote: >>>> >>>> Hi, >>>> >>>> few weeks ago I was looking into performance of local cache when >>>> compared to basic concurrent hash map, or data container. I can't find >>>> the exact results now, but the difference was in order of magnitude - >>>> IIRC concurrent hash map was about 20x faster than local cache. There >>>> was no 'bottleneck', but the versatile Infinispan design of commands >>>> traversing through interceptor stack brings some overhead (e.g. >>>> allocation costs with each invocation, not only for writes) while in >>>> some use cases it is not necessary to keep this complexity. The use case >>>> I am looking for is caching in Hibernate ORM, which basically requires >>>> only map with eviction, expiration and transactions in some cases. No >>>> need for cache stores, statistics etc. So far I've found ways to remove >>>> few interceptors [1], but it's few percent, not hundreds of percent >>>> where I would ideally aim. >>>> >>>> Therefore, I was considering about an option to inspect cache >>>> configuration and in suitable cases return LocalCacheImpl that would get >>>> rid of the burden: no interceptor stack, no commands instantiation. This >>>> would be transparent to the user. I understand that it will increase >>>> maintenance costs, but it still seems better to me to have it under >>>> wings of Infinispan as caching solution rather than separate project, as >>>> it can share a lot of the codebase. >>>> >>>> Do you think that this idea makes sense, or is it just too wild? Do you >>>> think I will crash when trying to implement this? >>>> >>>> Radim >>>> >>>> [1] https://issues.jboss.org/browse/ISPN-5542 >>>> >>>> -- >>>> 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 > > _______________________________________________ > 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 Mon Jun 22 11:52:41 2015 From: galder at redhat.com (Galder Zamarreno) Date: Mon, 22 Jun 2015 11:52:41 -0400 (EDT) Subject: [infinispan-dev] Interceptor stack for local caches In-Reply-To: <5587EF03.7090108@redhat.com> References: <5587EF03.7090108@redhat.com> Message-ID: <1950519728.7103425.1434988361016.JavaMail.zimbra@redhat.com> As Sanne suggested in another email, the minimum you'd need for a local non-JTA (e.g. only JDBC transactions) 2LC is the data container and the eviction part, e.g. LIRs. You could try to work something around those and see how far you get. Once you have JTA or clustering, you'd need more bells and whistles. Cheers, ----- Original Message ----- > Hi, > > few weeks ago I was looking into performance of local cache when > compared to basic concurrent hash map, or data container. I can't find > the exact results now, but the difference was in order of magnitude - > IIRC concurrent hash map was about 20x faster than local cache. There > was no 'bottleneck', but the versatile Infinispan design of commands > traversing through interceptor stack brings some overhead (e.g. > allocation costs with each invocation, not only for writes) while in > some use cases it is not necessary to keep this complexity. The use case > I am looking for is caching in Hibernate ORM, which basically requires > only map with eviction, expiration and transactions in some cases. No > need for cache stores, statistics etc. So far I've found ways to remove > few interceptors [1], but it's few percent, not hundreds of percent > where I would ideally aim. > > Therefore, I was considering about an option to inspect cache > configuration and in suitable cases return LocalCacheImpl that would get > rid of the burden: no interceptor stack, no commands instantiation. This > would be transparent to the user. I understand that it will increase > maintenance costs, but it still seems better to me to have it under > wings of Infinispan as caching solution rather than separate project, as > it can share a lot of the codebase. > > Do you think that this idea makes sense, or is it just too wild? Do you > think I will crash when trying to implement this? > > Radim > > [1] https://issues.jboss.org/browse/ISPN-5542 > > -- > Radim Vansa > JBoss Performance Team > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev > From ttarrant at redhat.com Mon Jun 22 16:45:05 2015 From: ttarrant at redhat.com (Tristan Tarrant) Date: Mon, 22 Jun 2015 22:45:05 +0200 Subject: [infinispan-dev] Weekly IRC Meeting minutes 2015-06-22 Message-ID: <558873D1.7000804@redhat.com> Hi, find the minutes here: http://transcripts.jboss.org/meeting/irc.freenode.org/infinispan/2015/infinispan.2015-06-22-14.03.log.html Cheers Tristan -- Tristan Tarrant Infinispan Lead JBoss, a division of Red Hat