[JBoss JIRA] (ISPN-4515) Create repository for lucene wildfly modules
by Gustavo Fernandes (JIRA)
Gustavo Fernandes created ISPN-4515:
---------------------------------------
Summary: Create repository for lucene wildfly modules
Key: ISPN-4515
URL: https://issues.jboss.org/browse/ISPN-4515
Project: Infinispan
Issue Type: Task
Security Level: Public (Everyone can see)
Components: Lucene Directory
Affects Versions: 7.0.0.Alpha4
Reporter: Gustavo Fernandes
Assignee: Gustavo Fernandes
In order to standardize the Lucene directory modules for Wildfly usage across projects, so that a single "slot" is used, and to be able to evolve it independently from Infinispan releases, we need to create a new repository & Maven project
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 6 months
[JBoss JIRA] (ISPN-4514) Investigate possible memory issue with query modules
by William Burns (JIRA)
William Burns created ISPN-4514:
-----------------------------------
Summary: Investigate possible memory issue with query modules
Key: ISPN-4514
URL: https://issues.jboss.org/browse/ISPN-4514
Project: Infinispan
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Test Suite - Query
Affects Versions: 7.0.0.Alpha4
Reporter: William Burns
Assignee: William Burns
There have been reported memory issues in the query module which are possible "memory leaks", we should verify those and fix if needed.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 6 months
[JBoss JIRA] (ISPN-4504) Topology id is not properly set on ClusteredGetCommands
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-4504?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-4504:
------------------------------------
I got some failures in {{StateTransferLargeObjectTest}} because {{ClusteredGetCommand.canBlock()}} was returning {{false}}, but it was blocking the OOB thread to wait for a new topology.
That was easy to fix, but it made me wonder if we really need {{ClusteredGetCommand}}s to block. So I changed it to no longer implement {{TopologyAwareCommand}} and I re-enabled scenarios 5 and 7, and everything seems to work fine.
> Topology id is not properly set on ClusteredGetCommands
> -------------------------------------------------------
>
> Key: ISPN-4504
> URL: https://issues.jboss.org/browse/ISPN-4504
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Core
> Affects Versions: 7.0.0.Alpha4
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 7.0.0.Alpha5
>
>
> Because the topology id is not properly set on ClusteredGetCommands, they don't wait for the sender's topology to be installed on the target.
> I have tried to fix this while implementing a fix for ISPN-4503. My solution caused 2 failures in RemoteGetDuringStateTransferTest, scenarios 5 and 7::
> | sc | currentTopologyId | currentTopologyId + 1 (rebalance) | currentTopologyId + 2 (finish) |
> | 5 | 0:remoteGet | 2:sendReply | 0:receiveReply, 1:sendReply |
> | 7 | | 0:remoteGet, 2: sendReply | 0:receiveReply, 1:sendReply |
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 6 months
[JBoss JIRA] (ISPN-4512) CacheManagerTest.testCacheManagerRestartReusingConfigurations random failures
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-4512?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-4512:
-------------------------------
Attachment: CacheManagerTest_t_ISPN-4154_failing_elasticity_test_20140707.log.gz
> CacheManagerTest.testCacheManagerRestartReusingConfigurations random failures
> -----------------------------------------------------------------------------
>
> Key: ISPN-4512
> URL: https://issues.jboss.org/browse/ISPN-4512
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Core, Test Suite - Core
> Affects Versions: 7.0.0.Alpha4
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Blocker
> Labels: testsuite_stability
> Fix For: 7.0.0.Alpha5
>
> Attachments: CacheManagerTest_t_ISPN-4154_failing_elasticity_test_20140707.log.gz
>
>
> When a new cache manager is started with the same configuration, it uses the JGroupsTransport instance. In some rare cases, the JGroupsTransport keeps using the old marshaller, which doesn't work, and the cache fails to start:
> {noformat}
> 23:54:08,203 TRACE (testng-CacheManagerTest:___defaultcache) [JGroupsTransport] dests=[NodeB-24139], command=CacheTopologyControlCommand{cache=___defaultcache, type=JOIN, sender=NodeA-33664, joinInfo=CacheJoinInfo{consistentHashFactory=org.infinispan.distribution.ch.impl.ReplicatedConsistentHashFactory@b8c8791, hashFunction=MurmurHash3, numSegments=60, numOwners=2, timeout=240000, totalOrder=false, distributed=false}, topologyId=0, currentCH=null, pendingCH=null, throwable=null, viewId=3}, mode=SYNCHRONOUS, timeout=240000
> 23:54:08,207 DEBUG (testng-CacheManagerTest:___defaultcache) [VersionAwareMarshaller] Object is not serializable
> java.io.NotSerializableException: org.infinispan.topology.CacheTopologyControlCommand
> at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:890)
> at org.jboss.marshalling.AbstractObjectOutput.writeObject(AbstractObjectOutput.java:58)
> at org.jboss.marshalling.AbstractMarshaller.writeObject(AbstractMarshaller.java:111)
> at org.infinispan.commons.marshall.jboss.AbstractJBossMarshaller.objectToObjectStream(AbstractJBossMarshaller.java:73)
> at org.infinispan.marshall.core.VersionAwareMarshaller.objectToBuffer(VersionAwareMarshaller.java:77)
> at org.infinispan.commons.marshall.AbstractMarshaller.objectToBuffer(AbstractMarshaller.java:41)
> at org.infinispan.commons.marshall.AbstractDelegatingMarshaller.objectToBuffer(AbstractDelegatingMarshaller.java:85)
> at org.infinispan.remoting.transport.jgroups.MarshallerAdapter.objectToBuffer(MarshallerAdapter.java:23)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.marshallCall(CommandAwareRpcDispatcher.java:335)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.processSingleCall(CommandAwareRpcDispatcher.java:352)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:165)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotely(JGroupsTransport.java:526)
> at org.infinispan.topology.LocalTopologyManagerImpl.executeOnCoordinator(LocalTopologyManagerImpl.java:290)
> at org.infinispan.topology.LocalTopologyManagerImpl.join(LocalTopologyManagerImpl.java:100)
> at org.infinispan.statetransfer.StateTransferManagerImpl.start(StateTransferManagerImpl.java:104)
> {noformat}
> The only test that does this is CacheManagerTest.testCacheManagerRestartReusingConfigurations.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 6 months
[JBoss JIRA] (ISPN-4513) ProgrammaticCacheContainerTest.testSmallCache always fails on JDK8
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-4513?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-4513:
-------------------------------
Attachment: ProgrammaticCacheContainerTest_pr_wburns_ISPN-4435_20140701.log.gz
> ProgrammaticCacheContainerTest.testSmallCache always fails on JDK8
> ------------------------------------------------------------------
>
> Key: ISPN-4513
> URL: https://issues.jboss.org/browse/ISPN-4513
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: CDI Integration
> Affects Versions: 7.0.0.Alpha4
> Reporter: Dan Berindei
> Assignee: William Burns
> Labels: testsuite_stability
> Fix For: 7.0.0.Alpha5
>
> Attachments: ProgrammaticCacheContainerTest_pr_wburns_ISPN-4435_20140701.log.gz
>
>
> CDI listeners are implemented via an adapter class that extends {{AbstractAdapter<T extends Event>}}. For {{CacheStartedEvent}}, the base class defines a {{void fire(T payload)}} method, and the adapter overrides it as {{void fire(CacheStartedEvent payload)}}.
> It appears that in JDK8 both these methods are returned by {{Class.getMethods()}}, and the CDI listener ends up being called twice:
> {noformat}
> 16:42:44,810 ERROR (testng-ProgrammaticCacheContainerTest:) [UnitTestTestNGListener] Test testSmallCache(org.infinispan.cdi.test.cachemanager.embedded.programmatic.ProgrammaticCacheContainerTest) failed.
> java.lang.AssertionError: expected [1] but found [2]
> at org.testng.Assert.fail(Assert.java:94)
> at org.testng.Assert.failNotEquals(Assert.java:494)
> at org.testng.Assert.assertEquals(Assert.java:123)
> at org.testng.Assert.assertEquals(Assert.java:370)
> at org.testng.Assert.assertEquals(Assert.java:380)
> at org.infinispan.cdi.test.cachemanager.embedded.programmatic.ProgrammaticCacheContainerTest.testSmallCache(ProgrammaticCacheContainerTest.java:39)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 6 months
[JBoss JIRA] (ISPN-4513) ProgrammaticCacheContainerTest.testSmallCache always fails on JDK8
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-4513?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-4513:
------------------------------------
http://stas-blogspot.blogspot.ro/2010/03/java-bridge-methods-explained.html
> ProgrammaticCacheContainerTest.testSmallCache always fails on JDK8
> ------------------------------------------------------------------
>
> Key: ISPN-4513
> URL: https://issues.jboss.org/browse/ISPN-4513
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: CDI Integration
> Affects Versions: 7.0.0.Alpha4
> Reporter: Dan Berindei
> Assignee: William Burns
> Labels: testsuite_stability
> Fix For: 7.0.0.Alpha5
>
>
> CDI listeners are implemented via an adapter class that extends {{AbstractAdapter<T extends Event>}}. For {{CacheStartedEvent}}, the base class defines a {{void fire(T payload)}} method, and the adapter overrides it as {{void fire(CacheStartedEvent payload)}}.
> It appears that in JDK8 both these methods are returned by {{Class.getMethods()}}, and the CDI listener ends up being called twice:
> {noformat}
> 16:42:44,810 ERROR (testng-ProgrammaticCacheContainerTest:) [UnitTestTestNGListener] Test testSmallCache(org.infinispan.cdi.test.cachemanager.embedded.programmatic.ProgrammaticCacheContainerTest) failed.
> java.lang.AssertionError: expected [1] but found [2]
> at org.testng.Assert.fail(Assert.java:94)
> at org.testng.Assert.failNotEquals(Assert.java:494)
> at org.testng.Assert.assertEquals(Assert.java:123)
> at org.testng.Assert.assertEquals(Assert.java:370)
> at org.testng.Assert.assertEquals(Assert.java:380)
> at org.infinispan.cdi.test.cachemanager.embedded.programmatic.ProgrammaticCacheContainerTest.testSmallCache(ProgrammaticCacheContainerTest.java:39)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 6 months
[JBoss JIRA] (ISPN-4513) ProgrammaticCacheContainerTest.testSmallCache always fails on JDK8
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-4513?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-4513:
-------------------------------
Priority: Major (was: Blocker)
> ProgrammaticCacheContainerTest.testSmallCache always fails on JDK8
> ------------------------------------------------------------------
>
> Key: ISPN-4513
> URL: https://issues.jboss.org/browse/ISPN-4513
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: CDI Integration
> Affects Versions: 7.0.0.Alpha4
> Reporter: Dan Berindei
> Assignee: William Burns
> Labels: testsuite_stability
> Fix For: 7.0.0.Alpha5
>
>
> CDI listeners are implemented via an adapter class that extends {{AbstractAdapter<T extends Event>}}. For {{CacheStartedEvent}}, the base class defines a {{void fire(T payload)}} method, and the adapter overrides it as {{void fire(CacheStartedEvent payload)}}.
> It appears that in JDK8 both these methods are returned by {{Class.getMethods()}}, and the CDI listener ends up being called twice:
> {noformat}
> 16:42:44,810 ERROR (testng-ProgrammaticCacheContainerTest:) [UnitTestTestNGListener] Test testSmallCache(org.infinispan.cdi.test.cachemanager.embedded.programmatic.ProgrammaticCacheContainerTest) failed.
> java.lang.AssertionError: expected [1] but found [2]
> at org.testng.Assert.fail(Assert.java:94)
> at org.testng.Assert.failNotEquals(Assert.java:494)
> at org.testng.Assert.assertEquals(Assert.java:123)
> at org.testng.Assert.assertEquals(Assert.java:370)
> at org.testng.Assert.assertEquals(Assert.java:380)
> at org.infinispan.cdi.test.cachemanager.embedded.programmatic.ProgrammaticCacheContainerTest.testSmallCache(ProgrammaticCacheContainerTest.java:39)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 6 months
[JBoss JIRA] (ISPN-4513) ProgrammaticCacheContainerTest.testSmallCache always fails on JDK8
by Dan Berindei (JIRA)
Dan Berindei created ISPN-4513:
----------------------------------
Summary: ProgrammaticCacheContainerTest.testSmallCache always fails on JDK8
Key: ISPN-4513
URL: https://issues.jboss.org/browse/ISPN-4513
Project: Infinispan
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: CDI Integration
Affects Versions: 7.0.0.Alpha4
Reporter: Dan Berindei
Assignee: William Burns
Priority: Blocker
Fix For: 7.0.0.Alpha5
CDI listeners are implemented via an adapter class that extends {{AbstractAdapter<T extends Event>}}. For {{CacheStartedEvent}}, the base class defines a {{void fire(T payload)}} method, and the adapter overrides it as {{void fire(CacheStartedEvent payload)}}.
It appears that in JDK8 both these methods are returned by {{Class.getMethods()}}, and the CDI listener ends up being called twice:
{noformat}
16:42:44,810 ERROR (testng-ProgrammaticCacheContainerTest:) [UnitTestTestNGListener] Test testSmallCache(org.infinispan.cdi.test.cachemanager.embedded.programmatic.ProgrammaticCacheContainerTest) failed.
java.lang.AssertionError: expected [1] but found [2]
at org.testng.Assert.fail(Assert.java:94)
at org.testng.Assert.failNotEquals(Assert.java:494)
at org.testng.Assert.assertEquals(Assert.java:123)
at org.testng.Assert.assertEquals(Assert.java:370)
at org.testng.Assert.assertEquals(Assert.java:380)
at org.infinispan.cdi.test.cachemanager.embedded.programmatic.ProgrammaticCacheContainerTest.testSmallCache(ProgrammaticCacheContainerTest.java:39)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 6 months
[JBoss JIRA] (ISPN-4163) CacheAuthorizationTest.testAllCombinations always fails on JDK8
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-4163?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-4163:
-------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 7.0.0.Alpha5
(was: 7.0.0.Beta1)
Resolution: Done
> CacheAuthorizationTest.testAllCombinations always fails on JDK8
> ---------------------------------------------------------------
>
> Key: ISPN-4163
> URL: https://issues.jboss.org/browse/ISPN-4163
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Security, Test Suite - Core
> Affects Versions: 7.0.0.Alpha1
> Reporter: Dan Berindei
> Assignee: Tristan Tarrant
> Labels: testsuite_stability
> Fix For: 7.0.0.Alpha5
>
>
> JDK8 added some new default methods to ConcurrentMap, and SecureCacheTestDriver doesn't cover them. This actually raises the question of whether we could provide our own implementations while still keeping compatibility with JDK6...
> {noformat}
> java.lang.Exception: Class org.infinispan.security.SecureCacheTestDriver needs to declare a method with the following signature: void testReplaceAll_BiFunction(SecureCache<String, String> cache) {}
> at org.infinispan.security.CacheAuthorizationTest.testAllCombinations(CacheAuthorizationTest.java:158)
> Caused by: java.lang.NoSuchMethodException: org.infinispan.security.SecureCacheTestDriver.testReplaceAll_BiFunction(org.infinispan.security.SecureCache)
> at java.lang.Class.getMethod(Class.java:1773)
> at org.infinispan.security.CacheAuthorizationTest.testAllCombinations(CacheAuthorizationTest.java:109) ... 20 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 6 months
[JBoss JIRA] (ISPN-4512) CacheManagerTest.testCacheManagerRestartReusingConfigurations random failures
by Dan Berindei (JIRA)
Dan Berindei created ISPN-4512:
----------------------------------
Summary: CacheManagerTest.testCacheManagerRestartReusingConfigurations random failures
Key: ISPN-4512
URL: https://issues.jboss.org/browse/ISPN-4512
Project: Infinispan
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Core, Test Suite - Core
Affects Versions: 7.0.0.Alpha4
Reporter: Dan Berindei
Assignee: Dan Berindei
Priority: Blocker
Fix For: 7.0.0.Alpha5
When a new cache manager is started with the same configuration, it uses the JGroupsTransport instance. In some rare cases, the JGroupsTransport keeps using the old marshaller, which doesn't work, and the cache fails to start:
{noformat}
23:54:08,203 TRACE (testng-CacheManagerTest:___defaultcache) [JGroupsTransport] dests=[NodeB-24139], command=CacheTopologyControlCommand{cache=___defaultcache, type=JOIN, sender=NodeA-33664, joinInfo=CacheJoinInfo{consistentHashFactory=org.infinispan.distribution.ch.impl.ReplicatedConsistentHashFactory@b8c8791, hashFunction=MurmurHash3, numSegments=60, numOwners=2, timeout=240000, totalOrder=false, distributed=false}, topologyId=0, currentCH=null, pendingCH=null, throwable=null, viewId=3}, mode=SYNCHRONOUS, timeout=240000
23:54:08,207 DEBUG (testng-CacheManagerTest:___defaultcache) [VersionAwareMarshaller] Object is not serializable
java.io.NotSerializableException: org.infinispan.topology.CacheTopologyControlCommand
at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:890)
at org.jboss.marshalling.AbstractObjectOutput.writeObject(AbstractObjectOutput.java:58)
at org.jboss.marshalling.AbstractMarshaller.writeObject(AbstractMarshaller.java:111)
at org.infinispan.commons.marshall.jboss.AbstractJBossMarshaller.objectToObjectStream(AbstractJBossMarshaller.java:73)
at org.infinispan.marshall.core.VersionAwareMarshaller.objectToBuffer(VersionAwareMarshaller.java:77)
at org.infinispan.commons.marshall.AbstractMarshaller.objectToBuffer(AbstractMarshaller.java:41)
at org.infinispan.commons.marshall.AbstractDelegatingMarshaller.objectToBuffer(AbstractDelegatingMarshaller.java:85)
at org.infinispan.remoting.transport.jgroups.MarshallerAdapter.objectToBuffer(MarshallerAdapter.java:23)
at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.marshallCall(CommandAwareRpcDispatcher.java:335)
at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.processSingleCall(CommandAwareRpcDispatcher.java:352)
at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:165)
at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotely(JGroupsTransport.java:526)
at org.infinispan.topology.LocalTopologyManagerImpl.executeOnCoordinator(LocalTopologyManagerImpl.java:290)
at org.infinispan.topology.LocalTopologyManagerImpl.join(LocalTopologyManagerImpl.java:100)
at org.infinispan.statetransfer.StateTransferManagerImpl.start(StateTransferManagerImpl.java:104)
{noformat}
The only test that does this is CacheManagerTest.testCacheManagerRestartReusingConfigurations.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 6 months