May 2014 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-4265) Make it possible to deploy c3p0 in OSGi

by Ion Savin (JIRA)

Ion Savin created ISPN-4265: ------------------------------- Summary: Make it possible to deploy c3p0 in OSGi Key: ISPN-4265 URL: https://issues.jboss.org/browse/ISPN-4265 Project: Infinispan Issue Type: Feature Request Reporter: Ion Savin Assignee: Ion Savin -- This message was sent by Atlassian JIRA (v6.2.3#6260)

9 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4263) Add all Java tests to C++ testsuite

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-4263?page=com.atlassian.jira.plugin.... ] Radim Vansa closed ISPN-4263. ----------------------------- Resolution: Rejected Wrong project, sorry... > Add all Java tests to C++ testsuite > ----------------------------------- > > Key: ISPN-4263 > URL: https://issues.jboss.org/browse/ISPN-4263 > Project: Infinispan > Issue Type: Enhancement > Reporter: Radim Vansa > Assignee: Radim Vansa > > Some tests are excluded from the testsuite. Add all Java tests or comment why this test is not included. Also, comment on the expected test failures. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

9 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4263) Add all Java tests to C++ testsuite

by Radim Vansa (JIRA)

Radim Vansa created ISPN-4263: --------------------------------- Summary: Add all Java tests to C++ testsuite Key: ISPN-4263 URL: https://issues.jboss.org/browse/ISPN-4263 Project: Infinispan Issue Type: Enhancement Reporter: Radim Vansa Assignee: Radim Vansa Some tests are excluded from the testsuite. Add all Java tests or comment why this test is not included. Also, comment on the expected test failures. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

9 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4264) Server CLI should be able to manipulate role mapping

by Tristan Tarrant (JIRA)

Tristan Tarrant created ISPN-4264: ------------------------------------- Summary: Server CLI should be able to manipulate role mapping Key: ISPN-4264 URL: https://issues.jboss.org/browse/ISPN-4264 Project: Infinispan Issue Type: Sub-task Reporter: Tristan Tarrant Assignee: Tristan Tarrant The server CLI should have "allow" and "deny" commands to be able to grant permissions to principals -- This message was sent by Atlassian JIRA (v6.2.3#6260)

9 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4059) Authorization for code execution (DistExec & Map/Reduce)

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4059?page=com.atlassian.jira.plugin.... ] Tristan Tarrant resolved ISPN-4059. ----------------------------------- Fix Version/s: 7.0.0.Alpha3 Resolution: Done This was resolved by ISPN-3931 > Authorization for code execution (DistExec & Map/Reduce) > -------------------------------------------------------- > > Key: ISPN-4059 > URL: https://issues.jboss.org/browse/ISPN-4059 > Project: Infinispan > Issue Type: Sub-task > Components: Security > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 7.0.0.Final, 7.0.0.Alpha3 > > -- This message was sent by Atlassian JIRA (v6.2.3#6260)

9 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4241) Distexec cannot clone tasks for distributed executions in Karaf

by Martin Gencur (JIRA)

