[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/23/14 5:21 AM:
-------------------------------------------------------------
I want to at least somehow quickly sum up my investigation in this area at the end of week so I can clear my head this way before a weekend.
So... I was playing with droidium multiple container extension (https://github.com/arquillian/arquillian-droidium/tree/master/droidium-co...). This stuff should allow us to start 2 different containers in one test. I.e. JBoss-as (7) and Wildfly (8+) in order to be able comfortly test rolling upgrades.
After decent investigation and discussion with Stefan (author of the extension), we created: https://issues.jboss.org/browse/WFLY-3756
I suppose this stuff is currently blocking us in the next proceeding because:
1) I needed to rebuild my own SNAPSHOT of wildfly arq container in order to differentiate org.jboss.as.arquillian.container.managed.ManagedDeployableContainer class. FQN was the same for wildfly and jboss-as.
2) Something is still wrong. I am able to start old jboss-as based ispn server using arquillian when I use ONLY jboss-as adapter on the classpath. When I add also wildfly adapter to the class path I end up with:
17:40:53,934 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
This is result of a wrong call inside of isServerInRunningState() method in ManagementClient.java class from jboss-as-arquillian-container-managed. Particularly:
ModelNode rsp = client.execute(op);
This call fails when both wildfly-arquillian-container-managed and jboss-as-arquillian-container-managed are present on the class path.
jboss-as managed adapter is not able to properly recognize that server is already running.
The last step is to dig a little bit deeper to find out exact reason for this.
was (Author: tsykora):
I want to at least somehow quickly sum up my investigation in this area at the end of week so I can clear my head this way before a weekend.
So... I was playing with droidium multiple container extension (https://github.com/arquillian/arquillian-droidium/tree/master/droidium-co...). This stuff should allow us to start 2 different containers in one test. I.e. JBoss-as (7) and Wildfly (8+) in order to be able comfortly test rolling upgrades.
After decent investigation and discussion with Stefan (author of the extension), we created: https://issues.jboss.org/browse/WFLY-3756
I suppose this stuff is currently blocking us in the next proceeding because:
1) I needed to rebuild my own SNAPSHOT of wildfly arq container in order to differentiate org.jboss.as.arquillian.container.managed.ManagedDeployableContainer class. FQN was the same for wildfly and jboss-as.
2) Something is still wrong. I am able to start old jboss-as based ispn server using arquillian when I use ONLY on the classpath. When I add to the class path I end up with:
17:40:53,934 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
This is result of a wrong call inside of isServerInRunningState() method in ManagementClient.java class from jboss-as-arquillian-container-managed. Particularly:
ModelNode rsp = client.execute(op);
This call fails when both wildfly-arquillian-container-managed and jboss-as-arquillian-container-managed are present on the class path.
jboss-as managed adapter is not able to properly recognize that server is already running.
The last step is to dig a little bit deeper to find out exact reason for this.
> 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)
9 years, 9 months
[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/23/14 5:20 AM:
-------------------------------------------------------------
I want to at least somehow quickly sum up my investigation in this area at the end of week so I can clear my head this way before a weekend.
So... I was playing with droidium multiple container extension (https://github.com/arquillian/arquillian-droidium/tree/master/droidium-co...). This stuff should allow us to start 2 different containers in one test. I.e. JBoss-as (7) and Wildfly (8+) in order to be able comfortly test rolling upgrades.
After decent investigation and discussion with Stefan (author of the extension), we created: https://issues.jboss.org/browse/WFLY-3756
I suppose this stuff is currently blocking us in the next proceeding because:
1) I needed to rebuild my own SNAPSHOT of wildfly arq container in order to differentiate org.jboss.as.arquillian.container.managed.ManagedDeployableContainer class. FQN was the same for wildfly and jboss-as.
2) Something is still wrong. I am able to start old jboss-as based ispn server using arquillian when I use ONLY on the classpath. When I add to the class path I end up with:
17:40:53,934 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
This is result of a wrong call inside of isServerInRunningState() method in ManagementClient.java class from jboss-as-arquillian-container-managed. Particularly:
ModelNode rsp = client.execute(op);
This call fails when both wildfly-arquillian-container-managed and jboss-as-arquillian-container-managed are present on the class path.
jboss-as managed adapter is not able to properly recognize that server is already running.
The last step is to dig a little bit deeper to find out exact reason for this.
was (Author: tsykora):
I want at least somehow quickly sum up my investigation in this area at the of week so I can clear my head this way before a weekend.
So... I was playing with droidium multiple container extension (https://github.com/arquillian/arquillian-droidium/tree/master/droidium-co...). This stuff should allow us to start 2 different containers in one test. I.e. JBoss-as (7) and Wildfly (8+) in order to be able comfortly test rolling upgrades.
After decent investigation and discussion with Stefan (author of the extension), we created: https://issues.jboss.org/browse/WFLY-3756
I suppose this stuff is currently blocking us in the next proceeding because:
1) I needed to rebuild my own SNAPSHOT of wildfly arq container in order to differentiate org.jboss.as.arquillian.container.managed.ManagedDeployableContainer class. FQN was the same for wildfly and jboss-as.
2) Something is still wrong. I am able to start old jboss-as based ispn server using arquillian when I use ONLY on the classpath. When I add to the class path I end up with:
17:40:53,934 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
This is result of a wrong call inside of isServerInRunningState() method in ManagementClient.java class from jboss-as-arquillian-container-managed. Particularly:
ModelNode rsp = client.execute(op);
This call fails when both wildfly-arquillian-container-managed and jboss-as-arquillian-container-managed are present on the class path.
jboss-as managed adapter is not able to properly recognize that server is already running.
The last step is to dig a little bit deeper to find out exact reason for this.
> 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)
9 years, 9 months
[JBoss JIRA] (ISPN-4559) Replace fails with cache loader
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-4559?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-4559:
--------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> 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)
9 years, 9 months
[JBoss JIRA] (ISPN-4649) RemoveCommand does not activate the key in Passivation
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-4649?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-4649:
--------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> RemoveCommand does not activate the key in Passivation
> ------------------------------------------------------
>
> Key: ISPN-4649
> URL: https://issues.jboss.org/browse/ISPN-4649
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 7.0.0.Beta1
> Reporter: Pedro Ruivo
> Assignee: Pedro Ruivo
> Fix For: 7.0.0.Beta2
>
>
> The RemoveCommand does not activate the key in CacheStore. This creates an inconsistency because the key is never really removed. More precisely, the key is removed from DataContainer but not from CacheStore and during any operation, the old value is loaded from the CacheStore.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 9 months
[JBoss JIRA] (ISPN-3979) JdbcStringBasedStore loading of Key2StringMapper class is too restrictive
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-3979?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-3979:
------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 7.0.0.Beta2
(was: 7.0.0.Final)
Resolution: Done
> JdbcStringBasedStore loading of Key2StringMapper class is too restrictive
> -------------------------------------------------------------------------
>
> Key: ISPN-3979
> URL: https://issues.jboss.org/browse/ISPN-3979
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Loaders and Stores
> Affects Versions: 6.0.1.Final
> Reporter: Paul Ferraro
> Assignee: William Burns
> Priority: Critical
> Fix For: 7.0.0.Beta2
>
>
> Currently the Key2StringMapper of a JdbcStringBasedStore is specified to the JdbcStringBasedStoreConfigurationBuilder as a class name. Yes, there is a method that accepts a Class<? extends Key2StringMapper>, but that simply stores the getName() of the Class! The JdbcStringBasedStore loads the class using the class loader of the JdbcStringBasedStore class (via Class.forName(...). This is too restrictive. At the very least, JdbcStringBasedStore should use the classLoader defined in the cache Configuration (i.e. via ConfigurationBuilder.classLoader()) to load the class. Why not also allow the JdbcStringBasedStoreConfigurationBuilder to specify a Key2StringMapper instance?
> I would really like to make use of Key2StringMapper in WildFly to allow users the option to persist web sessions and SFSBs via the JdbcStringBasedStore (instead of the binary bucket-based store), but the current mechanism is incompatible with use cases where the Key2StringMapper is not known to class loader of the infinispan module.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 9 months
[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:
------------------------------------
I want at least somehow quickly sum up my investigation in this area at the of week so I can clear my head this way before a weekend.
So... I was playing with droidium multiple container extension (https://github.com/arquillian/arquillian-droidium/tree/master/droidium-co...). This stuff should allow us to start 2 different containers in one test. I.e. JBoss-as (7) and Wildfly (8+) in order to be able comfortly test rolling upgrades.
After decent investigation and discussion with Stefan (author of the extension), we created: https://issues.jboss.org/browse/WFLY-3756
I suppose this stuff is currently blocking us in the next proceeding because:
1) I needed to rebuild my own SNAPSHOT of wildfly arq container in order to differentiate org.jboss.as.arquillian.container.managed.ManagedDeployableContainer class. FQN was the same for wildfly and jboss-as.
2) Something is still wrong. I am able to start old jboss-as based ispn server using arquillian when I use ONLY on the classpath. When I add to the class path I end up with:
17:40:53,934 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
This is result of a wrong call inside of isServerInRunningState() method in ManagementClient.java class from jboss-as-arquillian-container-managed. Particularly:
ModelNode rsp = client.execute(op);
This call fails when both wildfly-arquillian-container-managed and jboss-as-arquillian-container-managed are present on the class path.
jboss-as managed adapter is not able to properly recognize that server is already running.
The last step is to dig a little bit deeper to find out exact reason for this.
> 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)
9 years, 9 months
[JBoss JIRA] (ISPN-3979) JdbcStringBasedStore loading of Key2StringMapper class is too restrictive
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-3979?page=com.atlassian.jira.plugin.... ]
Work on ISPN-3979 started by William Burns.
-------------------------------------------
> JdbcStringBasedStore loading of Key2StringMapper class is too restrictive
> -------------------------------------------------------------------------
>
> Key: ISPN-3979
> URL: https://issues.jboss.org/browse/ISPN-3979
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Loaders and Stores
> Affects Versions: 6.0.1.Final
> Reporter: Paul Ferraro
> Assignee: William Burns
> Priority: Critical
> Fix For: 7.0.0.Final
>
>
> Currently the Key2StringMapper of a JdbcStringBasedStore is specified to the JdbcStringBasedStoreConfigurationBuilder as a class name. Yes, there is a method that accepts a Class<? extends Key2StringMapper>, but that simply stores the getName() of the Class! The JdbcStringBasedStore loads the class using the class loader of the JdbcStringBasedStore class (via Class.forName(...). This is too restrictive. At the very least, JdbcStringBasedStore should use the classLoader defined in the cache Configuration (i.e. via ConfigurationBuilder.classLoader()) to load the class. Why not also allow the JdbcStringBasedStoreConfigurationBuilder to specify a Key2StringMapper instance?
> I would really like to make use of Key2StringMapper in WildFly to allow users the option to persist web sessions and SFSBs via the JdbcStringBasedStore (instead of the binary bucket-based store), but the current mechanism is incompatible with use cases where the Key2StringMapper is not known to class loader of the infinispan module.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 9 months
[JBoss JIRA] (ISPN-3979) JdbcStringBasedStore loading of Key2StringMapper class is too restrictive
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-3979?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-3979:
--------------------------------
Status: Pull Request Sent (was: Coding In Progress)
Git Pull Request: https://issues.jboss.org/browse/ISPN-3979
> JdbcStringBasedStore loading of Key2StringMapper class is too restrictive
> -------------------------------------------------------------------------
>
> Key: ISPN-3979
> URL: https://issues.jboss.org/browse/ISPN-3979
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Loaders and Stores
> Affects Versions: 6.0.1.Final
> Reporter: Paul Ferraro
> Assignee: William Burns
> Priority: Critical
> Fix For: 7.0.0.Final
>
>
> Currently the Key2StringMapper of a JdbcStringBasedStore is specified to the JdbcStringBasedStoreConfigurationBuilder as a class name. Yes, there is a method that accepts a Class<? extends Key2StringMapper>, but that simply stores the getName() of the Class! The JdbcStringBasedStore loads the class using the class loader of the JdbcStringBasedStore class (via Class.forName(...). This is too restrictive. At the very least, JdbcStringBasedStore should use the classLoader defined in the cache Configuration (i.e. via ConfigurationBuilder.classLoader()) to load the class. Why not also allow the JdbcStringBasedStoreConfigurationBuilder to specify a Key2StringMapper instance?
> I would really like to make use of Key2StringMapper in WildFly to allow users the option to persist web sessions and SFSBs via the JdbcStringBasedStore (instead of the binary bucket-based store), but the current mechanism is incompatible with use cases where the Key2StringMapper is not known to class loader of the infinispan module.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 9 months
[JBoss JIRA] (ISPN-4651) LevelDB crashes JVM when stop() is called concurrently with write()
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-4651?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-4651:
-------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 7.0.0.Beta2
Resolution: Done
> LevelDB crashes JVM when stop() is called concurrently with write()
> -------------------------------------------------------------------
>
> Key: ISPN-4651
> URL: https://issues.jboss.org/browse/ISPN-4651
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Loaders and Stores
> Affects Versions: 7.0.0.Beta1
> Reporter: Radim Vansa
> Assignee: Radim Vansa
> Fix For: 7.0.0.Beta2
>
>
> This test reproduces the issue:
> {code}
> public void testConcurrentWriteAndRestart() {
> final int THREADS = 4;
> final AtomicBoolean run = new AtomicBoolean(true);
> final CountDownLatch started = new CountDownLatch(THREADS);
> ExecutorService executor = Executors.newFixedThreadPool(THREADS);
> for (int i = 0; i < THREADS; ++i) {
> executor.execute(new Runnable() {
> @Override
> public void run() {
> started.countDown();
> int i = 0;
> while (run.get()) {
> InternalCacheEntry entry = TestInternalCacheEntryFactory.create("k" + i, "v" + i);
> MarshalledEntry me = TestingUtil.marshalledEntry(entry, getMarshaller());
> cl.write(me);
> ++i;
> }
> }
> });
> }
> try {
> started.await();
> Thread.sleep(1000);
> cl.stop();
> Thread.sleep(1000);
> cl.start();
> Thread.sleep(1000);
> } catch (InterruptedException e) {
> throw new IllegalStateException(e);
> } finally {
> run.set(false);
> executor.shutdown();
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 9 months