Re: [infinispan-dev] JGroupsDistSync and ISPN-83
The more I research ReentrantReadWriteLock the more shocked I am. Not only that a thread wanting to acquire write lock first has to release read lock, but we can block forever even if we release the read lock if we have acquired that read lock reentrantly. Each call to unlock just reduces the hold count, and the lock is only actually released when the hold count hits zero. Surreal! People have already debated this issue: http://stackoverflow.com/questions/464784/java-reentrantreadwritelocks-how-to-safely-acquire-write-lock In conlusion we have to seriously revisit all our uses of ReentrantReadWriteLock! Vladimir On 11-05-10 11:31 AM, Vladimir Blagojevic wrote: Hi, Would you please confirm my understanding and reading of javadoc for ReentrantReadWriteLock under section for lock downgrading. It says: Reentrancy also allows downgrading from the write lock to a read lock, by acquiring the write lock, then the read lock and then releasing the write lock. However, upgrading from a read lock to the write lock is not possible. ReentrantReadWriteLock javadoc code example with class CacheData also shows how a thread owning a read lock first has to release it in order to obtain a write lock! So a thread owning a read lock first has to release a read lock in order to obtain a write lock? This is very symptomatic in logs of ISPN-83 such as this one https://issues.jboss.org/secure/attachment/12341409/server1.log Recall how FLUSH stops all invocations on cluster and therefore all read lock acquisitions in JGroupsDistSync ultimately enabling smooth write lock acquisitions for state transfer and what not. In conclusion this leads me wondering if the culprit of all this FLUSH mess is rooted in read/write lock semantics from above? Regards, Vladimir ___ 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] JGroupsDistSync and ISPN-83
On Wed, May 11, 2011 at 11:25 AM, Vladimir Blagojevic vblag...@redhat.com wrote: The more I research ReentrantReadWriteLock the more shocked I am. Not only that a thread wanting to acquire write lock first has to release read lock, but we can block forever even if we release the read lock if we have acquired that read lock reentrantly. Each call to unlock just reduces the hold count, and the lock is only actually released when the hold count hits zero. Surreal! If ReentrantReadWriteLock would allow upgrades then you would get a deadlock when two threads both hold the read lock and try to upgrade to a write lock at the same time. There's always a trade-off... I'm not familiar with the code, but are you sure the read lock is being held by the same thread that is trying to acquire the write lock? Dan People have already debated this issue: http://stackoverflow.com/questions/464784/java-reentrantreadwritelocks-how-to-safely-acquire-write-lock In conlusion we have to seriously revisit all our uses of ReentrantReadWriteLock! Vladimir On 11-05-10 11:31 AM, Vladimir Blagojevic wrote: Hi, Would you please confirm my understanding and reading of javadoc for ReentrantReadWriteLock under section for lock downgrading. It says: Reentrancy also allows downgrading from the write lock to a read lock, by acquiring the write lock, then the read lock and then releasing the write lock. However, upgrading from a read lock to the write lock is not possible. ReentrantReadWriteLock javadoc code example with class CacheData also shows how a thread owning a read lock first has to release it in order to obtain a write lock! So a thread owning a read lock first has to release a read lock in order to obtain a write lock? This is very symptomatic in logs of ISPN-83 such as this one https://issues.jboss.org/secure/attachment/12341409/server1.log Recall how FLUSH stops all invocations on cluster and therefore all read lock acquisitions in JGroupsDistSync ultimately enabling smooth write lock acquisitions for state transfer and what not. In conclusion this leads me wondering if the culprit of all this FLUSH mess is rooted in read/write lock semantics from above? Regards, Vladimir ___ 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
[infinispan-dev] ISPN-1049
Hi, I've added a possible solution to https://issues.jboss.org/browse/ISPN-1049, can you please take a look and tell me what you think? Cheers, Mircea ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
[infinispan-dev] https://issues.jboss.org/browse/ISPN-977
Hi, The basic problem behind this is that I need to be notified when a new consistent hash is installed. ATM there isn't any support (of which I know) for a @ConsistenHashChangeListener. I'm thinking to add such notifications either: a) internally: Observer pattern on DistributionManager or even on DistributionManagerImpl b) more generically, as a fully flagged listener. I favor a) and then if more people ask for it we will expose it as a fully flagged listener. Suggestions? Cheers, Mircea ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] https://issues.jboss.org/browse/ISPN-977
On 11 May 2011, at 13:29, Sanne Grinovero wrote: First thing I thought when reading your email was OMG do we support on-the-fly hash implementation changes? crazy! That's obviously not the case, but if you name it as @ConsistenHashChangeListene that's what I would think. good point :-) ConsistentHashMembershipChange perhaps? Wouldn't it be better to change the exact timing of the viewchange event? I don't see why Infinispan users might be more interested in knowing about the topology details according to the transport than what they are about the actual Infinispan hashing topology - I would expect that when I receive which notification the new view is already installed and ready to go; actually I thought that was the case since ever. What would be the use cases to get the notification *before* the new hash is installed? @ViewChanged listener is a CacheManager listener, so it's independent of the caches in that are in use. It is possible for the CacheManager to wait for all its distributed caches to install the view first, and only then dispatch the @ViewChange event, Not sure that's a good idea in the general case, though. Cheers, Sanne 2011/5/11 Mircea Markus mircea.mar...@jboss.com: Hi, The basic problem behind this is that I need to be notified when a new consistent hash is installed. ATM there isn't any support (of which I know) for a @ConsistenHashChangeListener. I'm thinking to add such notifications either: a) internally: Observer pattern on DistributionManager or even on DistributionManagerImpl b) more generically, as a fully flagged listener. I favor a) and then if more people ask for it we will expose it as a fully flagged listener. Suggestions? Cheers, Mircea ___ 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] https://issues.jboss.org/browse/ISPN-977
2011/5/11 Mircea Markus mircea.mar...@jboss.com: On 11 May 2011, at 13:29, Sanne Grinovero wrote: First thing I thought when reading your email was OMG do we support on-the-fly hash implementation changes? crazy! That's obviously not the case, but if you name it as @ConsistenHashChangeListene that's what I would think. good point :-) ConsistentHashMembershipChange perhaps? Wouldn't it be better to change the exact timing of the viewchange event? I don't see why Infinispan users might be more interested in knowing about the topology details according to the transport than what they are about the actual Infinispan hashing topology - I would expect that when I receive which notification the new view is already installed and ready to go; actually I thought that was the case since ever. What would be the use cases to get the notification *before* the new hash is installed? @ViewChanged listener is a CacheManager listener, so it's independent of the caches in that are in use. It is possible for the CacheManager to wait for all its distributed caches to install the view first, and only then dispatch the @ViewChange event, Not sure that's a good idea in the general case, though. let's talk about use cases. As an application developer building something cool on top of Infinispan, what's the point in receiving an event about new nodes being joined, if they're not ready to be used? I'd rather have you notify me when new nodes joined and I can actually start using them; the rest is low-level detail that an application shouldn't worry about - I think - but I'm ready to take it back if you find an example for which that's not true. Sanne Cheers, Sanne 2011/5/11 Mircea Markus mircea.mar...@jboss.com: Hi, The basic problem behind this is that I need to be notified when a new consistent hash is installed. ATM there isn't any support (of which I know) for a @ConsistenHashChangeListener. I'm thinking to add such notifications either: a) internally: Observer pattern on DistributionManager or even on DistributionManagerImpl b) more generically, as a fully flagged listener. I favor a) and then if more people ask for it we will expose it as a fully flagged listener. Suggestions? Cheers, Mircea ___ 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 ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] https://issues.jboss.org/browse/ISPN-977
On 11 May 2011, at 15:53, Sanne Grinovero wrote: 2011/5/11 Mircea Markus mircea.mar...@jboss.com: On 11 May 2011, at 13:29, Sanne Grinovero wrote: First thing I thought when reading your email was OMG do we support on-the-fly hash implementation changes? crazy! That's obviously not the case, but if you name it as @ConsistenHashChangeListene that's what I would think. good point :-) ConsistentHashMembershipChange perhaps? Wouldn't it be better to change the exact timing of the viewchange event? I don't see why Infinispan users might be more interested in knowing about the topology details according to the transport than what they are about the actual Infinispan hashing topology - I would expect that when I receive which notification the new view is already installed and ready to go; actually I thought that was the case since ever. What would be the use cases to get the notification *before* the new hash is installed? @ViewChanged listener is a CacheManager listener, so it's independent of the caches in that are in use. It is possible for the CacheManager to wait for all its distributed caches to install the view first, and only then dispatch the @ViewChange event, Not sure that's a good idea in the general case, though. let's talk about use cases. As an application developer building something cool on top of Infinispan, what's the point in receiving an event about new nodes being joined, if they're not ready to be used? I'd rather have you notify me when new nodes joined and I can actually start using them; the rest is low-level detail that an application shouldn't worry about - I think - but I'm ready to take it back if you find an example for which that's not true. TBH I can't find a convincing-enough use case to write down :-) There is a small semantic (again theory!) difference between @ViewChanged and @NodeJoined (which is a really cool replacement-name for ConsistentHashMembershipChange btw). ViewChange happens sooner than NodeJoined. This can be a matter of nanos or even seconds (timeout is by default 10 secs) - depending on how long the state transfer takes. I'd love to see other opinions around this as well. ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] [Pull Request] Modular Classloading Compatibility
Were we developing for OSGi I would certainly agree with you. However in many environments today we can reasonably expect the TCCL to be set and to be able to load the classes we need. So whilst making it part of the API is the safest option, it's also making complicated an API for the sake of the few at the cost of the many. Further this also seems kinda nasty to me. We know the class (and hence bundle/module) when we put the object into Infinispan, therefore why do we require people to respecify this again? David, can we not actually do something here akin to what we are discussing for Weld? Whereby we can serialize out the bundle id and then find the correct CL based on that when we deserialize. On 9 May 2011, at 20:57, David Bosschaert wrote: Yeah, the bottom line is that the value of the TCCL is not defined by the OSGi standards. You can define it yourself by setting it before you call the relevant code but as said before this is ugly and it's actually very error-prone because there's nothing in the API to remind you to do it, so you might forget the odd time (it's effectively a hidden argument to the API). To make things even worse, there is a chance that the TCCL is not unset after previous use which means that its value might happen to be correct in some cases and incorrect in others - which is what the issue in the post seems to be hitting. I think making this part of the API explicit is the safest option. Yes, it requires people to think about classloading who don't like to think about classloading, but generally passing in getClass().getClassLoader() is all that's needed to get the right one... Just my 2c, David On 09/05/2011 18:01, Galder Zamarreño wrote: Guys, It's funny that we're talking about this but this appears to be precisely the use case that we don't support as per user forum post in: http://community.jboss.org/thread/166080?tstart=0 Pete, do we have a JIRA for this? If not, would you mind creating one? Cheers, On May 9, 2011, at 5:37 PM, Pete Muir wrote: Ok, let me stew on that ;-) On 9 May 2011, at 16:35, David Bosschaert wrote: If you have a Bundle object or BundleContext object you can figure out what classloader is associated with that. Also, if you have a class from a bundle you can find out what it's classloader is (obviously). However, you need to have one of those things to find this out. There is nothing magically available in the current context to tell you what the current Bundle is. It's generally really easy for the caller though to find out what the classloader is, though... If you have bundle X, you'd know a class from that bundle a.b.c.D (any class will do). Then you can simply call D.class.getClassLoader() and you've got the Bundle Classloader. Hope this helps, David On 09/05/2011 16:27, Pete Muir wrote: The issue that David raises is that in an OSGi env that this wouldn't be done by OSGi so would be up to the user or would require some extra integration library. I'm not even sure if this is possible in OSGi? David, is there anyway for a framework to find out the current bundle classloader in OSGi rather than having to be told it (i.e. push rather than pull)? The idea is that in AS that by doing (a) it would require the integration to make sure the TCCL is set before Infinispan is called (this is the way many things are integrated into GF for example). On 5 May 2011, at 20:05, Emmanuel Bernard wrote: Quick question. In case of 2.a (ie setting the TCCL), this is a requirement for frameworks and libraries using Infinispan, right? Not / never for a user application using Infinispan (in this case it seems that the application class loader will do the right thing and is set as the TCCL by the AS environment)? Emmanuel On 5 mai 2011, at 10:55, Pete Muir wrote: I talked about this with Emmanuel last night, and we were a) concerned about the pollution of the API that this implies b) not sure why we need to do this So I also spoke to Jason to understand his initial motivation, and from this chat I think it's clear that things have gone off course here. Jason raised two issues with modularity/classloading in Infinispan: 1) Using the TCCL as the classloader to load Infinispan classes is a bad idea. Instead we should use org.infinispan.foo.Bar.getClass().getClassLoader(). 2) When we need to load application classes we need a different approach to that used today. Most of the time the TCCL is perfect for this. However *sometimes* Infinispan may be invoked outside of the application, when the TCCL may not be set in AS7. Jason and I discussed three options: a) require (through a platform integration documentation contract) that the TCCL must always be set when Infinispan is invoked. b) Have some sort of InvocationContext which knows what the correct classloader to use is (aka Hibernate/Seam/Weld design
Re: [infinispan-dev] https://issues.jboss.org/browse/ISPN-977
On Wed, May 11, 2011 at 5:51 PM, Mircea Markus mircea.mar...@jboss.com wrote: On 11 May 2011, at 13:57, Dan Berindei wrote: With the new push-based rebalancing code, we install the new CH before doing any rebalancing work, so the inconsistency window should be much smaller. In theory we also block new transactions, maybe you could use that to stop generating new keys while rehashing. that's sounds interesting, I'll take a look! On the other hand, in 5.0 you should be able to implement KeyAffinityService on top of Pete's grouping work for https://issues.jboss.org/browse/ISPN-312 and then you won't need any listeners. Not sure how could that work? KAS generates pseudo-random keys that map to a certain nice. It's up to the user to place them in cache at some point, if ever. I was thinking of wrapping the keys generated by the user's KeyGenerator together with a node address in our own MagicKey class and set the @Group annotation on the address field. We already have a MagicKey class for testing, the only problem with it is that it only uses the address for hashing so you'd get lots of collisions. With Pete's changes MagicKey becomes something we can actually expose to the users (I was thinking through the KeyAffinityService API). I didn't think this through however, because MagicKeyK would have to extend K in order to satisfy the KeyAffinityService API (and even to be able to store the key in the CacheK,V later). Your question does raise an interesting point, though: a new node can join between the user call to KeyAffinityService.getKeyForAddress(address) and Cache.put(generatedKey), making generatedKey map to the new node. So there is no way for us to completely eliminate the issue of stale keys. Dan On Wed, May 11, 2011 at 3:29 PM, Sanne Grinovero sanne.grinov...@gmail.com wrote: First thing I thought when reading your email was OMG do we support on-the-fly hash implementation changes? crazy! That's obviously not the case, but if you name it as @ConsistenHashChangeListene that's what I would think. Wouldn't it be better to change the exact timing of the viewchange event? I don't see why Infinispan users might be more interested in knowing about the topology details according to the transport than what they are about the actual Infinispan hashing topology - I would expect that when I receive which notification the new view is already installed and ready to go; actually I thought that was the case since ever. What would be the use cases to get the notification *before* the new hash is installed? Cheers, Sanne 2011/5/11 Mircea Markus mircea.mar...@jboss.com: Hi, The basic problem behind this is that I need to be notified when a new consistent hash is installed. ATM there isn't any support (of which I know) for a @ConsistenHashChangeListener. I'm thinking to add such notifications either: a) internally: Observer pattern on DistributionManager or even on DistributionManagerImpl b) more generically, as a fully flagged listener. I favor a) and then if more people ask for it we will expose it as a fully flagged listener. Suggestions? Cheers, Mircea ___ 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 ___ 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] storeAsBinary: serialize keys, values, or both?
The current behaviour is both. But there are good reasons for finer grained control. Please have a look at https://issues.jboss.org/browse/ISPN-1097 and let me know what you think! Cheers Manik -- Manik Surtani ma...@jboss.org twitter.com/maniksurtani Lead, Infinispan http://www.infinispan.org ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] storeAsBinary: serialize keys, values, or both?
I'm also wondering how the equals is performed on a serialized key; I assume they are compared as byte[], but if that's the case that should be clearly documented as it would ignore any custom equals() implementation. If instead all keys are deserialized for each equals operation... well I suppose the internal datacontainer won't perform that well. Sanne 2011/5/11 Manik Surtani ma...@jboss.org: The current behaviour is both. But there are good reasons for finer grained control. Please have a look at https://issues.jboss.org/browse/ISPN-1097 and let me know what you think! Cheers Manik -- Manik Surtani ma...@jboss.org twitter.com/maniksurtani Lead, Infinispan http://www.infinispan.org ___ 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] https://issues.jboss.org/browse/ISPN-977
Wouldn't any rehash affect the locality of these generated keys, or am I missing something? Erik -Original Message- From: infinispan-dev-boun...@lists.jboss.org [mailto:infinispan-dev-boun...@lists.jboss.org] On Behalf Of Dan Berindei Sent: Wednesday, May 11, 2011 12:47 PM To: infinispan -Dev List Subject: Re: [infinispan-dev] https://issues.jboss.org/browse/ISPN-977 On Wed, May 11, 2011 at 5:51 PM, Mircea Markus mircea.mar...@jboss.com wrote: On 11 May 2011, at 13:57, Dan Berindei wrote: With the new push-based rebalancing code, we install the new CH before doing any rebalancing work, so the inconsistency window should be much smaller. In theory we also block new transactions, maybe you could use that to stop generating new keys while rehashing. that's sounds interesting, I'll take a look! On the other hand, in 5.0 you should be able to implement KeyAffinityService on top of Pete's grouping work for https://issues.jboss.org/browse/ISPN-312 and then you won't need any listeners. Not sure how could that work? KAS generates pseudo-random keys that map to a certain nice. It's up to the user to place them in cache at some point, if ever. I was thinking of wrapping the keys generated by the user's KeyGenerator together with a node address in our own MagicKey class and set the @Group annotation on the address field. We already have a MagicKey class for testing, the only problem with it is that it only uses the address for hashing so you'd get lots of collisions. With Pete's changes MagicKey becomes something we can actually expose to the users (I was thinking through the KeyAffinityService API). I didn't think this through however, because MagicKeyK would have to extend K in order to satisfy the KeyAffinityService API (and even to be able to store the key in the CacheK,V later). Your question does raise an interesting point, though: a new node can join between the user call to KeyAffinityService.getKeyForAddress(address) and Cache.put(generatedKey), making generatedKey map to the new node. So there is no way for us to completely eliminate the issue of stale keys. Dan On Wed, May 11, 2011 at 3:29 PM, Sanne Grinovero sanne.grinov...@gmail.com wrote: First thing I thought when reading your email was OMG do we support on-the-fly hash implementation changes? crazy! That's obviously not the case, but if you name it as @ConsistenHashChangeListene that's what I would think. Wouldn't it be better to change the exact timing of the viewchange event? I don't see why Infinispan users might be more interested in knowing about the topology details according to the transport than what they are about the actual Infinispan hashing topology - I would expect that when I receive which notification the new view is already installed and ready to go; actually I thought that was the case since ever. What would be the use cases to get the notification *before* the new hash is installed? Cheers, Sanne 2011/5/11 Mircea Markus mircea.mar...@jboss.com: Hi, The basic problem behind this is that I need to be notified when a new consistent hash is installed. ATM there isn't any support (of which I know) for a @ConsistenHashChangeListener. I'm thinking to add such notifications either: a) internally: Observer pattern on DistributionManager or even on DistributionManagerImpl b) more generically, as a fully flagged listener. I favor a) and then if more people ask for it we will expose it as a fully flagged listener. Suggestions? Cheers, Mircea ___ 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 ___ 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 The information contained in this message is legally privileged and confidential, and is intended for the individual or entity to whom it is addressed (or their designee). If this message is read by anyone other than the intended recipient, please be advised that distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete or destroy all copies of this message. ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org
[infinispan-dev] IDEA:building non-OSGi libraries...
Hi, Whenever I'm switching branches from 4.2.x to master the build in IDEA takes ages(even more, about 5 mins!!!). Most of the time is spent is Building non-OSGi libraries for module... Any idea on what can be done to speed things up? Cheers, Mircea ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] [Pull Request] Modular Classloading Compatibility
On 11/05/2011 17:54, Dan Berindei wrote: On Wed, May 11, 2011 at 7:08 PM, Pete Muirpm...@redhat.com wrote: Were we developing for OSGi I would certainly agree with you. However in many environments today we can reasonably expect the TCCL to be set and to be able to load the classes we need. So whilst making it part of the API is the safest option, it's also making complicated an API for the sake of the few at the cost of the many. Further this also seems kinda nasty to me. We know the class (and hence bundle/module) when we put the object into Infinispan, therefore why do we require people to respecify this again? David, can we not actually do something here akin to what we are discussing for Weld? Whereby we can serialize out the bundle id and then find the correct CL based on that when we deserialize. What if the object is a java.util.ArrayList? Each element in the list could belong to a different bundle, so you'd have to write a bundle id for every element in the list. Yes, if you know the Bundle-SymbolicName and Version (or the Bundle ID) you can find its classloader. On the other question, if you're passing in a class object then you can obtain its classloader and hence the bundle where it came from. But, and I think this is what Dan allused to above, is it always true that the class your passing in comes from the bundle that you need to have or could it also come from one of its parent class loaders? Cheers, David ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
