Re: [infinispan-dev] 5.0.0.CR5
I'll be mainly working on perf bechmark, so no deliverables from me. On 7 Jun 2011, at 17:19, Manik Surtani ma...@jboss.org wrote: Hi guys What do we have in store for CR5? What's been committed since CR4, and what's in the pipeline for CR5? Does a release on Monday (13th) make sense? 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
[infinispan-dev] infinispan-server-core build fails
I'm getting the following compilation error: http://pastebin.com/n14N3Jig It seems like the property has gone completely? -- Trustin Lee, http://gleamynode.net/ ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] infinispan-server-core build fails
https://github.com/infinispan/infinispan/pull/361 2011/6/8 Sanne Grinovero sanne.grinov...@gmail.com: sorry, I didn't setup the scala projects in my ide so didn't catch that. We can revert the commit now, but as a next step should this not use JBoss Logger now? Sanne 2011/6/8 Manik Surtani ma...@jboss.org: Probably related to this commit: https://github.com/infinispan/infinispan/commit/26782de8f4662c2dca7a0e62b5d246c677f98a41 Sanne (author)/Galder (committer): any idea why this wasn't picked up? Cheers Manik On 8 Jun 2011, at 09:13, 이희승 (Trustin Lee) wrote: I'm getting the following compilation error: http://pastebin.com/n14N3Jig It seems like the property has gone completely? -- Trustin Lee, http://gleamynode.net/ ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev -- 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] infinispan-server-core build fails
Merged. Thanks! Trustin - works now? On 8 Jun 2011, at 09:41, Sanne Grinovero wrote: https://github.com/infinispan/infinispan/pull/361 2011/6/8 Sanne Grinovero sanne.grinov...@gmail.com: sorry, I didn't setup the scala projects in my ide so didn't catch that. We can revert the commit now, but as a next step should this not use JBoss Logger now? Sanne 2011/6/8 Manik Surtani ma...@jboss.org: Probably related to this commit: https://github.com/infinispan/infinispan/commit/26782de8f4662c2dca7a0e62b5d246c677f98a41 Sanne (author)/Galder (committer): any idea why this wasn't picked up? Cheers Manik On 8 Jun 2011, at 09:13, 이희승 (Trustin Lee) wrote: I'm getting the following compilation error: http://pastebin.com/n14N3Jig It seems like the property has gone completely? -- Trustin Lee, http://gleamynode.net/ ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev -- 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 -- 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] infinispan-server-core build fails
Also, Galder - shouldn't our CloudBees setup catch things like this and email the author/committer? On 8 Jun 2011, at 10:08, Manik Surtani wrote: Merged. Thanks! Trustin - works now? On 8 Jun 2011, at 09:41, Sanne Grinovero wrote: https://github.com/infinispan/infinispan/pull/361 2011/6/8 Sanne Grinovero sanne.grinov...@gmail.com: sorry, I didn't setup the scala projects in my ide so didn't catch that. We can revert the commit now, but as a next step should this not use JBoss Logger now? Sanne 2011/6/8 Manik Surtani ma...@jboss.org: Probably related to this commit: https://github.com/infinispan/infinispan/commit/26782de8f4662c2dca7a0e62b5d246c677f98a41 Sanne (author)/Galder (committer): any idea why this wasn't picked up? Cheers Manik On 8 Jun 2011, at 09:13, 이희승 (Trustin Lee) wrote: I'm getting the following compilation error: http://pastebin.com/n14N3Jig It seems like the property has gone completely? -- Trustin Lee, http://gleamynode.net/ ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev -- 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 -- 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 -- 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] 5.0.0.CR5
I've only got ISPN-1092 to review with Pete and some improvements planned around ISPN-1000. Monday sounds good. Dan On Wed, Jun 8, 2011 at 9:08 AM, Mircea Markus mmar...@redhat.com wrote: I'll be mainly working on perf bechmark, so no deliverables from me. On 7 Jun 2011, at 17:19, Manik Surtani ma...@jboss.org wrote: Hi guys What do we have in store for CR5? What's been committed since CR4, and what's in the pipeline for CR5? Does a release on Monday (13th) make sense? 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 ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] 5.0.0.CR5
I consider ISPN-1154 quite blocking, at least for the Lucene / Hibernate Search needs. I'm assuming that it could affect the Hibernate 2nd level cache as well, but this was not tested, and as it was never reported maybe it's not true. Anyway, Monday seems a feasible target; I hope to find a solution or at least a workaround soon. Sanne 2011/6/8 Dan Berindei dan.berin...@gmail.com: I've only got ISPN-1092 to review with Pete and some improvements planned around ISPN-1000. Monday sounds good. Dan On Wed, Jun 8, 2011 at 9:08 AM, Mircea Markus mmar...@redhat.com wrote: I'll be mainly working on perf bechmark, so no deliverables from me. On 7 Jun 2011, at 17:19, Manik Surtani ma...@jboss.org wrote: Hi guys What do we have in store for CR5? What's been committed since CR4, and what's in the pipeline for CR5? Does a release on Monday (13th) make sense? 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 ___ 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] [Pull Request] Modular Classloading Compatibility
Apologies for my long absence from this thread. On 20 May 2011, at 15:28, Jason T. Greene wrote: On 5/18/11 11:06 AM, Manik Surtani wrote: 1) Class loader per session/cache. I like Jason/Sanne/Trustin's suggestions of a session-like contract, and specifically I think this is best achieved as a delegate to a cache, again as suggested elsewhere by Pete, etc. E.g., Cache?, ? myCache = cacheManager.getCache(myCache, myClassLoader); -snip- I would recommend leaving this open to store other per-session configuration values (perhaps with a builder), and some of them mutable. This will allow you to completely eliminate the ThreadLocal context stuff used today which is both faster and more robust (the gc will clean up the state for you). Are you suggesting something like: cacheManager.withClassLoader(myClassLoader).getCache(myCache); thus allowing future expansions such as: cacheManager.withClassLoader(myClassLoader).withSomeOtherParam(param).getCache() ? I do like this, since it doesn't pollute the basic cache manager API methods like getCache(). 2) Class loader per invocation. If this session notion has some mutable values, you could also make CL mutable: cacheSession.setClassLoader(blah); cacheSession.setFlags(FORCE_WRITE_LOCK) Yes, no reason why the delegate Cache can't do this. These setters would need to exist on the Cache interface though. For now, we should just restrict to setClassLoader(). From an implementation perspective, given where we are with 5.0 now, I suggest we implement by holding the ClassLoader in the CacheDelegate impl, and each method invocation impl would: 1) Set TCCL with the instance's ClassLoader field 2) Do work 3) In a finally block, reset TCCL. This is just a temp measure, since I don't want to re-work how Marshallers, etc get a hold of the class loader. They use TCCLs right now, and while sub-optimal in many ways, this approach gives us an easy mechanism to implement while still preventing any leaks, etc otherwise common with TCCLs. 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] [Pull Request] Modular Classloading Compatibility
On 20 May 2011, at 15:39, Jason T. Greene wrote: So I think to ever justify it, it would take some very convincing numbers that eager deserialization is indeed better. Agreed. -- 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] 5.0.0.CR5
I have https://issues.jboss.org/browse/ISPN-1112 pending. That should be done by Monday. On Jun 7, 2011, at 6:19 PM, Manik Surtani wrote: Hi guys What do we have in store for CR5? What's been committed since CR4, and what's in the pipeline for CR5? Does a release on Monday (13th) make sense? 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 -- 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
Re: [infinispan-dev] fixing eviction with transactions (critical for Hibernate Search)
On Jun 7, 2011, at 2:41 PM, Mircea Markus wrote: On 7 Jun 2011, at 13:13, Sanne Grinovero wrote: Hello all, in this scenario we have the Infinispan Lucene Directory using batching (DummyTransaction), eviction and passivation to keep the amount of memory being used for the index under control; I'm using LIRS but experienced the same issue with all other strategies. As you can see from the following stacktrace, the batching ends by sending a commit request, so the status of the transaction is 8 (STATUS_COMMITTING) in this context. The new data is stored in the DataContainer, then the BoundedConcurrentHashMap notifies the EvictionManagerImpl as it has to evict some values, and this one attempts to acquire a lock on the to-be-evicted keys (which are obviously not the same I'm trying to store). Acquiring this lock is an invalid operation as the transaction is in commit state, and so this operation fails with an exception. Thread [Hibernate Search: Directory writer-1] (Suspended (breakpoint at line 92 in LockManagerImpl)) LockManagerImpl.lockAndRecord(Object, InvocationContext) line: 92 EvictionManagerImpl.acquireLock(InvocationContext, Object) line: 210 EvictionManagerImpl.onEntryEviction(Object, InternalCacheEntry) line: 170 EvictionManagerImpl.onEntryEviction(MapObject,InternalCacheEntry) line: 162 DefaultDataContainer$DefaultEvictionListener.onEntryEviction(MapObject,InternalCacheEntry) line: 201 BoundedConcurrentHashMap$SegmentK,V.notifyEvictionListener(SetHashEntryK,V) line: 1176 BoundedConcurrentHashMap$SegmentK,V.put(K, int, V, boolean) line: 1011 BoundedConcurrentHashMapK,V.put(K, V) line: 1556 DefaultDataContainer.put(Object, Object, long, long) line: 148 ReadCommittedEntry.commit(DataContainer) line: 177 LockingInterceptor.commitEntry(CacheEntry, boolean) line: 389 LockingInterceptor.cleanupLocks(InvocationContext, boolean) line: 367 LockingInterceptor.visitCommitCommand(TxInvocationContext, CommitCommand) line: 98 CommitCommand.acceptVisitor(InvocationContext, Visitor) line: 60 CacheStoreInterceptor(CommandInterceptor).invokeNextInterceptor(InvocationContext, VisitableCommand) line: 119 CacheStoreInterceptor.visitCommitCommand(TxInvocationContext, CommitCommand) line: 148 CommitCommand.acceptVisitor(InvocationContext, Visitor) line: 60 CacheLoaderInterceptor(CommandInterceptor).invokeNextInterceptor(InvocationContext, VisitableCommand) line: 119 CacheLoaderInterceptor(CommandInterceptor).handleDefault(InvocationContext, VisitableCommand) line: 133 CacheLoaderInterceptor(AbstractVisitor).visitCommitCommand(TxInvocationContext, CommitCommand) line: 116 CommitCommand.acceptVisitor(InvocationContext, Visitor) line: 60 NotificationInterceptor(CommandInterceptor).invokeNextInterceptor(InvocationContext, VisitableCommand) line: 119 NotificationInterceptor.visitCommitCommand(TxInvocationContext, CommitCommand) line: 56 CommitCommand.acceptVisitor(InvocationContext, Visitor) line: 60 TxInterceptor(CommandInterceptor).invokeNextInterceptor(InvocationContext, VisitableCommand) line: 119 TxInterceptor.visitCommitCommand(TxInvocationContext, CommitCommand) line: 142 CommitCommand.acceptVisitor(InvocationContext, Visitor) line: 60 CacheMgmtInterceptor(CommandInterceptor).invokeNextInterceptor(InvocationContext, VisitableCommand) line: 119 CacheMgmtInterceptor(CommandInterceptor).handleDefault(InvocationContext, VisitableCommand) line: 133 CacheMgmtInterceptor(AbstractVisitor).visitCommitCommand(TxInvocationContext, CommitCommand) line: 116 CommitCommand.acceptVisitor(InvocationContext, Visitor) line: 60 InvocationContextInterceptor(CommandInterceptor).invokeNextInterceptor(InvocationContext, VisitableCommand) line: 119 InvocationContextInterceptor.handleAll(InvocationContext, VisitableCommand) line: 96 InvocationContextInterceptor.handleDefault(InvocationContext, VisitableCommand) line: 63 InvocationContextInterceptor(AbstractVisitor).visitCommitCommand(TxInvocationContext, CommitCommand) line: 116 CommitCommand.acceptVisitor(InvocationContext, Visitor) line: 60 BatchingInterceptor(CommandInterceptor).invokeNextInterceptor(InvocationContext, VisitableCommand) line: 119 BatchingInterceptor.handleDefault(InvocationContext, VisitableCommand) line: 77 BatchingInterceptor(AbstractVisitor).visitCommitCommand(TxInvocationContext, CommitCommand) line: 116 CommitCommand.acceptVisitor(InvocationContext, Visitor) line: 60 InterceptorChain.invoke(InvocationContext, VisitableCommand) line: 274 TransactionCoordinator.commit(LocalTransaction, boolean) line: 136
Re: [infinispan-dev] Defining new commands in modules
https://issues.jboss.org/browse/ISPN-1162 On Jun 8, 2011, at 3:23 AM, Israel Lacerra wrote: Hi Galder. An easy way to test is to use Manik's sample (https://github.com/infinispan/infinispan-sample-module). Just change the id of BulkDeleteCommand to a core command id (like 22). Israel On Mon, Jun 6, 2011 at 7:29 AM, Galder Zamarreño gal...@redhat.com wrote: Israel, do you have a test case for this? On Jun 6, 2011, at 7:23 AM, Israel Lacerra wrote: Manik, I think there is a little problem. If a custom command use the same id of a core command...no exception is thrown. cheers Israel On Thu, Mar 10, 2011 at 9:25 PM, Israel Lacerra israe...@gmail.com wrote: Manik, It's look pretty fine to me and will solve my problem :) Israel On Tue, Mar 8, 2011 at 11:43 AM, Manik Surtani ma...@jboss.org wrote: On 7 Mar 2011, at 13:02, Mircea Markus wrote: Nice stuff! What do you think from the perspective of having to implement your own commands, say for the continuous query prototype you did? Does it fit with that model? Also, any more feedback from module authors that need this (looking at Sanne and Israel!)? If not, I'll go ahead and issue a pull req... 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 -- 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 -- 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] CacheDelegate
Looking at the Class Loading discussion, part of the confusion is that CacheDelegate doesn't do what it says. Delegate is normally used to described the thing that a decorator delegates calls to. To avoid confusion, I would like to rename CacheDelegate. I would propose it ComposedCache (as it's a Cache impl which is composed of various services which actually implement the Cache itself). Alternatively we could go with CacheImpl. Any concerns? ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] CacheDelegate
+2 to CacheImpl, +1 to ComposedCache, -1 to CacheDelegate (i.e., I support the rename) On 8 Jun 2011, at 12:38, Pete Muir wrote: Looking at the Class Loading discussion, part of the confusion is that CacheDelegate doesn't do what it says. Delegate is normally used to described the thing that a decorator delegates calls to. To avoid confusion, I would like to rename CacheDelegate. I would propose it ComposedCache (as it's a Cache impl which is composed of various services which actually implement the Cache itself). Alternatively we could go with CacheImpl. Any concerns? ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev -- 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] Old JBoss repo in pom.xml
What was the fix around this? To remove the hard-coded repo in the poms? On 31 May 2011, at 09:46, Galder Zamarreño wrote: I'm fine with it. I think Adrian added it but clearly, all jars should be available in the Nexus maven profile. This has been fixed and integrated and build looks fine. On May 26, 2011, at 4:12 PM, Sanne Grinovero wrote: So this got quite urgent right now: http://repository.jboss.org/maven2 is now returning not authorized, we all knew it was deprecated since long time, but now it's gone and this is affecting my build and blocking my work. Even if I fix it locally, it's still troublesome as people depending on these poms will download it, get it in their cache, and then spend hours to figure out what's wrong, because right now Maven3 is not even being explicit on what is broken (I had to use -X and read the full log to figure this out). My current workaround is to define mirrors in my own settings.xml. Seems to me a good reason to remove all these references, or at least fix the links; I'm voting to remove them, but have no strong feeling about it as Pete's objections are interesting as well; just that I don't think we risk loosing good contributors or users, we might loose someone which doesn't have a clue on how Maven works, but if they're good and interested they'll find the wiki or ask for help; most people I know don't need to add this as if you use artifactory or nexus the jboss.org repository is already proxies by default, and others might have the URL setup already because they used JBoss community projects too. Either way, we should take a decision urgently. https://issues.jboss.org/browse/ISPN-1142 Cheers, Sanne 2011/5/19 Pete Muir pm...@redhat.com: On 19 May 2011, at 11:40, Sanne Grinovero wrote: 2011/5/19 Pete Muir pm...@redhat.com: The one argument for putting the (new) repo in the pom is that does make getting started contributing easier, and buildable on a clean system with no changes. Maven guys used to recommend not putting repos in poms, but they changed that a while back and now don't discourage it. Still I've been consulting in some big companies where there are rules about it: projects having poms defining a repository can not be used. Makes it too hard to create a controlled build environment. Yes, and note that i'm certainly not advocating putting any old repo in a pom. As Tristan says, we should require that everything is in the jboss repo. I'm simply proposing putting the jboss repo in the POM as it is our canonical repo. I also assume that at some point we might want to have our artifacts synched with central, I doubt they will accept poms pointing to other repositories, that was not the case before but it might have changed. Agreed, but see my other email, having them in settings.xml is just as bad/worse at this point. I'd avoid that. people using our artifacts learned how to configure their settings already, or wouldn't be able to build infinispan core anyway. I would hope we are planning to attract some new users ;-) On 19 May 2011, at 10:58, Manik Surtani wrote: On 19 May 2011, at 09:52, Galder Zamarreño wrote: Hi all, So, what's our current approach towards hardcoding maven repositories in the pom.xml files? Should we allow JBoss repos to be defined master/parent/pom.xml? This was added by Adrian C when he upgraded JClouds: repository idjboss/id urlhttp://repository.jboss.org/maven2/url /repository First of all, this is a deprecated repo and not sure it should even be amongst the configured repositories. Secondly, the idea so far has been that users configure the JBoss Maven repo in their settings.xml - http://community.jboss.org/wiki/MavenGettingStarted-Users I think we should still stick to putting it in settings.xml since even as a bootstrap for project X to reach infinispan jars, you'd need the JBoss repo either in project X's pom or in settings.xml. Now in some cases I've seen third-party repos exposed in certain modules' poms. This needs to be assessed on a case-by-case basis, but is generally discouraged. For example, infinispan-spring declares a repo which contains some Spring 3.1 milestone artefacts, and cachestore-cloud points to a repo with JClouds milestones/snapshots. -- 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 -- 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 -- Manik Surtani ma...@jboss.org twitter.com/maniksurtani Lead,
Re: [infinispan-dev] Possible Bug in Distribution Manager
Has an update fixed your problem, Pedro?
On 2 Jun 2011, at 14:47, Pedro Ruivo wrote:
Hi,
Yes I'm using a old version of Infinispan. I will do the update.
Cheers,
Pedro
On 02-06-2011 13:20, infinispan-dev-requ...@lists.jboss.org wrote:
Hi Pedro, From your logs it looks like the CH function has duplicate
addresses in it and that's what's causing some nodes to return the
same owner twice: 12:04:03,505 TRACE [DistributionManagerImpl] New CH
is DefaultConsistentHash{addresses ={73=node09-42492,
848=node02-34421, 1849=node03-61513, 1850=node03-61513,
2093=node10-3814, 2094=node10-3814, 2380=node08-968, 2381=node08-968,
3182=node04-53049, 3183=node04-53049, *5868=node07-42120,
5869=node07-42120,* 5914=node05-23599, 5915=node05-23599,
6410=node01-27066, 6978=node06-24999, 8485=node11-42115,
8486=node11-42115}, hash space =10240} How old is your snapshot? Since
5.0.0.ALPHA4 the CH interface uses SetAddress, so duplicates should
never happen. I think it would be better to use the latest CR release
instead, 5.0.0.CR3, so you (and us) know exactly what code you're
using. Cheers Dan I think my changes for ISPN-110 On Wed, Jun 1, 2011
at 7:49 PM, Pedro Ruivo pru...@gsd.inesc-id.pt wrote:
Hi,
My name is Pedro and I am working in CloudTM project.
I think that I may have encountered a possible bug in the consistent
hash function.
I am working on Infinispan 'Pagoa' 5.0.0-SNAPSHOT with JGroups 3.0.0
Alpha1 and I have a total of 100 000 keys distributed by 11 nodes.
I am using Radargun, that was modified to execute the maximum number of
transactions in a 5 minutes run. All transactions updates at least one
key, ie, I didn't have read-only transactions.
At the end of the test, ?I am printing all the keys and their location
(keys' owners), and, as you can see for instance here [1], different
nodes have different opinions concerning which replicas are in charge of
storing some keys.
Note that I didn't change anything in the distribution code and my tests
only update keys, never delete them.
Part of the log can be found in [2] and the config file is in [3]. In
the log file we have a lot of 'WARN ?[DistLockingInterceptor] xxx entry
commit warmup_key(...) = ?Thread(...)'. Ignore this entries.
Unfortunately, the problem does not always show up, in my tests this
shows up, say, 5% of the times.
Did this ever happen to you, or am I hitting a known issue?
I hope that the information that I am providing can be sufficient to
reproduce the bug, let me know if there is anything else that I can do
to help
Cheers
Pedro
[1] -http://pastebin.com/Pp47ctj9
[2] -http://pastebin.com/tpSXqVmV
[3] -http://pastebin.com/vjVP48L2
--
INESC-ID Lisboa, sala 511
gsd.inesc-id.pt/~pruivo
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
INESC-ID Lisboa, sala 511
gsd.inesc-id.pt/~pruivo
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
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] Local state transfer before going over network
On 24 May 2011, at 11:33, Mircea Markus wrote: Merkle trees would do much better than key-by-key comparison. +1. Is there a JIRA for this? Anyone wants to take this on, I would target this at 6.0 though. -- 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] [Pull Request] Modular Classloading Compatibility
On 8 Jun 2011, at 11:42, Dan Berindei wrote: Yes, no reason why the delegate Cache can't do this. These setters would need to exist on the Cache interface though. For now, we should just restrict to setClassLoader(). From an implementation perspective, given where we are with 5.0 now, I suggest we implement by holding the ClassLoader in the CacheDelegate impl, and each method invocation impl would: 1) Set TCCL with the instance's ClassLoader field 2) Do work 3) In a finally block, reset TCCL. This is just a temp measure, since I don't want to re-work how Marshallers, etc get a hold of the class loader. They use TCCLs right now, and while sub-optimal in many ways, this approach gives us an easy mechanism to implement while still preventing any leaks, etc otherwise common with TCCLs. The CacheDelegate instance returned by CM.getCache() is shared between all the users that called getCache(), so if we want different users to have different classloaders I think we need another Cache wrapper class that will set/reset the TCCL. Yes, that's what I have in mind. -- 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] Infinispan Shell Console
Very cool stuff! You should link to this from http://community.jboss.org/wiki/Infinispan and maybe write a wiki page about it. If you want to blog about it as well, I can give you write access to http://infinispan.blogspot.com/ - ping me off-list if you want this. :-) Cheers Manik On 26 May 2011, at 10:44, Michal Linhard wrote: Hi all! Announcing my little project Infinispan Console: https://github.com/mlinhard/ispncon I wanted to wait with publishing of this until I do some more testing, but I don't know when I'll get to that, and it already helps me with some testing and I thought that it might be useful to some of you too, so I don't wanna keep it to myself any longer... it basically enables you to do stuff like ispncon put key value ispncon get key from your bash, using client access (hotrod, memcached, rest) - I.e. you have to have these server modules running/deployed in a container. feedback is appreciated. m. -- Michal Linhard Quality Assurance Engineer Red Hat Czech s.r.o. Purkynova 99 612 45 Brno, Czech Republic phone: +420 532 294 320 ext. 62320 mobile: +420 728 626 363 ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev -- 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] chunking ability on the JDBC cacheloader
On 23 May 2011, at 18:05, Sanne Grinovero wrote: I was more concerned about the fact that some database might not raise any exception ? Not sure if that's the case, and possibly not our problem. Yes, not sure how we can detect this. -- 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] Infinispan Shell Console
On 06/08/2011 02:06 PM, Manik Surtani wrote: Very cool stuff! You should link to this from http://community.jboss.org/wiki/Infinispan and maybe write a wiki page about it. If you want to blog about it as well, O.K. I'll try to prepare something on the jboss.org wiki and then link it from the wiki docs page. Which section would you insert the link to ? what about User Guide 22. Infinispan Command-Line Console When I finish the docs I can write a short announcement on the blog as well... I'll ping you for the access then. I can give you write access to http://infinispan.blogspot.com/ - ping me off-list if you want this. :-) Cheers Manik On 26 May 2011, at 10:44, Michal Linhard wrote: Hi all! Announcing my little project Infinispan Console: https://github.com/mlinhard/ispncon I wanted to wait with publishing of this until I do some more testing, but I don't know when I'll get to that, and it already helps me with some testing and I thought that it might be useful to some of you too, so I don't wanna keep it to myself any longer... it basically enables you to do stuff like ispncon put key value ispncon get key from your bash, using client access (hotrod, memcached, rest) - I.e. you have to have these server modules running/deployed in a container. feedback is appreciated. m. -- Michal Linhard Quality Assurance Engineer Red Hat Czech s.r.o. Purkynova 99 612 45 Brno, Czech Republic phone: +420 532 294 320 ext. 62320 mobile: +420 728 626 363 ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Manik Surtani ma...@jboss.org mailto:ma...@jboss.org twitter.com/maniksurtani http://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 -- Michal Linhard Quality Assurance Engineer Red Hat Czech s.r.o. Purkynova 99 612 45 Brno, Czech Republic phone: +420 532 294 320 ext. 62320 mobile: +420 728 626 363 ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] Infinispan Shell Console
On 8 Jun 2011, at 13:24, Michal Linhard wrote: On 06/08/2011 02:06 PM, Manik Surtani wrote: Very cool stuff! You should link to this from http://community.jboss.org/wiki/Infinispan and maybe write a wiki page about it. If you want to blog about it as well, O.K. I'll try to prepare something on the jboss.org wiki and then link it from the wiki docs page. Which section would you insert the link to ? what about User Guide 22. Infinispan Command-Line Console +1 When I finish the docs I can write a short announcement on the blog as well... I'll ping you for the access then. Sure - 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] Old JBoss repo in pom.xml
On Wed, Jun 8, 2011 at 12:59 PM, Manik Surtani ma...@jboss.org wrote: What was the fix around this? To remove the hard-coded repo in the poms? No, I removed the old deprecated repository.jboss.org/maven2 as this was offline and pretty urgent, and re-adapted the build to be able to build without it (needed to add/reconfigure other repository definitions, especially for the scala compiler). Now the repository is back online so the patch would not have been that urgent, but it's good that we don't depend on the deprecated one any more. I still wonder if we should not remove all repository references, but as we didn't find an agreement on that I didn't change it for the time being. Sanne On 31 May 2011, at 09:46, Galder Zamarreño wrote: I'm fine with it. I think Adrian added it but clearly, all jars should be available in the Nexus maven profile. This has been fixed and integrated and build looks fine. On May 26, 2011, at 4:12 PM, Sanne Grinovero wrote: So this got quite urgent right now: http://repository.jboss.org/maven2 is now returning not authorized, we all knew it was deprecated since long time, but now it's gone and this is affecting my build and blocking my work. Even if I fix it locally, it's still troublesome as people depending on these poms will download it, get it in their cache, and then spend hours to figure out what's wrong, because right now Maven3 is not even being explicit on what is broken (I had to use -X and read the full log to figure this out). My current workaround is to define mirrors in my own settings.xml. Seems to me a good reason to remove all these references, or at least fix the links; I'm voting to remove them, but have no strong feeling about it as Pete's objections are interesting as well; just that I don't think we risk loosing good contributors or users, we might loose someone which doesn't have a clue on how Maven works, but if they're good and interested they'll find the wiki or ask for help; most people I know don't need to add this as if you use artifactory or nexus the jboss.org repository is already proxies by default, and others might have the URL setup already because they used JBoss community projects too. Either way, we should take a decision urgently. https://issues.jboss.org/browse/ISPN-1142 Cheers, Sanne 2011/5/19 Pete Muir pm...@redhat.com: On 19 May 2011, at 11:40, Sanne Grinovero wrote: 2011/5/19 Pete Muir pm...@redhat.com: The one argument for putting the (new) repo in the pom is that does make getting started contributing easier, and buildable on a clean system with no changes. Maven guys used to recommend not putting repos in poms, but they changed that a while back and now don't discourage it. Still I've been consulting in some big companies where there are rules about it: projects having poms defining a repository can not be used. Makes it too hard to create a controlled build environment. Yes, and note that i'm certainly not advocating putting any old repo in a pom. As Tristan says, we should require that everything is in the jboss repo. I'm simply proposing putting the jboss repo in the POM as it is our canonical repo. I also assume that at some point we might want to have our artifacts synched with central, I doubt they will accept poms pointing to other repositories, that was not the case before but it might have changed. Agreed, but see my other email, having them in settings.xml is just as bad/worse at this point. I'd avoid that. people using our artifacts learned how to configure their settings already, or wouldn't be able to build infinispan core anyway. I would hope we are planning to attract some new users ;-) On 19 May 2011, at 10:58, Manik Surtani wrote: On 19 May 2011, at 09:52, Galder Zamarreño wrote: Hi all, So, what's our current approach towards hardcoding maven repositories in the pom.xml files? Should we allow JBoss repos to be defined master/parent/pom.xml? This was added by Adrian C when he upgraded JClouds: repository idjboss/id urlhttp://repository.jboss.org/maven2/url /repository First of all, this is a deprecated repo and not sure it should even be amongst the configured repositories. Secondly, the idea so far has been that users configure the JBoss Maven repo in their settings.xml - http://community.jboss.org/wiki/MavenGettingStarted-Users I think we should still stick to putting it in settings.xml since even as a bootstrap for project X to reach infinispan jars, you'd need the JBoss repo either in project X's pom or in settings.xml. Now in some cases I've seen third-party repos exposed in certain modules' poms. This needs to be assessed on a case-by-case basis, but is generally discouraged. For example, infinispan-spring declares a repo which contains some
Re: [infinispan-dev] 5.0.0.CR5
Same here. I hope to finally put these FLUSH issues behind! On 11-06-08 6:32 AM, Galder Zamarreño wrote: I have https://issues.jboss.org/browse/ISPN-1112 pending. That should be done by Monday. On Jun 7, 2011, at 6:19 PM, Manik Surtani wrote: Hi guys What do we have in store for CR5? What's been committed since CR4, and what's in the pipeline for CR5? Does a release on Monday (13th) make sense? 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 -- 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] Old JBoss repo in pom.xml
On 8 Jun 2011, at 13:54, Sanne Grinovero wrote: On Wed, Jun 8, 2011 at 1:52 PM, Pete Muir pm...@redhat.com wrote: This may be old news, but if something is missing from the new (ish ;-) r.j.o, but available in another repo, you can email Paul Gier and ask for that repo to be added to the r.j.o consolidated repo. Se we could collect all needed dependencies and add them to jboss.org, so that nothing else is needed? Yes, I believe so. This should be the correct approach. Let me look into this. 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] 5.0.0.CR5
I plan to get the classloading fixed by Monday. On 8 Jun 2011, at 13:59, Vladimir Blagojevic wrote: Same here. I hope to finally put these FLUSH issues behind! On 11-06-08 6:32 AM, Galder Zamarreño wrote: I have https://issues.jboss.org/browse/ISPN-1112 pending. That should be done by Monday. On Jun 7, 2011, at 6:19 PM, Manik Surtani wrote: Hi guys What do we have in store for CR5? What's been committed since CR4, and what's in the pipeline for CR5? Does a release on Monday (13th) make sense? 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 -- 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] [Pull Request] Modular Classloading Compatibility
On 8 Jun 2011, at 14:06, Pete Muir wrote: We've decided that rather than swap out the TCCL (which is frankly a bit error prone), to fix this properly and have it so that each time a class is loaded it must select the classloaders it wants. To help, we will add an advancedCache.getClassLoader(), which defaults to the TCCL but can be overridden as described below. As a first step, I have removed the TCCL from the default lookup in Util (AFAICT all class loading was going through there), and required that, if you want to lookup app classes (as opposed to Infinispan classes) you explicitly pass in a classloader. I have then passed in the TCCL as a parameter throughout the codebase. This now makes it explicit where the TCCL is being used and should mean that any new work does think about whether they need to look at app classes or not. Under this new scheme we have 45 refs to the TCCL in the codebase. Some of these are: a) not needed, we are only ever loading system classes b) can, with a bit of a refactor, refer to the classloader we select using withClassLoader() c) other (these will be harder to fix :-() My plan is to go through each one, and chat with the owner of the code and discuss which of (a), (b) or (c) is relevant here. Sounds good. -- 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] fixing eviction with transactions (critical for Hibernate Search)
On 8 Jun 2011, at 11:44, Galder Zamarreño wrote: On Jun 7, 2011, at 2:41 PM, Mircea Markus wrote: On 7 Jun 2011, at 13:13, Sanne Grinovero wrote: Hello all, in this scenario we have the Infinispan Lucene Directory using batching (DummyTransaction), eviction and passivation to keep the amount of memory being used for the index under control; I'm using LIRS but experienced the same issue with all other strategies. As you can see from the following stacktrace, the batching ends by sending a commit request, so the status of the transaction is 8 (STATUS_COMMITTING) in this context. The new data is stored in the DataContainer, then the BoundedConcurrentHashMap notifies the EvictionManagerImpl as it has to evict some values, and this one attempts to acquire a lock on the to-be-evicted keys (which are obviously not the same I'm trying to store). Acquiring this lock is an invalid operation as the transaction is in commit state, and so this operation fails with an exception. Thread [Hibernate Search: Directory writer-1] (Suspended (breakpoint at line 92 in LockManagerImpl)) LockManagerImpl.lockAndRecord(Object, InvocationContext) line: 92 EvictionManagerImpl.acquireLock(InvocationContext, Object) line: 210 EvictionManagerImpl.onEntryEviction(Object, InternalCacheEntry) line: 170 EvictionManagerImpl.onEntryEviction(MapObject,InternalCacheEntry) line: 162 DefaultDataContainer$DefaultEvictionListener.onEntryEviction(MapObject,InternalCacheEntry) line: 201 BoundedConcurrentHashMap$SegmentK,V.notifyEvictionListener(SetHashEntryK,V) line: 1176 BoundedConcurrentHashMap$SegmentK,V.put(K, int, V, boolean) line: 1011 BoundedConcurrentHashMapK,V.put(K, V) line: 1556 DefaultDataContainer.put(Object, Object, long, long) line: 148 ReadCommittedEntry.commit(DataContainer) line: 177 LockingInterceptor.commitEntry(CacheEntry, boolean) line: 389 LockingInterceptor.cleanupLocks(InvocationContext, boolean) line: 367 LockingInterceptor.visitCommitCommand(TxInvocationContext, CommitCommand) line: 98 CommitCommand.acceptVisitor(InvocationContext, Visitor) line: 60 CacheStoreInterceptor(CommandInterceptor).invokeNextInterceptor(InvocationContext, VisitableCommand) line: 119 CacheStoreInterceptor.visitCommitCommand(TxInvocationContext, CommitCommand) line: 148 CommitCommand.acceptVisitor(InvocationContext, Visitor) line: 60 CacheLoaderInterceptor(CommandInterceptor).invokeNextInterceptor(InvocationContext, VisitableCommand) line: 119 CacheLoaderInterceptor(CommandInterceptor).handleDefault(InvocationContext, VisitableCommand) line: 133 CacheLoaderInterceptor(AbstractVisitor).visitCommitCommand(TxInvocationContext, CommitCommand) line: 116 CommitCommand.acceptVisitor(InvocationContext, Visitor) line: 60 NotificationInterceptor(CommandInterceptor).invokeNextInterceptor(InvocationContext, VisitableCommand) line: 119 NotificationInterceptor.visitCommitCommand(TxInvocationContext, CommitCommand) line: 56 CommitCommand.acceptVisitor(InvocationContext, Visitor) line: 60 TxInterceptor(CommandInterceptor).invokeNextInterceptor(InvocationContext, VisitableCommand) line: 119 TxInterceptor.visitCommitCommand(TxInvocationContext, CommitCommand) line: 142 CommitCommand.acceptVisitor(InvocationContext, Visitor) line: 60 CacheMgmtInterceptor(CommandInterceptor).invokeNextInterceptor(InvocationContext, VisitableCommand) line: 119 CacheMgmtInterceptor(CommandInterceptor).handleDefault(InvocationContext, VisitableCommand) line: 133 CacheMgmtInterceptor(AbstractVisitor).visitCommitCommand(TxInvocationContext, CommitCommand) line: 116 CommitCommand.acceptVisitor(InvocationContext, Visitor) line: 60 InvocationContextInterceptor(CommandInterceptor).invokeNextInterceptor(InvocationContext, VisitableCommand) line: 119 InvocationContextInterceptor.handleAll(InvocationContext, VisitableCommand) line: 96 InvocationContextInterceptor.handleDefault(InvocationContext, VisitableCommand) line: 63 InvocationContextInterceptor(AbstractVisitor).visitCommitCommand(TxInvocationContext, CommitCommand) line: 116 CommitCommand.acceptVisitor(InvocationContext, Visitor) line: 60 BatchingInterceptor(CommandInterceptor).invokeNextInterceptor(InvocationContext, VisitableCommand) line: 119 BatchingInterceptor.handleDefault(InvocationContext, VisitableCommand) line: 77 BatchingInterceptor(AbstractVisitor).visitCommitCommand(TxInvocationContext, CommitCommand) line: 116 CommitCommand.acceptVisitor(InvocationContext, Visitor) line: 60 InterceptorChain.invoke(InvocationContext, VisitableCommand) line: 274 TransactionCoordinator.commit(LocalTransaction, boolean) line: 136
Re: [infinispan-dev] Defining new commands in modules
So far command IDs have been bytes, so using ranges is harder. We'd need to change them to short or something bigger to be able to use ID ranges relatively safely. On Jun 8, 2011, at 2:25 PM, Manik Surtani wrote: Isn't the approach here to use well-known ID ranges? A bit like externalizers? On 6 Jun 2011, at 11:29, Galder Zamarreño wrote: Israel, do you have a test case for this? On Jun 6, 2011, at 7:23 AM, Israel Lacerra wrote: Manik, I think there is a little problem. If a custom command use the same id of a core command...no exception is thrown. cheers Israel On Thu, Mar 10, 2011 at 9:25 PM, Israel Lacerra israe...@gmail.com wrote: Manik, It's look pretty fine to me and will solve my problem :) Israel On Tue, Mar 8, 2011 at 11:43 AM, Manik Surtani ma...@jboss.org wrote: On 7 Mar 2011, at 13:02, Mircea Markus wrote: Nice stuff! What do you think from the perspective of having to implement your own commands, say for the continuous query prototype you did? Does it fit with that model? Also, any more feedback from module authors that need this (looking at Sanne and Israel!)? If not, I'll go ahead and issue a pull req... 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 -- 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 -- 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 -- 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
Re: [infinispan-dev] CacheDelegate
+1 CacheImp. On 8 Jun 2011, at 13:50, Sanne Grinovero wrote: +1, has been disturbing me as well :) On Wed, Jun 8, 2011 at 12:51 PM, Manik Surtani ma...@jboss.org wrote: +2 to CacheImpl, +1 to ComposedCache, -1 to CacheDelegate (i.e., I support the rename) On 8 Jun 2011, at 12:38, Pete Muir wrote: Looking at the Class Loading discussion, part of the confusion is that CacheDelegate doesn't do what it says. Delegate is normally used to described the thing that a decorator delegates calls to. To avoid confusion, I would like to rename CacheDelegate. I would propose it ComposedCache (as it's a Cache impl which is composed of various services which actually implement the Cache itself). Alternatively we could go with CacheImpl. Any concerns? ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev -- 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 ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] fixing eviction with transactions (critical for Hibernate Search)
On 8 Jun 2011, at 16:24, Sanne Grinovero wrote: I was mentioning passivation was enabled as debugging I saw it was going to invoke to the passivator, but I just realized that passivation was actually disabled in my configuration. So one thing I'm solving now, is that we don't need to lock if the passivator is disabled, as we're not going to do any operation with the lock held, besides potentially invoking user listeners. So this affects the 2nd level cache as well, as the bug kicks in regardless of the passivation being enabled). Some findings about this lock, after talking with Vladimir yesterday on irc: we realized that the lock is actually acquired *after* it was evicted from the container; so if the mission of this lock was to protect readers from reading the non-existing value, then we should acquire it before it's actually evicted; currently there's a smallish race condition possible, in which the value has been evicted but not stored yet; during the proper store operation which is likely the slowest part the lock is owned so this might prevent a get with locks to not find the value anywhere. So for this case maybe having the lock is a good idea, but could anybody confirm that having the lock would prevent an inconsistent read? Is this lock good enough here? There is still a race between evicting from the data container and acquiring the lock that a thread may attempt a read and find nothing. But even then this doesn't really help since this is a write lock we are talking about. Concurrent readers will not acquire a write (or even read) lock. The correct approach really should be: 1) Passivate entry to a CacheStore 2) Evict entry from data container with no need for a lock. This would mean the BoundedCHM would have a handle on the Passivator. 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] Cloudbees
We're now building and doing our testing in Cloudbees: https://infinispan.ci.cloudbees.com/ The old http://hudson.infinispan.org/ address is still pointing to our old Hudson installation, but we'll be shutting down very shortly and it will redirect to Cloudbees. 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
Re: [infinispan-dev] discussion about impact of using TransactionSynchronizationRegistry in AS7...
On 8 Jun 2011, at 11:57, Galder Zamarreño wrote: In the mean time, I can quickly modify the dummy TM to make the same check as JBoss TS and see whether it fails in the 2LC testsuite. -1. Better to just switch the testsuite to use JBossTS. -- 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] discussion about impact of using TransactionSynchronizationRegistry in AS7...
So what is the final proposed solution here? On 8 Jun 2011, at 01:07, Scott Marlow wrote: I just hit this case locally. http://pastie.org/2035067 This is running with a hacked AS7, in the sense that IronJacamar (JBJCA-594), Hibernate JPA and the EJB3.1 container are registering TSR interposed synchronizations (https://github.com/scottmarlow/jboss-as/commits/jpa_tsr). This is for a 2lc unit test running in AS7 (non-clustered). org.hibernate.engine.transaction.synchronization.internal.RegisteredSynchronization.beforeCompletion is already running, meaning that we cannot expect org.infinispan.transaction.TransactionTable.enlist() to succeed in its transaction.registerSynchronization(). Scott On 06/01/2011 03:49 PM, Scott Marlow wrote: I posted a message on the as7-dev ml (http://lists.jboss.org/pipermail/jboss-as7-dev/2011-May/002254.html), about switching to use the TransactionSynchronizationRegistry. Does Infinispan currently register Transaction synchronization objects? Does Infinispan currently register synchronizations via TransactionSynchronizationRegistry (TSR)? I'm trying to get a sense for, what would happen if container managed (AS7) session beans were registered with the active JTA transaction via the TSR. If AS7 switches to use the TSR, I think that Infinispan might need to ensure that it doesn't attempt to register with the TX too late. See http://pastie.org/1836698 for an example of what would happen if a TSR synchronization object is already present and someone tries to register a TX synchronization after tx.commit has been started. ___ 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 -- 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] fixing eviction with transactions (critical for Hibernate Search)
On 11-06-08 12:10 PM, Sanne Grinovero wrote: Yes, we're on the same channel now. That's exactly what I meant yesterday on IRC when mentioning the BoundedCHM, and what I meant above with we should acquire it before it's actually evicted. But this issue is getting complex, I've split it in 4 different problems and I'm going to solve the first three soon, the BoundedCHM is the fourth and I'm not sure I'll fix that today. Sanne, Sounds good, please consult us when it comes to changing BCHM! Cheers. ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
[infinispan-dev] does anyone else get scala build errors on master?
Can anyone suggest a workaround for the scala build errors I'm seeing http://pastie.org/2040797 Thanks, Scott ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] does anyone else get scala build errors on master?
Builds OK to me. There was some compilation errors due to the changes in LogFactory yesterday, but no problem since it's fixed. I just wish Scala had a faster compiler .. On 06/09/2011 11:56 AM, Scott Marlow wrote: Can anyone suggest a workaround for the scala build errors I'm seeing http://pastie.org/2040797 Thanks, Scott ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Trustin Lee, http://gleamynode.net/ ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
