[JBoss JIRA] (ISPN-4421) Migration from jboss-as to wildfly arquillian-container-managed broke RollingUpgrades tests
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-4421?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-4421:
-----------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 7.0.0.CR1
Resolution: Done
> 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
> Components: Test Suite - Server
> Affects Versions: 7.0.0.Alpha4
> Reporter: Tomas Sykora
> Assignee: Tomas Sykora
> Labels: test_suite, testsuite_stability
> Fix For: 7.0.0.CR1
>
>
> 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)
9 years, 6 months
[JBoss JIRA] (ISPN-4743) Rebalance can hang after the coordinator and another node leave
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-4743?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-4743:
-----------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Rebalance can hang after the coordinator and another node leave
> ---------------------------------------------------------------
>
> Key: ISPN-4743
> URL: https://issues.jboss.org/browse/ISPN-4743
> Project: Infinispan
> Issue Type: Bug
> Components: Core, State Transfer
> Affects Versions: 7.0.0.Beta2
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Critical
> Labels: testsuite_stability
> Fix For: 7.0.0.CR1
>
>
> This caused a failure in {{ClusterTopologyManagerTest.testAbruptLeaveAfterGetStatus}}.
> When the coordinator changes, the new coordinator first sends a {{CacheTopologyControlCommand(type=CH_UPDATE)}} to reset any ongoing rebalance, then a {{CacheTopologyControlCommand(type=REBALANCE_START)}} to start a new rebalance with the remaining members. If another node leaves afterwards, the coordinator sends yet another {{CacheTopologyControlCommand(type=CH_UPDATE)}} to remove the leaver from the CHs.
> If one node (in this case the coordinator itself) processes the last {{CH_UPDATE}} before the other two commands, it will fail to confirm the rebalance, and the cache will stay in "rebalancing" state until another node joins or leaves.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 6 months
[JBoss JIRA] (ISPN-4421) Migration from jboss-as to wildfly arquillian-container-managed broke RollingUpgrades tests
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-4421?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-4421:
-----------------------------------
Assignee: Tomas Sykora (was: Mircea Markus)
> 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
> Components: Test Suite - Server
> Affects Versions: 7.0.0.Alpha4
> Reporter: Tomas Sykora
> Assignee: Tomas Sykora
> 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)
9 years, 6 months
[JBoss JIRA] (ISPN-4574) PartitionHandling: consider less than numOwners partitions
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4574?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-4574:
-----------------------------------------------
Dan Berindei <dberinde(a)redhat.com> changed the Status of [bug 1147885|https://bugzilla.redhat.com/show_bug.cgi?id=1147885] from NEW to POST
> PartitionHandling: consider less than numOwners partitions
> ----------------------------------------------------------
>
> Key: ISPN-4574
> URL: https://issues.jboss.org/browse/ISPN-4574
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Reporter: Mircea Markus
> Assignee: Dan Berindei
> Priority: Critical
> Labels: partition_handling
> Fix For: 7.0.0.Beta2
>
>
> If the following two conditions are simultaneously met during a split brain:
> a) less than numOwners nodes leave
> b) two clusters are formed having that size
> Then both partitions would be considered as available. E.g. a cluster of 6 nodes with numOwners=4, with a split brain resulting in 3 and 3 nodes partitions.
> We should add some logic to prevent this situation, e.g. by requiring the remaining partition to have at least numOwners members.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 6 months
[JBoss JIRA] (ISPN-3792) Optional Cache.putForExternalRead expiration arguments
by Karl von Randow (JIRA)
[ https://issues.jboss.org/browse/ISPN-3792?page=com.atlassian.jira.plugin.... ]
Karl von Randow commented on ISPN-3792:
---------------------------------------
I don't understand how you could use the Flag API to set an expiration on a PFER request. The Flags appear to affect the operation of the cache, but you need to provide Metadata to affect the lifespan and idle time?
I am experimenting with a patch to enable these functions, which I'd love to either know is not required or would be a useful addition! I have other caches that require this feature to avoid invalidation, and have the same characteristics as the hibernate 2LC.
> Optional Cache.putForExternalRead expiration arguments
> ------------------------------------------------------
>
> Key: ISPN-3792
> URL: https://issues.jboss.org/browse/ISPN-3792
> Project: Infinispan
> Issue Type: Feature Request
> Components: Core
> Reporter: Vladimir Dzhuvinov
> Assignee: Mircea Markus
> Priority: Optional
>
> BasicCache has optional lifespan and idle time arguments for its put methods, I was hoping to have that for putForExternalRead as well.
> Cheers,
> Vladimir
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 6 months