August 2014 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-4421) Migration from jboss-as to wildfly arquillian-container-managed broke RollingUpgrades tests

by Tomas Sykora (JIRA)

[ https://issues.jboss.org/browse/ISPN-4421?page=com.atlassian.jira.plugin.... ] Tomas Sykora edited comment on ISPN-4421 at 8/26/14 5:42 AM: ------------------------------------------------------------- We need this one in order to be able properly recognize container adapter class on a class path. (using droidium multicontainer extension) Added link to: https://issues.jboss.org/browse/WFLY-3756 was (Author: tsykora): We need this one in order to be able properly recognize container adapter class on a class path. (using droidium multicontainer extension) > Migration from jboss-as to wildfly arquillian-container-managed broke RollingUpgrades tests > ------------------------------------------------------------------------------------------- > > Key: ISPN-4421 > URL: https://issues.jboss.org/browse/ISPN-4421 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Test Suite - Server > Affects Versions: 7.0.0.Alpha4 > Reporter: Tomas Sykora > Assignee: Mircea Markus > Labels: test_suite, testsuite_stability > > Server was rebased to Wildfly. > For Arquillian, jboss-as-arquillian-container-managed was changed to wildfly-arquillian-container-managed in order to reflect respective changes. > The problem for Rolling Upgrade tests ( -Psuite.rolling.upgrades ) is that there are used also old server instances in those tests. > Due to new changes in infinispan-arquillian-container old Infinispan servers are not properly managed during their startup phase. > Observation: > Switching port to 10099 (wildfly is using 10090 for mgmt ops) does not help. Strange message is continuously showing until timeout: > 13:41:57,691 ERROR [org.jboss.remoting.remote.connection] (Remoting "node1:MANAGEMENT" read-1) JBREM000200: Remote connection failed: java.io.IOException: Received an invalid message length of 1195725856 > "Experiment" with setting up <property name="managementProtocol">remoting-jmx</property> for OLD server in arquillian.xml didn't help either, however, ERROR message ^ disappeared. > But the server can't start properly, better to say, it starts, but Arquillian is not able to handle it properly and communicate: > testHotRodRollingUpgradesDiffVersions(org.infinispan.server.test.rollingupgrades.HotRodRollingUpgradesIT) Time elapsed: 60.389 sec <<< ERROR! > org.jboss.arquillian.container.spi.client.container.LifecycleException: Could not start container > at org.jboss.as.arquillian.container.managed.ManagedDeployableContainer.startInternal(ManagedDeployableContainer.java:204) > at org.jboss.as.arquillian.container.CommonDeployableContainer.start(CommonDeployableContainer.java:112) > at org.jboss.arquillian.container.impl.ContainerImpl.start(ContainerImpl.java:199) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:163) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:157) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forContainer(ContainerLifecycleController.java:255) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startContainer(ContainerLifecycleController.java:156) > 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.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57) > 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.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.test.impl.client.container.ClientContainerController.start(ClientContainerController.java:93) > at org.infinispan.server.test.rollingupgrades.HotRodRollingUpgradesIT.testHotRodRollingUpgradesDiffVersions(HotRodRollingUpgradesIT.java:68) > It looks like we need to somehow create a "bridge" or "switch" which will allow operations for both old and new servers in one test. > Or maybe I'm missing something important. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4421) Migration from jboss-as to wildfly arquillian-container-managed broke RollingUpgrades tests

by Tomas Sykora (JIRA)

[ https://issues.jboss.org/browse/ISPN-4421?page=com.atlassian.jira.plugin.... ] Tomas Sykora commented on ISPN-4421: ------------------------------------ We need this one in order to be able properly recognize container adapter class on a class path. (using droidium multicontainer extension) > Migration from jboss-as to wildfly arquillian-container-managed broke RollingUpgrades tests > ------------------------------------------------------------------------------------------- > > Key: ISPN-4421 > URL: https://issues.jboss.org/browse/ISPN-4421 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Test Suite - Server > Affects Versions: 7.0.0.Alpha4 > Reporter: Tomas Sykora > Assignee: Mircea Markus > Labels: test_suite, testsuite_stability > > Server was rebased to Wildfly. > For Arquillian, jboss-as-arquillian-container-managed was changed to wildfly-arquillian-container-managed in order to reflect respective changes. > The problem for Rolling Upgrade tests ( -Psuite.rolling.upgrades ) is that there are used also old server instances in those tests. > Due to new changes in infinispan-arquillian-container old Infinispan servers are not properly managed during their startup phase. > Observation: > Switching port to 10099 (wildfly is using 10090 for mgmt ops) does not help. Strange message is continuously showing until timeout: > 13:41:57,691 ERROR [org.jboss.remoting.remote.connection] (Remoting "node1:MANAGEMENT" read-1) JBREM000200: Remote connection failed: java.io.IOException: Received an invalid message length of 1195725856 > "Experiment" with setting up <property name="managementProtocol">remoting-jmx</property> for OLD server in arquillian.xml didn't help either, however, ERROR message ^ disappeared. > But the server can't start properly, better to say, it starts, but Arquillian is not able to handle it properly and communicate: > testHotRodRollingUpgradesDiffVersions(org.infinispan.server.test.rollingupgrades.HotRodRollingUpgradesIT) Time elapsed: 60.389 sec <<< ERROR! > org.jboss.arquillian.container.spi.client.container.LifecycleException: Could not start container > at org.jboss.as.arquillian.container.managed.ManagedDeployableContainer.startInternal(ManagedDeployableContainer.java:204) > at org.jboss.as.arquillian.container.CommonDeployableContainer.start(CommonDeployableContainer.java:112) > at org.jboss.arquillian.container.impl.ContainerImpl.start(ContainerImpl.java:199) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:163) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:157) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forContainer(ContainerLifecycleController.java:255) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startContainer(ContainerLifecycleController.java:156) > 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.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57) > 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.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.test.impl.client.container.ClientContainerController.start(ClientContainerController.java:93) > at org.infinispan.server.test.rollingupgrades.HotRodRollingUpgradesIT.testHotRodRollingUpgradesDiffVersions(HotRodRollingUpgradesIT.java:68) > It looks like we need to somehow create a "bridge" or "switch" which will allow operations for both old and new servers in one test. > Or maybe I'm missing something important. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4559) Replace fails with cache loader

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4559?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4559: ----------------------------------------------- Alan Field <afield(a)redhat.com> changed the Status of [bug 1122269|https://bugzilla.redhat.com/show_bug.cgi?id=1122269] from ON_QA to VERIFIED > Replace fails with cache loader > ------------------------------- > > Key: ISPN-4559 > URL: https://issues.jboss.org/browse/ISPN-4559 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Loaders and Stores > Affects Versions: 7.0.0.Alpha5 > Reporter: Dennis Reed > Assignee: Pedro Ruivo > Priority: Critical > Fix For: 7.0.0.Beta2 > > > cache.replace(key, oldValue, newValue) compares the current value in the cache to oldValue, and if they differ it turns into a no-op. > However, CacheLoaderInterceptor does not load entries for a ReplaceCommand. > If the entry only exists in the loader and not in memory, this causes the replace to fail. > CacheLoaderInterceptor must always load the value for a ReplaceCommand. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4648) Log rebalancing messages to specific category

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4648?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4648: ----------------------------------------------- Martin Gencur <mgencur(a)redhat.com> changed the Status of [bug 1131117|https://bugzilla.redhat.com/show_bug.cgi?id=1131117] from ON_QA to VERIFIED > Log rebalancing messages to specific category > --------------------------------------------- > > Key: ISPN-4648 > URL: https://issues.jboss.org/browse/ISPN-4648 > Project: Infinispan > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Core > Affects Versions: 7.0.0.Beta1 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 7.0.0.Beta2, 7.0.0.Final > > > For ease of management, logging of major rebalancing events should be sent to an appropriate category. > Use org.infinispan.CLUSTER and level INFO -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3229) L1 cache entries should not be passivated

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3229?page=com.atlassian.jira.plugin.... ] Work on ISPN-3229 started by William Burns. ------------------------------------------- > L1 cache entries should not be passivated > ----------------------------------------- > > Key: ISPN-3229 > URL: https://issues.jboss.org/browse/ISPN-3229 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: L1 > Affects Versions: 5.2.6.Final > Reporter: William Burns > Assignee: William Burns > Fix For: 7.0.0.Beta2 > > Attachments: DistSyncL1PassivationFuncTest.java > > > L1 entries are stored in the same data container as the real entries. These can be evicted which is fine, however we don't want them to be passivated as this could be costly to write/read from the cache store. We should either prevent L1 cache entries from being passivated or have an option to allow for it. > Currently L1 entries are not differentiated from other entries except through the fact that they are mortal, which is used for other operations as well, which means they would need a placeholder of some kind to tell the container this is a L1 entry. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4179) Add Filters that utilize indexless querying

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-4179?page=com.atlassian.jira.plugin.... ] William Burns resolved ISPN-4179. --------------------------------- Resolution: Duplicate Issue Adrian had completed this with ISPN-3917 > Add Filters that utilize indexless querying > ------------------------------------------- > > Key: ISPN-4179 > URL: https://issues.jboss.org/browse/ISPN-4179 > Project: Infinispan > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Listeners > Reporter: William Burns > Assignee: William Burns > Fix For: 7.0.0.Final > > > We will need to add in a KeyValueFilter implementation on top of -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-871) Out-of-heap data container implementation

by Ben Cotton (JIRA)

[ https://issues.jboss.org/browse/ISPN-871?page=com.atlassian.jira.plugin.s... ] Ben Cotton commented on ISPN-871: --------------------------------- Hi, Please be advised that on Sep 18/19 all of Ben Cotton, Peter Lawrey and Dmitry Gordeev will be meeting in NYC to specifically discuss the plan to progress development on https://github.com/Cotton-Ben/infinispan ... we will then pass our findings onto Mircea Markus and Adrian Nistor re: next best steps. Please forgive our lack of progress on this JIRA ... we are not RedHat employees and are 100% donating our time as commuinity contributors. That said we are exceedingly excited wmance Opent to adopting the OpenHFT high-performance off-heap capability as an ISPN Cache. Thanks. > Out-of-heap data container implementation > ----------------------------------------- > > Key: ISPN-871 > URL: https://issues.jboss.org/browse/ISPN-871 > Project: Infinispan > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Configuration > Reporter: Manik Surtani > Assignee: Tristan Tarrant > Labels: gc, jni, native, performance, research > > The {{DataContainer}} interface could be implemented using a off-heap impl in C, using a wrapper around [TBB|http://threadingbuildingblocks.org/]'s concurrent hashmap. > Cheap and easy way, no memory management needed, at worst case same performance as the Java CHM-like impl of the data container + some JNI overhead. Potential benefit of large data heaps. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-871) Out-of-heap data container implementation

by Rajeev Rana (JIRA)

[ https://issues.jboss.org/browse/ISPN-871?page=com.atlassian.jira.plugin.s... ] Rajeev Rana commented on ISPN-871: ---------------------------------- Any plan for this one on the roadmap please ? > Out-of-heap data container implementation > ----------------------------------------- > > Key: ISPN-871 > URL: https://issues.jboss.org/browse/ISPN-871 > Project: Infinispan > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Configuration > Reporter: Manik Surtani > Assignee: Tristan Tarrant > Labels: gc, jni, native, performance, research > > The {{DataContainer}} interface could be implemented using a off-heap impl in C, using a wrapper around [TBB|http://threadingbuildingblocks.org/]'s concurrent hashmap. > Cheap and easy way, no memory management needed, at worst case same performance as the Java CHM-like impl of the data container + some JNI overhead. Potential benefit of large data heaps. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4645) Many XSD default values do not match the defaults from the corresponding configuration builder

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4645?page=com.atlassian.jira.plugin.... ] Tristan Tarrant reassigned ISPN-4645: ------------------------------------- Assignee: Tristan Tarrant (was: Dan Berindei) > Many XSD default values do not match the defaults from the corresponding configuration builder > ---------------------------------------------------------------------------------------------- > > Key: ISPN-4645 > URL: https://issues.jboss.org/browse/ISPN-4645 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Configuration > Affects Versions: 7.0.0.Beta1 > Reporter: Paul Ferraro > Assignee: Tristan Tarrant > > Some examples from the 7.0 xsd: > https://github.com/infinispan/infinispan/blob/7.0.0.Beta1/core/src/main/r... > vs > https://github.com/infinispan/infinispan/blob/7.0.0.Beta1/core/src/main/j... > https://github.com/infinispan/infinispan/blob/7.0.0.Beta1/core/src/main/r... > vs > https://github.com/infinispan/infinispan/blob/7.0.0.Beta1/core/src/main/j... > https://github.com/infinispan/infinispan/blob/7.0.0.Beta1/core/src/main/r... > vs > https://github.com/infinispan/infinispan/blob/7.0.0.Beta1/core/src/main/j... > https://github.com/infinispan/infinispan/blob/7.0.0.Beta1/core/src/main/r... > vs > https://github.com/infinispan/infinispan/blob/7.0.0.Beta1/core/src/main/j... > There are several others. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4665) Define "smoke" test group for Infinispan test suite

by Martin Gencur (JIRA)

Martin Gencur created ISPN-4665: ----------------------------------- Summary: Define "smoke" test group for Infinispan test suite Key: ISPN-4665 URL: https://issues.jboss.org/browse/ISPN-4665 Project: Infinispan Issue Type: Task Security Level: Public (Everyone can see) Components: Test Suite - Core, Test Suite - Server Reporter: Martin Gencur Assignee: Martin Gencur The goal is to define a new TestNG group called "smoke" and add some tests into this group. Let's go over Infinispan test suite and choose tests that verify basic functionality of each (or most of) feature but they don't have to test it in depth. Running tests in "smoke" group should take just a few minutes. We don't need thousands of tests here. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 7 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues August 2014