Re: [infinispan-dev] CDI support
+1, I think so too. If you have the time, could you go ahead and merge it in to master? Some docs with examples + a blog about it would be awesome too. :) I presume this is something Kevin would do? On 13 Jul 2011, at 18:36, Sanne Grinovero wrote: Since you're the expert, if you like it and you think people could start using it, why not in 5.0 ? Being a tech preview and there are no related changes on the other modules, I think that would be fine. Sanne 2011/7/13 Pete Muir pm...@redhat.com: Kevin has completed this up a pretty good standard, so I think it's ready to merge. Do we want to try to slip this into Infinispan 5? It's a separate module so should have no impact on the rest of the code base. I would label it a tech preview, moving to final status in 5.1 but it will give people a taster. WDYT? ___ 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] CDI support
On 14 Jul 2011, at 10:36, Manik Surtani wrote: +1, I think so too. If you have the time, could you go ahead and merge it in to master? Some docs with examples + a blog about it would be awesome too. :) I presume this is something Kevin would do? I'll work with Kevin on this :-) On 13 Jul 2011, at 18:36, Sanne Grinovero wrote: Since you're the expert, if you like it and you think people could start using it, why not in 5.0 ? Being a tech preview and there are no related changes on the other modules, I think that would be fine. Sanne 2011/7/13 Pete Muir pm...@redhat.com: Kevin has completed this up a pretty good standard, so I think it's ready to merge. Do we want to try to slip this into Infinispan 5? It's a separate module so should have no impact on the rest of the code base. I would label it a tech preview, moving to final status in 5.1 but it will give people a taster. WDYT? ___ 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 ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] CDI support
On 14 Jul 2011, at 10:47, Pete Muir wrote: On 14 Jul 2011, at 10:36, Manik Surtani wrote: +1, I think so too. If you have the time, could you go ahead and merge it in to master? Some docs with examples + a blog about it would be awesome too. :) I presume this is something Kevin would do? I'll work with Kevin on this :-) You have write access to blog.infinispan.org, right? Do you think we should give Kevin write access as well? -- 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] CDI support
On 14 Jul 2011, at 11:35, Manik Surtani wrote: On 14 Jul 2011, at 10:47, Pete Muir wrote: On 14 Jul 2011, at 10:36, Manik Surtani wrote: +1, I think so too. If you have the time, could you go ahead and merge it in to master? Some docs with examples + a blog about it would be awesome too. :) I presume this is something Kevin would do? I'll work with Kevin on this :-) You have write access to blog.infinispan.org, right? Do you think we should give Kevin write access as well? Should be fine, I can just post stuff from my access for now. ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
[infinispan-dev] For Eclipse users: setup the annotation processors
Yesterday during one of the changes I made about dependencies I removed the committed eclipse project file which setup the annotation processors for Eclipse, mainly because it was not valid anymore with the current dependencies. Fred Bricon from the JBoss Tools team is working on https://issues.jboss.org/browse/JBIDE-8208, I've tested his work yesterday on both Infinispan and Hibernate projects: it's awesome, and the project will not need anything more than a standard maven project import to be setup properly. The integration is very nice, for example if you now make a mistake in the logger annotations (like a duplicate logging ID) Eclipse will immediately highlight it as compile error - again without needing to configure anything in the IDE; as soon as [LOGTOOL-20] will be included in the next version of the annotation processor we'll even get errors of mismatching parameters with the message placeholders as %s. There's one side note: this update of the plugin was not released yet, so please be patient and for the time being configure the annotation processors manually and avoid committing that in the project as it will conflict with the plugin work. The main difficulty in configuring the APs is gone (duplicate conflicting classes on classpath), so you only have to tick the annotation processors checkbox to enabled, if it's not already. Cheers, Sanne ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] For Eclipse users: setup the annotation processors
On 14 Jul 2011, at 12:34, Sanne Grinovero wrote: Yesterday during one of the changes I made about dependencies I removed the committed eclipse project file which setup the annotation processors for Eclipse, mainly because it was not valid anymore with the current dependencies. Haha, I only added that about last week. It shows how poor the current approach for eclipse is :-( Please make sure you add a note to the contribution guide to state how to set up annotation processing without this file present. You can find the current instructions in chapter 1. Fred Bricon from the JBoss Tools team is working on https://issues.jboss.org/browse/JBIDE-8208, I've tested his work yesterday on both Infinispan and Hibernate projects: it's awesome, and the project will not need anything more than a standard maven project import to be setup properly. This is a much better approach. The integration is very nice, for example if you now make a mistake in the logger annotations (like a duplicate logging ID) Eclipse will immediately highlight it as compile error - again without needing to configure anything in the IDE; as soon as [LOGTOOL-20] will be included in the next version of the annotation processor we'll even get errors of mismatching parameters with the message placeholders as %s. There's one side note: this update of the plugin was not released yet, so please be patient and for the time being configure the annotation processors manually and avoid committing that in the project as it will conflict with the plugin work. The main difficulty in configuring the APs is gone (duplicate conflicting classes on classpath), so you only have to tick the annotation processors checkbox to enabled, if it's not already. Cheers, Sanne ___ 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] IllegalStateException when receiving invalidation messages on a stopped/stopping cache
Hello, I was looking into the many stacktraces being thrown from the testsuite, this one caught my attention (see below). Can't we just discard such errors? if the cache is stopping, or stopped already, we shouldn't really care for invalidations - especially stacktraces and exceptions being returned to the caller. This doesn't solve all the EOF exceptions I'm still experiencing, but it seems to make things a bit better.. I've hacked a solution which implies adding a method: boolean ignoreCommandOnStatus(ComponentStatus status); to the VisitableCommand interface, seems to work fine. Shall I open a JIRA and send a pull request? Details: https://github.com/Sanne/infinispan/commit/ed962ed72bc68765078b6a0f172b95ea1c07d485#L7L142 Cheers, Sanne 2011-07-14 15:16:20,940 ERROR [RebalanceTask] (Rehasher,Infinispan-Cluster,NonStringKeyStateTransferTest-NodeC-7649) ISPN000145: Error during rehash java.lang.IllegalStateException: Default cache is in 'STOPPING' state and this is an invocation not belonging to an on-going transaction, so it does not accept new invocations. Either restart it or recreate the cache container. at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:83) at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:64) at org.infinispan.commands.AbstractVisitor.visitInvalidateCommand(AbstractVisitor.java:120) at org.infinispan.commands.AbstractVisitor.visitInvalidateL1Command(AbstractVisitor.java:124) at org.infinispan.commands.write.InvalidateL1Command.acceptVisitor(InvalidateL1Command.java:177) at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:274) at org.infinispan.distribution.RebalanceTask.invalidateKeys(RebalanceTask.java:172) at org.infinispan.distribution.RebalanceTask.performRehash(RebalanceTask.java:145) at org.infinispan.distribution.RehashTask.call(RehashTask.java:67) at org.infinispan.distribution.RehashTask.call(RehashTask.java:44) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] IllegalStateException when receiving invalidation messages on a stopped/stopping cache
Patch looks good. Go ahead and issue a pull req. On 14 Jul 2011, at 16:26, Sanne Grinovero wrote: Hello, I was looking into the many stacktraces being thrown from the testsuite, this one caught my attention (see below). Can't we just discard such errors? if the cache is stopping, or stopped already, we shouldn't really care for invalidations - especially stacktraces and exceptions being returned to the caller. This doesn't solve all the EOF exceptions I'm still experiencing, but it seems to make things a bit better.. I've hacked a solution which implies adding a method: boolean ignoreCommandOnStatus(ComponentStatus status); to the VisitableCommand interface, seems to work fine. Shall I open a JIRA and send a pull request? Details: https://github.com/Sanne/infinispan/commit/ed962ed72bc68765078b6a0f172b95ea1c07d485#L7L142 Cheers, Sanne 2011-07-14 15:16:20,940 ERROR [RebalanceTask] (Rehasher,Infinispan-Cluster,NonStringKeyStateTransferTest-NodeC-7649) ISPN000145: Error during rehash java.lang.IllegalStateException: Default cache is in 'STOPPING' state and this is an invocation not belonging to an on-going transaction, so it does not accept new invocations. Either restart it or recreate the cache container. at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:83) at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:64) at org.infinispan.commands.AbstractVisitor.visitInvalidateCommand(AbstractVisitor.java:120) at org.infinispan.commands.AbstractVisitor.visitInvalidateL1Command(AbstractVisitor.java:124) at org.infinispan.commands.write.InvalidateL1Command.acceptVisitor(InvalidateL1Command.java:177) at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:274) at org.infinispan.distribution.RebalanceTask.invalidateKeys(RebalanceTask.java:172) at org.infinispan.distribution.RebalanceTask.performRehash(RebalanceTask.java:145) at org.infinispan.distribution.RehashTask.call(RehashTask.java:67) at org.infinispan.distribution.RehashTask.call(RehashTask.java:44) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) ___ 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] IllegalStateException when receiving invalidation messages on a stopped/stopping cache
TBH I'm not sure why the patch helped with the error messages in the log, I always thought that doing this would just replace the IllegalStateException with an InterruptedException (since do some more stuff after invalidation). Of course the best solution would be to not do rehashing at all when we know we're going to stop the entire cluster anyway (https://issues.jboss.org/browse/ISPN-1239). Dan On Thu, Jul 14, 2011 at 7:48 PM, Manik Surtani ma...@jboss.org wrote: Patch looks good. Go ahead and issue a pull req. On 14 Jul 2011, at 16:26, Sanne Grinovero wrote: Hello, I was looking into the many stacktraces being thrown from the testsuite, this one caught my attention (see below). Can't we just discard such errors? if the cache is stopping, or stopped already, we shouldn't really care for invalidations - especially stacktraces and exceptions being returned to the caller. This doesn't solve all the EOF exceptions I'm still experiencing, but it seems to make things a bit better.. I've hacked a solution which implies adding a method: boolean ignoreCommandOnStatus(ComponentStatus status); to the VisitableCommand interface, seems to work fine. Shall I open a JIRA and send a pull request? Details: https://github.com/Sanne/infinispan/commit/ed962ed72bc68765078b6a0f172b95ea1c07d485#L7L142 Cheers, Sanne 2011-07-14 15:16:20,940 ERROR [RebalanceTask] (Rehasher,Infinispan-Cluster,NonStringKeyStateTransferTest-NodeC-7649) ISPN000145: Error during rehash java.lang.IllegalStateException: Default cache is in 'STOPPING' state and this is an invocation not belonging to an on-going transaction, so it does not accept new invocations. Either restart it or recreate the cache container. at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:83) at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:64) at org.infinispan.commands.AbstractVisitor.visitInvalidateCommand(AbstractVisitor.java:120) at org.infinispan.commands.AbstractVisitor.visitInvalidateL1Command(AbstractVisitor.java:124) at org.infinispan.commands.write.InvalidateL1Command.acceptVisitor(InvalidateL1Command.java:177) at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:274) at org.infinispan.distribution.RebalanceTask.invalidateKeys(RebalanceTask.java:172) at org.infinispan.distribution.RebalanceTask.performRehash(RebalanceTask.java:145) at org.infinispan.distribution.RehashTask.call(RehashTask.java:67) at org.infinispan.distribution.RehashTask.call(RehashTask.java:44) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) ___ 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