[ https://issues.jboss.org/browse/ISPN-4241?page=com.atlassian.jira.plugin.... ] Martin Gencur updated ISPN-4241: -------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 7.0.0.Alpha4 Resolution: Done > Distexec cannot clone tasks for distributed executions in Karaf > --------------------------------------------------------------- > > Key: ISPN-4241 > URL: https://issues.jboss.org/browse/ISPN-4241 > Project: Infinispan > Issue Type: Bug > Components: Distributed Execution and Map/Reduce > Reporter: Martin Gencur > Assignee: Ion Savin > Fix For: 7.0.0.Alpha4 > > > DistExec uses JBoss Marshalling to clone a task when running in clustered mode but it is not able to load the task class. I don't think this is a problem of classpath in PAX EXAM (as the log below might signify) because DistribuedExecutorService.submit works while DistribuedExecutorService.submitEverywhere fails to load the task class. > I'll provide the test later. > Stacktrace: > {code} > java.lang.ClassNotFoundException: org.infinispan.it.osgi.distexec.LocalDistributedExecutorTest$ExceptionThrowingCallable not found by org.ops4j.pax.exam.rbc [77] > at org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1460) > at org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:72) > at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1843) > at java.lang.ClassLoader.loadClass(ClassLoader.java:356) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:266) > at org.jboss.marshalling.AbstractClassResolver.loadClass(AbstractClassResolver.java:131) > at org.jboss.marshalling.AbstractClassResolver.resolveClass(AbstractClassResolver.java:112) > at org.jboss.marshalling.river.RiverUnmarshaller.doReadClassDescriptor(RiverUnmarshaller.java:943) > at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1239) > at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:272) > at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209) > at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:41) > at org.infinispan.commons.marshall.jboss.AbstractJBossMarshaller.objectFromObjectStream(AbstractJBossMarshaller.java:135) > at org.infinispan.marshall.core.VersionAwareMarshaller.objectFromByteBuffer(VersionAwareMarshaller.java:101) > at org.infinispan.commons.marshall.AbstractMarshaller.objectFromByteBuffer(AbstractMarshaller.java:82) > at org.infinispan.commons.marshall.AbstractDelegatingMarshaller.objectFromByteBuffer(AbstractDelegatingMarshaller.java:75) > at org.infinispan.commons.util.Util.cloneWithMarshaller(Util.java:240) > at org.infinispan.distexec.DefaultExecutorService.clone(DefaultExecutorService.java:507) > at org.infinispan.distexec.DefaultExecutorService.submitEverywhere(DefaultExecutorService.java:462) > at org.infinispan.distexec.DefaultExecutorService.submitEverywhere(DefaultExecutorService.java:449) > at org.infinispan.it.osgi.distexec.LocalDistributedExecutorTest.testExceptionInvocation(LocalDistributedExecutorTest.java:119) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) > at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) > at org.ops4j.pax.exam.invoker.junit.internal.ContainerTestRunner.runChild(ContainerTestRunner.java:67) > at org.ops4j.pax.exam.invoker.junit.internal.ContainerTestRunner.runChild(ContainerTestRunner.java:37) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) > at org.junit.runners.ParentRunner.run(ParentRunner.java:309) > at org.junit.runner.JUnitCore.run(JUnitCore.java:160) > at org.junit.runner.JUnitCore.run(JUnitCore.java:138) > at org.ops4j.pax.exam.invoker.junit.internal.JUnitProbeInvoker.invokeViaJUnit(JUnitProbeInvoker.java:125) > at org.ops4j.pax.exam.invoker.junit.internal.JUnitProbeInvoker.findAndInvoke(JUnitProbeInvoker.java:98) > at org.ops4j.pax.exam.invoker.junit.internal.JUnitProbeInvoker.call(JUnitProbeInvoker.java:74) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.ops4j.pax.exam.rbc.internal.RemoteBundleContextImpl.remoteCall(RemoteBundleContextImpl.java:80) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:322) > at sun.rmi.transport.Transport$1.run(Transport.java:177) > at sun.rmi.transport.Transport$1.run(Transport.java:174) > at java.security.AccessController.doPrivileged(Native Method) > at sun.rmi.transport.Transport.serviceCall(Transport.java:173) > at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:553) > at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:808) > at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:667) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:722) > {code} -- This message was sent by Atlassian JIRA (v6.2.3#6260)

9 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4099) Local Listeners can raise entry events on rehash

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-4099?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-4099: -------------------------------- Summary: Local Listeners can raise entry events on rehash (was: Cluster Listeners raise entry events on rehash) Description: -Cluster Listeners currently raise all create, modify and remove events. When a rehash event occurs this would cause a create event to be generated even though it wasn't just added to the cache. We need to not raise an event in this case.- Writing up tests for this, cluster listeners are unaffected as they use the primaryOnly value for the listener. Further testing shows that this only affects local listeners when they become a backup owner from not being an owner. was:Cluster Listeners currently raise all create, modify and remove events. When a rehash event occurs this would cause a create event to be generated even though it wasn't just added to the cache. We need to not raise an event in this case. > Local Listeners can raise entry events on rehash > ------------------------------------------------ > > Key: ISPN-4099 > URL: https://issues.jboss.org/browse/ISPN-4099 > Project: Infinispan > Issue Type: Bug > Components: Listeners > Affects Versions: 7.0.0.Alpha1 > Reporter: William Burns > Assignee: William Burns > Fix For: 7.0.0.Final > > > -Cluster Listeners currently raise all create, modify and remove events. When a rehash event occurs this would cause a create event to be generated even though it wasn't just added to the cache. We need to not raise an event in this case.- > Writing up tests for this, cluster listeners are unaffected as they use the primaryOnly value for the listener. Further testing shows that this only affects local listeners when they become a backup owner from not being an owner. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

9 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3838) L1 entry added by ST when already invalidated

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3838?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3838: -------------------------------- Fix Version/s: 7.0.0.Alpha4 7.0.0.Final > L1 entry added by ST when already invalidated > --------------------------------------------- > > Key: ISPN-3838 > URL: https://issues.jboss.org/browse/ISPN-3838 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 6.0.0.Final > Reporter: Radim Vansa > Assignee: William Burns > Priority: Critical > Labels: 620 > Fix For: 7.0.0.Alpha4, 7.0.0.Final > > > Non-transactional cache with L1 enabled. Node A is losing ownership of an entry, the entry is not removed during ST but is going to L1. > 1. ST builds the invalidation command, EntryWrapping interceptor starts committing all the entries > 2. Write on primary owner (B) occurs > 3. A gets the InvalidateL1Command, removes the ImmortalCacheEntry from data container (as it does not own the entry anymore) > 4. The ST invalidation command commits the MortalCacheEntry with old value, storing it into the data container. > Result: Outdated value is in L1 cache. > As the entry is not locked during the ST, it can be committed as MortalCacheEntry only if it was not changed (removed and possibly then cached again with different value). > (I understand that this wouldn't be easy to implement as the check is not to be executed in perform, but during the actual commit - and atomically in the container.) -- This message was sent by Atlassian JIRA (v6.2.3#6260)

9 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3838) L1 entry added by ST when already invalidated

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3838?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3838: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > L1 entry added by ST when already invalidated > --------------------------------------------- > > Key: ISPN-3838 > URL: https://issues.jboss.org/browse/ISPN-3838 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 6.0.0.Final > Reporter: Radim Vansa > Assignee: William Burns > Priority: Critical > Labels: 620 > > Non-transactional cache with L1 enabled. Node A is losing ownership of an entry, the entry is not removed during ST but is going to L1. > 1. ST builds the invalidation command, EntryWrapping interceptor starts committing all the entries > 2. Write on primary owner (B) occurs > 3. A gets the InvalidateL1Command, removes the ImmortalCacheEntry from data container (as it does not own the entry anymore) > 4. The ST invalidation command commits the MortalCacheEntry with old value, storing it into the data container. > Result: Outdated value is in L1 cache. > As the entry is not locked during the ST, it can be committed as MortalCacheEntry only if it was not changed (removed and possibly then cached again with different value). > (I understand that this wouldn't be easy to implement as the check is not to be executed in perform, but during the actual commit - and atomically in the container.) -- This message was sent by Atlassian JIRA (v6.2.3#6260)

9 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4227) OSGi - import packages - don't hardcode version ranges

by Ion Savin (JIRA)

[ https://issues.jboss.org/browse/ISPN-4227?page=com.atlassian.jira.plugin.... ] Ion Savin updated ISPN-4227: ---------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/2540 > OSGi - import packages - don't hardcode version ranges > ------------------------------------------------------ > > Key: ISPN-4227 > URL: https://issues.jboss.org/browse/ISPN-4227 > Project: Infinispan > Issue Type: Sub-task > Components: Core > Reporter: Ion Savin > Assignee: Ion Savin > > Version ranges in Import-Package declarations are hardcoded. Should specify them relative to the maven versions to avoid duplication / ease maintenance. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

9 years, 12 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues May 2014