[JBoss JIRA] (ISPN-8177) OSGi integration tests ignored error messages
by Sebastian Łaskawiec (JIRA)
[ https://issues.jboss.org/browse/ISPN-8177?page=com.atlassian.jira.plugin.... ]
Sebastian Łaskawiec updated ISPN-8177:
--------------------------------------
Status: Resolved (was: Pull Request Sent)
Assignee: Tristan Tarrant (was: Dan Berindei)
Resolution: Done
> OSGi integration tests ignored error messages
> ---------------------------------------------
>
> Key: ISPN-8177
> URL: https://issues.jboss.org/browse/ISPN-8177
> Project: Infinispan
> Issue Type: Bug
> Components: Build process
> Affects Versions: 9.1.0.Final
> Reporter: Dan Berindei
> Assignee: Tristan Tarrant
> Priority: Critical
> Labels: testsuite_stability
> Fix For: 9.1.1.Final
>
>
> This is logged at start:
> {noformat}
> Exception in thread "JMX Connector Thread [service:jmx:rmi://0.0.0.0:44444/jndi/rmi://0.0.0.0:1099/karaf-root]" java.lang.RuntimeException:
> Port already in use: 44444;
> You may have started two containers. If you need to start a second container or the default ports are already in use update the config file etc/org.apache.karaf.management.cfg and change the Registry Port and Server Port to unused ports
> at org.apache.karaf.management.ConnectorServerFactory$1.run(ConnectorServerFactory.java:278)
> {noformat}
> And at the end:
> {noformat}
> [ERROR] There are test failures.
> Please refer to /home/infinispan/workspace/Infinispan_master-5OURPVBKVS5PLGVSKVWLBFUZPLIO2DZSV3U7HWSZJBYGBGKYSFXQ/integrationtests/osgi/target/surefire-reports for the individual test results.
> Please refer to dump files (if any exist) [date]-jvmRun[N].dump, [date].dumpstream and [date]-jvmRun[N].dumpstream.
> The forked VM terminated without properly saying goodbye. VM crash or System.exit called?
> Command was /bin/sh -c cd /home/infinispan/workspace/Infinispan_master-5OURPVBKVS5PLGVSKVWLBFUZPLIO2DZSV3U7HWSZJBYGBGKYSFXQ/integrationtests/osgi && /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.141-1.b16.el7_3.x86_64/jre/bin/java -Xmx2G -jar /home/infinispan/workspace/Infinispan_master-5OURPVBKVS5PLGVSKVWLBFUZPLIO2DZSV3U7HWSZJBYGBGKYSFXQ/integrationtests/osgi/target/surefire/surefirebooter7771544774109157019.jar /home/infinispan/workspace/Infinispan_master-5OURPVBKVS5PLGVSKVWLBFUZPLIO2DZSV3U7HWSZJBYGBGKYSFXQ/integrationtests/osgi/target/surefire 2017-08-04T07-25-46_539-jvmRun1 surefire3570357305639890359tmp surefire_428610915757147431769tmp
> Error occurred in starting fork, check output in log
> Process Exit Code: 1
> org.apache.maven.surefire.booter.SurefireBooterForkException: The forked VM terminated without properly saying goodbye. VM crash or System.exit called?
> Command was /bin/sh -c cd /home/infinispan/workspace/Infinispan_master-5OURPVBKVS5PLGVSKVWLBFUZPLIO2DZSV3U7HWSZJBYGBGKYSFXQ/integrationtests/osgi && /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.141-1.b16.el7_3.x86_64/jre/bin/java -Xmx2G -jar /home/infinispan/workspace/Infinispan_master-5OURPVBKVS5PLGVSKVWLBFUZPLIO2DZSV3U7HWSZJBYGBGKYSFXQ/integrationtests/osgi/target/surefire/surefirebooter7771544774109157019.jar /home/infinispan/workspace/Infinispan_master-5OURPVBKVS5PLGVSKVWLBFUZPLIO2DZSV3U7HWSZJBYGBGKYSFXQ/integrationtests/osgi/target/surefire 2017-08-04T07-25-46_539-jvmRun1 surefire3570357305639890359tmp surefire_428610915757147431769tmp
> Error occurred in starting fork, check output in log
> Process Exit Code: 1
> at org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:679)
> at org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:533)
> at org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:279)
> at org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:243)
> at org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1077)
> at org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:907)
> at org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:785)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> {noformat}
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[JBoss JIRA] (ISPN-8204) Remove should be conditional
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/ISPN-8204?page=com.atlassian.jira.plugin.... ]
Radim Vansa commented on ISPN-8204:
-----------------------------------
2. Here you speak about IGNORE_RETURN_VALUES, not conditionality. Remove returns previous value, so it has to do the remote fetch as well. Nothing would change here.
3. As I've said, SCL is going to be respected (well actually WSC ignores it, but it's another matter), and IRV as well - the previous value won't be sent to originator over the wire.
Any comments on the semantics change in transaction?
> Remove should be conditional
> ----------------------------
>
> Key: ISPN-8204
> URL: https://issues.jboss.org/browse/ISPN-8204
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.1.0.Final
> Reporter: Radim Vansa
> Assignee: Radim Vansa
>
> If {{cache.remove(k)}} is called on non-existent key, it should become a no-op, marking the command as unsuccessful, not writing the cache store and not replicating the change to backup owners. That makes the command effectively conditional (as it checks previous value), in the same way as {{cache.replace(k, newValue)}} is.
> While I think that this is the correct behaviour, it's a breaking change for transactions. Some transactions may become read-only and there are multiple tests in the testsuite that would be broken by this.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[JBoss JIRA] (ISPN-8204) Remove should be conditional
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-8204?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo commented on ISPN-8204:
-----------------------------------
1. ok
2. doesn't the conditional commands force to fetch the remote value (in the new primary owner) when topology changes? non-conditional commands with IGNORE_RETURN_VALUES doesn't need to do so.
3. sometimes I wonder why do we still have flags... there are more cases where the flags are ignored than respected :) Anyway, I think the SKIP_CACHE_LOAD is ignored for conditional commands anyway.
> Remove should be conditional
> ----------------------------
>
> Key: ISPN-8204
> URL: https://issues.jboss.org/browse/ISPN-8204
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.1.0.Final
> Reporter: Radim Vansa
> Assignee: Radim Vansa
>
> If {{cache.remove(k)}} is called on non-existent key, it should become a no-op, marking the command as unsuccessful, not writing the cache store and not replicating the change to backup owners. That makes the command effectively conditional (as it checks previous value), in the same way as {{cache.replace(k, newValue)}} is.
> While I think that this is the correct behaviour, it's a breaking change for transactions. Some transactions may become read-only and there are multiple tests in the testsuite that would be broken by this.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[JBoss JIRA] (ISPN-8204) Remove should be conditional
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/ISPN-8204?page=com.atlassian.jira.plugin.... ]
Radim Vansa commented on ISPN-8204:
-----------------------------------
1) I am removing value matchers in ISPN-7590, and I speak only about changes including version history
2) What is different for conditional commands with regards to topology changes?
3) SKIP_CACHE_LOAD (if you meant that) will be respected. IGNORE_RETURN_VALUE won't prevent cache loading anyway, we need previous value for listeners and we can't know ahead if we'll need the previous value until it's too late. WSC would be executed less times (nothing changes for regular case, and we won't run it when the remove is a no-op).
I don't see any disadvantages; the only problem I see so far is how expiration listeners rely on this in dist mode.
> Remove should be conditional
> ----------------------------
>
> Key: ISPN-8204
> URL: https://issues.jboss.org/browse/ISPN-8204
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.1.0.Final
> Reporter: Radim Vansa
> Assignee: Radim Vansa
>
> If {{cache.remove(k)}} is called on non-existent key, it should become a no-op, marking the command as unsuccessful, not writing the cache store and not replicating the change to backup owners. That makes the command effectively conditional (as it checks previous value), in the same way as {{cache.replace(k, newValue)}} is.
> While I think that this is the correct behaviour, it's a breaking change for transactions. Some transactions may become read-only and there are multiple tests in the testsuite that would be broken by this.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[JBoss JIRA] (ISPN-8204) Remove should be conditional
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-8204?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo commented on ISPN-8204:
-----------------------------------
Well, IMO the {{remove()}} should be non-conditional. It would have a simplified code path (always successful and same value matcher) and a simplified topology change handling (without the issues related to conditional commands) and it can respect the {{skip_load*}} (and related) flags. Of course we would have to send the commands to the backups and interact with persistence every time...
None of the approaches will have the advantage in all scenarios (existing vs non-existing key). So, we can choose a scenario to optimize and go for the approach that works better in that scenario.
> Remove should be conditional
> ----------------------------
>
> Key: ISPN-8204
> URL: https://issues.jboss.org/browse/ISPN-8204
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.1.0.Final
> Reporter: Radim Vansa
> Assignee: Radim Vansa
>
> If {{cache.remove(k)}} is called on non-existent key, it should become a no-op, marking the command as unsuccessful, not writing the cache store and not replicating the change to backup owners. That makes the command effectively conditional (as it checks previous value), in the same way as {{cache.replace(k, newValue)}} is.
> While I think that this is the correct behaviour, it's a breaking change for transactions. Some transactions may become read-only and there are multiple tests in the testsuite that would be broken by this.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[JBoss JIRA] (ISPN-8204) Remove should be conditional
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/ISPN-8204?page=com.atlassian.jira.plugin.... ]
Radim Vansa updated ISPN-8204:
------------------------------
Description:
If {{cache.remove(k)}} is called on non-existent key, it should become a no-op, marking the command as unsuccessful, not writing the cache store and not replicating the change to backup owners. That makes the command effectively conditional (as it checks previous value), in the same way as {{cache.replace(k, newValue)}} is.
While I think that this is the correct behaviour, it's a breaking change for transactions. Some transactions may become read-only and there are multiple tests in the testsuite that would be broken by this.
was:
If {{cache.remove(k)}} is called on non-existent key, it should become a no-op, marking the command as unsuccessful, and not replicating the change to backup owners. That makes the command effectively conditional (as it checks previous value), in the same way as {{cache.replace(k, newValue)}} is.
While I think that this is the correct behaviour, it's a breaking change for transactions. Some transactions may become read-only and there are multiple tests in the testsuite that would be broken by this.
> Remove should be conditional
> ----------------------------
>
> Key: ISPN-8204
> URL: https://issues.jboss.org/browse/ISPN-8204
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.1.0.Final
> Reporter: Radim Vansa
> Assignee: Radim Vansa
>
> If {{cache.remove(k)}} is called on non-existent key, it should become a no-op, marking the command as unsuccessful, not writing the cache store and not replicating the change to backup owners. That makes the command effectively conditional (as it checks previous value), in the same way as {{cache.replace(k, newValue)}} is.
> While I think that this is the correct behaviour, it's a breaking change for transactions. Some transactions may become read-only and there are multiple tests in the testsuite that would be broken by this.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[JBoss JIRA] (ISPN-8204) Remove should be conditional
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/ISPN-8204?page=com.atlassian.jira.plugin.... ]
Radim Vansa commented on ISPN-8204:
-----------------------------------
Thing to consider is also the {{RemoveExpiredCommand}}. As clustered expiration listeners in distributed mode rely on this being successful on primary owner, if that one does not contain the entry (because it is expired on that node, too) the listener would not be fired.
> Remove should be conditional
> ----------------------------
>
> Key: ISPN-8204
> URL: https://issues.jboss.org/browse/ISPN-8204
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.1.0.Final
> Reporter: Radim Vansa
> Assignee: Radim Vansa
>
> If {{cache.remove(k)}} is called on non-existent key, it should become a no-op, marking the command as unsuccessful, and not replicating the change to backup owners. That makes the command effectively conditional (as it checks previous value), in the same way as {{cache.replace(k, newValue)}} is.
> While I think that this is the correct behaviour, it's a breaking change for transactions. Some transactions may become read-only and there are multiple tests in the testsuite that would be broken by this.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months