Re: [infinispan-dev] Dynamic Externalizers sorted for ISPN-986 - looking for some feedback
+1 for Externalizer/AdvancedExternalizer. Dan On Tue, Apr 12, 2011 at 10:17 AM, Galder Zamarreño gal...@redhat.com wrote: On Apr 11, 2011, at 12:06 PM, Galder Zamarreño wrote: Guys, any thoughts on this? I want this in for BETA2... On Apr 1, 2011, at 5:54 PM, Galder Zamarreño wrote: Hi, Re: https://issues.jboss.org/browse/ISPN-986 As indicated in my comments, there's two room for two types of serialization mechanisms: one for end users and the other for SPIs. I've got a solution for this in https://github.com/galderz/infinispan/commit/09096f7998c0d0a5aae76d55bf59c72fe1cb510e and wanted to give a heads up to everyone on what it involves: - Two separate externalizer interfaces: Externalizer (which currently, to disrupt as little code as possible, is named EndUserExternalier) and ExternalizerSpi or ServiceProviderExternalizer (currently named Externalizer). The first API is basic read/write methods and the second one with a couple of more methods for more specialised behaivour. Do people like these names? Or can someone come up with better names? More detailed info on the use cases in the JIRA. I'm currently leaning towards: Externalizer (only readObject/writeObject methods) and ExternalizerSpi (would contain the current https://github.com/infinispan/infinispan/blob/master/core/src/main/java/org/infinispan/marshall/Externalizer.java) Actually, I don't like ExternalizerSpi name, it makes configuration getters ackward: getExternalizerSpis... Instead I'm leaning for: Externalizer and AdvancedExternalizer which maps very nicely with Cache and AdvancedCache and makes getters more readable: getAdvancedExternalizers much clearer :) - A related factor here would be to find a better name for the XML/programmatic configuration, i.e. getServiceProviderExternalizers()? serviceProviderExternalzer or getExternalizeSpis() externalizerSpi? This is one thing and the other is that I'd want this XML and programmatic configuration to be a bit hidden away cos it's specialised or for edge cases. The obvious route the average Infinispan user should be annotation and implement Infinispan's Externalizer interface. However, I'm don't think there's anything special that can be done in the current architechture of Infinispan without rethinking end user and spi configuration. Since the XML is only relevant for the SPI version, the programmatic API would go along the lines of getExternalizerSpis() and externalizerSpi - Naming methods like this gives a direct link to the interface name while not being too verbose - To hide JBoss Marshaller details away and to simplify some of the API it provides, I've created a new @MarshallableBy annotation that maps directly to what JBMAR's @Externalizer does. To get an idea of the differences for the end users, see https://github.com/galderz/infinispan/commit/09096f7998c0d0a5aae76d55bf59c72fe1cb510e#diff-10 as opposed to https://github.com/galderz/infinispan/commit/09096f7998c0d0a5aae76d55bf59c72fe1cb510e#diff-9. Are people happy with the annotation name? The cool thing is that if someone wants to really use JBoss Marshaller Externalizers, they can, but I think the majority will be happy with just a read/write object method. And that's about it! Afterwards it just needs proper documentation in wiki and javadocs, but right now I'm mostly focused at getting naming right. Thoughts? Ideally I'd like to get this into BETA1 (release date next Tuesday, 5th April), but I'll prob hold till BETA2 to get the naming right. Cheers, -- Galder Zamarreño Sr. Software Engineer Infinispan, JBoss Cache ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Galder Zamarreño Sr. Software Engineer Infinispan, JBoss Cache ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Galder Zamarreño Sr. Software Engineer Infinispan, JBoss Cache ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] Dynamic Externalizers sorted for ISPN-986 - looking for some feedback
On 12 Apr 2011, at 10:51, Dan Berindei wrote: +1 for Externalizer/AdvancedExternalizer. +1, we already do that for Cache/AdvancedCache. Dan On Tue, Apr 12, 2011 at 10:17 AM, Galder Zamarreño gal...@redhat.com wrote: On Apr 11, 2011, at 12:06 PM, Galder Zamarreño wrote: Guys, any thoughts on this? I want this in for BETA2... On Apr 1, 2011, at 5:54 PM, Galder Zamarreño wrote: Hi, Re: https://issues.jboss.org/browse/ISPN-986 As indicated in my comments, there's two room for two types of serialization mechanisms: one for end users and the other for SPIs. I've got a solution for this in https://github.com/galderz/infinispan/commit/09096f7998c0d0a5aae76d55bf59c72fe1cb510e and wanted to give a heads up to everyone on what it involves: - Two separate externalizer interfaces: Externalizer (which currently, to disrupt as little code as possible, is named EndUserExternalier) and ExternalizerSpi or ServiceProviderExternalizer (currently named Externalizer). The first API is basic read/write methods and the second one with a couple of more methods for more specialised behaivour. Do people like these names? Or can someone come up with better names? More detailed info on the use cases in the JIRA. I'm currently leaning towards: Externalizer (only readObject/writeObject methods) and ExternalizerSpi (would contain the current https://github.com/infinispan/infinispan/blob/master/core/src/main/java/org/infinispan/marshall/Externalizer.java) Actually, I don't like ExternalizerSpi name, it makes configuration getters ackward: getExternalizerSpis... Instead I'm leaning for: Externalizer and AdvancedExternalizer which maps very nicely with Cache and AdvancedCache and makes getters more readable: getAdvancedExternalizers much clearer :) - A related factor here would be to find a better name for the XML/programmatic configuration, i.e. getServiceProviderExternalizers()? serviceProviderExternalzer or getExternalizeSpis() externalizerSpi? This is one thing and the other is that I'd want this XML and programmatic configuration to be a bit hidden away cos it's specialised or for edge cases. The obvious route the average Infinispan user should be annotation and implement Infinispan's Externalizer interface. However, I'm don't think there's anything special that can be done in the current architechture of Infinispan without rethinking end user and spi configuration. Since the XML is only relevant for the SPI version, the programmatic API would go along the lines of getExternalizerSpis() and externalizerSpi - Naming methods like this gives a direct link to the interface name while not being too verbose - To hide JBoss Marshaller details away and to simplify some of the API it provides, I've created a new @MarshallableBy annotation that maps directly to what JBMAR's @Externalizer does. To get an idea of the differences for the end users, see https://github.com/galderz/infinispan/commit/09096f7998c0d0a5aae76d55bf59c72fe1cb510e#diff-10 as opposed to https://github.com/galderz/infinispan/commit/09096f7998c0d0a5aae76d55bf59c72fe1cb510e#diff-9. Are people happy with the annotation name? The cool thing is that if someone wants to really use JBoss Marshaller Externalizers, they can, but I think the majority will be happy with just a read/write object method. And that's about it! Afterwards it just needs proper documentation in wiki and javadocs, but right now I'm mostly focused at getting naming right. Thoughts? Ideally I'd like to get this into BETA1 (release date next Tuesday, 5th April), but I'll prob hold till BETA2 to get the naming right. Cheers, -- Galder Zamarreño Sr. Software Engineer Infinispan, JBoss Cache ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Galder Zamarreño Sr. Software Engineer Infinispan, JBoss Cache ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Galder Zamarreño Sr. Software Engineer Infinispan, JBoss Cache ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] distributed execution - invoking commands on self
can't you run the Callable locally on a clone of it? If Callable is Clonable then clone it in an orthodox manner, otherwise clone it by serializing/deseralizing it. On 11 Apr 2011, at 19:58, Vladimir Blagojevic wrote: Sanne, I thought about that as well but I do not see a way to ensure that all other commands have been sent to other nodes other than waiting for corresponding futures to return from get and then invoke locally in a serial fashion. I do not see a hook anywhere that will tell me when a command has been dropped on the wire! Vladimir On 11-04-11 2:21 PM, Sanne Grinovero wrote: 2011/4/11 Vladimir Blagojevicvblag...@redhat.com: Hi, I discovered a problem with distributed framework in cases where Callables submitted for distributed execution contain mutable instance fields. Just before Callable is dispersed across cluster it gets invoked locally where instance fields of a submitted Callable can be possibly mutated; Callable is in turn sent to remote nodes with mutated values instead of original field values as submitted by user. For example, consider pi approximation example from wiki [1]. If CircleTest Callable declared insideCircleCount as an instance field instead of local field of call method we would ultimately get a wrong final result. Therefore we need to ensure that each Infinispan node gets an unmodified instance of Callable for execution. I was looking at the possibility to send command to self thus causing creation of a marshaled copy of a Callable, pretty much like any other remote node receives it. However, I was unable to invoke a command on self. Any way to do this? How about invoking marshaling locally to create a Callable copy without going through rpc invocation layer? I though about skipping master/self node altogether but that's an easy way out;-) Got suggestions, ideas? Hi Vladimir, I've no clue about invoking a marshalled command on self, but could you not just make sure the local callable is being processed *after* you have created a serialized copy (sent it to others) ? ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] Dynamic Externalizers sorted for ISPN-986 - looking for some feedback
Yeah, eventually those were the names that made most sense to me. FYI, the pull req for this is up now: https://github.com/infinispan/infinispan/pull/245 I'm now working on updating http://community.jboss.org/docs/DOC-16198 On Apr 12, 2011, at 6:41 PM, Mircea Markus wrote: On 12 Apr 2011, at 10:51, Dan Berindei wrote: +1 for Externalizer/AdvancedExternalizer. +1, we already do that for Cache/AdvancedCache. Dan On Tue, Apr 12, 2011 at 10:17 AM, Galder Zamarreño gal...@redhat.com wrote: On Apr 11, 2011, at 12:06 PM, Galder Zamarreño wrote: Guys, any thoughts on this? I want this in for BETA2... On Apr 1, 2011, at 5:54 PM, Galder Zamarreño wrote: Hi, Re: https://issues.jboss.org/browse/ISPN-986 As indicated in my comments, there's two room for two types of serialization mechanisms: one for end users and the other for SPIs. I've got a solution for this in https://github.com/galderz/infinispan/commit/09096f7998c0d0a5aae76d55bf59c72fe1cb510e and wanted to give a heads up to everyone on what it involves: - Two separate externalizer interfaces: Externalizer (which currently, to disrupt as little code as possible, is named EndUserExternalier) and ExternalizerSpi or ServiceProviderExternalizer (currently named Externalizer). The first API is basic read/write methods and the second one with a couple of more methods for more specialised behaivour. Do people like these names? Or can someone come up with better names? More detailed info on the use cases in the JIRA. I'm currently leaning towards: Externalizer (only readObject/writeObject methods) and ExternalizerSpi (would contain the current https://github.com/infinispan/infinispan/blob/master/core/src/main/java/org/infinispan/marshall/Externalizer.java) Actually, I don't like ExternalizerSpi name, it makes configuration getters ackward: getExternalizerSpis... Instead I'm leaning for: Externalizer and AdvancedExternalizer which maps very nicely with Cache and AdvancedCache and makes getters more readable: getAdvancedExternalizers much clearer :) - A related factor here would be to find a better name for the XML/programmatic configuration, i.e. getServiceProviderExternalizers()? serviceProviderExternalzer or getExternalizeSpis() externalizerSpi? This is one thing and the other is that I'd want this XML and programmatic configuration to be a bit hidden away cos it's specialised or for edge cases. The obvious route the average Infinispan user should be annotation and implement Infinispan's Externalizer interface. However, I'm don't think there's anything special that can be done in the current architechture of Infinispan without rethinking end user and spi configuration. Since the XML is only relevant for the SPI version, the programmatic API would go along the lines of getExternalizerSpis() and externalizerSpi - Naming methods like this gives a direct link to the interface name while not being too verbose - To hide JBoss Marshaller details away and to simplify some of the API it provides, I've created a new @MarshallableBy annotation that maps directly to what JBMAR's @Externalizer does. To get an idea of the differences for the end users, see https://github.com/galderz/infinispan/commit/09096f7998c0d0a5aae76d55bf59c72fe1cb510e#diff-10 as opposed to https://github.com/galderz/infinispan/commit/09096f7998c0d0a5aae76d55bf59c72fe1cb510e#diff-9. Are people happy with the annotation name? The cool thing is that if someone wants to really use JBoss Marshaller Externalizers, they can, but I think the majority will be happy with just a read/write object method. And that's about it! Afterwards it just needs proper documentation in wiki and javadocs, but right now I'm mostly focused at getting naming right. Thoughts? Ideally I'd like to get this into BETA1 (release date next Tuesday, 5th April), but I'll prob hold till BETA2 to get the naming right. Cheers, -- Galder Zamarreño Sr. Software Engineer Infinispan, JBoss Cache ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Galder Zamarreño Sr. Software Engineer Infinispan, JBoss Cache ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Galder Zamarreño Sr. Software Engineer Infinispan, JBoss Cache ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev ___ infinispan-dev mailing list
Re: [infinispan-dev] 5.0.0.BETA2 this coming Friday?
I'm working full-speed on finishing JMX tooling on recovery. The coding might be finished but the review will take longer, so not sure it will get in. On 11 Apr 2011, at 11:09, Galder Zamarreño wrote: Hi all, I'm currently targeting BETA2 for this Friday. How does this sound? I know some of you will be busy with JAX London. Note that this is the last expected BETA, with CR1 planned for the week of 25th April. Please note that I'll be in Miracle Open World this week so my work will be cut out. Cheers, -- Galder Zamarreño Sr. Software Engineer Infinispan, JBoss Cache ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] distributed execution - invoking commands on self
Yeah, it would be too strict to require Callable to be Cloneable so I would opt out to serialization/deserialization as a clone method. Galder, do out have a recommended mechanism for this in your marshalers? Thanks Mircea On 11-04-12 12:59 PM, Mircea Markus wrote: can't you run the Callable locally on a clone of it? If Callable is Clonable then clone it in an orthodox manner, otherwise clone it by serializing/deseralizing it. On 11 Apr 2011, at 19:58, Vladimir Blagojevic wrote: Sanne, I thought about that as well but I do not see a way to ensure that all other commands have been sent to other nodes other than waiting for corresponding futures to return from get and then invoke locally in a serial fashion. I do not see a hook anywhere that will tell me when a command has been dropped on the wire! Vladimir On 11-04-11 2:21 PM, Sanne Grinovero wrote: 2011/4/11 Vladimir Blagojevicvblag...@redhat.com: Hi, I discovered a problem with distributed framework in cases where Callables submitted for distributed execution contain mutable instance fields. Just before Callable is dispersed across cluster it gets invoked locally where instance fields of a submitted Callable can be possibly mutated; Callable is in turn sent to remote nodes with mutated values instead of original field values as submitted by user. For example, consider pi approximation example from wiki [1]. If CircleTest Callable declared insideCircleCount as an instance field instead of local field of call method we would ultimately get a wrong final result. Therefore we need to ensure that each Infinispan node gets an unmodified instance of Callable for execution. I was looking at the possibility to send command to self thus causing creation of a marshaled copy of a Callable, pretty much like any other remote node receives it. However, I was unable to invoke a command on self. Any way to do this? How about invoking marshaling locally to create a Callable copy without going through rpc invocation layer? I though about skipping master/self node altogether but that's an easy way out;-) Got suggestions, ideas? Hi Vladimir, I've no clue about invoking a marshalled command on self, but could you not just make sure the local callable is being processed *after* you have created a serialized copy (sent it to others) ? ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev