[JBoss JIRA] (ISPN-7007) Refactor the AS modules into one package
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-7007?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-7007:
----------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 9.0.0.Beta1
Resolution: Done
> Refactor the AS modules into one package
> ----------------------------------------
>
> Key: ISPN-7007
> URL: https://issues.jboss.org/browse/ISPN-7007
> Project: Infinispan
> Issue Type: Task
> Components: WildFly modules
> Reporter: Tristan Tarrant
> Assignee: Gustavo Fernandes
> Fix For: 9.0.0.Beta1, 9.0.0.Final
>
>
> - remove as-modules/client
> - move as-modules/embedded to become as-modules
> - for symmetry with the uberjars, have an org.infinispan.embedded and org.infinispan.remote modules which re-export the appropriate APIs.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 6 months
[JBoss JIRA] (ISPN-7116) Test methods that use a TestNg dataProvider are duplicated in JUnit reports
by Alan Field (JIRA)
[ https://issues.jboss.org/browse/ISPN-7116?page=com.atlassian.jira.plugin.... ]
Alan Field commented on ISPN-7116:
----------------------------------
[~dan.berindei] you have any ideas on this one? I have looked at {{AbstractInfinispanTest}} which implements {{getTestName}}, but that isn't adding the parameters to the test case name in the reports. I'm going to keep looking, but I was wondering if you had any clues!
> Test methods that use a TestNg dataProvider are duplicated in JUnit reports
> ---------------------------------------------------------------------------
>
> Key: ISPN-7116
> URL: https://issues.jboss.org/browse/ISPN-7116
> Project: Infinispan
> Issue Type: Enhancement
> Components: Test Suite - Core
> Reporter: Alan Field
> Assignee: Alan Field
>
> TestNg test methods that use a {{dataProvider}} are reported as multiple duplicate test cases in the surefire results reports:
> {noformat}
> <testcase name="testDistExecPutGet" classname="org.infinispan.client.hotrod.ExecTest" time="0.424"/>
> <testcase name="testDistExecPutGet" classname="org.infinispan.client.hotrod.ExecTest" time="0.015"/>
> <testcase name="testEmbeddedScriptRemoteExecution" classname="org.infinispan.client.hotrod.ExecTest" time="0.132"/>
> <testcase name="testEmbeddedScriptRemoteExecution" classname="org.infinispan.client.hotrod.ExecTest" time="0.086"/>
> <testcase name="testExecPutConstantGet" classname="org.infinispan.client.hotrod.ExecTest" time="0.016"/>
> <testcase name="testExecPutConstantGet" classname="org.infinispan.client.hotrod.ExecTest" time="0.009"/>
> <testcase name="testExecReturnNull" classname="org.infinispan.client.hotrod.ExecTest" time="0.015"/>
> <testcase name="testExecReturnNull" classname="org.infinispan.client.hotrod.ExecTest" time="0.008"/>
> <testcase name="testLocalExecPutGet" classname="org.infinispan.client.hotrod.ExecTest" time="0.022"/>
> <testcase name="testLocalExecPutGet" classname="org.infinispan.client.hotrod.ExecTest" time="0.013"/>
> <testcase name="testLocalExecPutGetWithListener" classname="org.infinispan.client.hotrod.ExecTest" time="0.037"/>
> <testcase name="testLocalExecPutGetWithListener" classname="org.infinispan.client.hotrod.ExecTest" time="0.025"/>
> <testcase name="testRemoteScriptRemoteExecution" classname="org.infinispan.client.hotrod.ExecTest" time="0.074"/>
> <testcase name="testRemoteScriptRemoteExecution" classname="org.infinispan.client.hotrod.ExecTest" time="0.06"/>
> <testcase name="testRemovingNonExistentScript" classname="org.infinispan.client.hotrod.ExecTest" time="0.002"/>
> {noformat}
> The {{name}} property should include the parameters passed to the method to differentiate the results.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 6 months
[JBoss JIRA] (ISPN-7116) Test methods that use a TestNg dataProvider are duplicated in JUnit reports
by Alan Field (JIRA)
[ https://issues.jboss.org/browse/ISPN-7116?page=com.atlassian.jira.plugin.... ]
Alan Field updated ISPN-7116:
-----------------------------
Description:
TestNg test methods that use a {{dataProvider}} are reported as multiple duplicate test cases in the surefire results reports:
{noformat}
<testcase name="testDistExecPutGet" classname="org.infinispan.client.hotrod.ExecTest" time="0.424"/>
<testcase name="testDistExecPutGet" classname="org.infinispan.client.hotrod.ExecTest" time="0.015"/>
<testcase name="testEmbeddedScriptRemoteExecution" classname="org.infinispan.client.hotrod.ExecTest" time="0.132"/>
<testcase name="testEmbeddedScriptRemoteExecution" classname="org.infinispan.client.hotrod.ExecTest" time="0.086"/>
<testcase name="testExecPutConstantGet" classname="org.infinispan.client.hotrod.ExecTest" time="0.016"/>
<testcase name="testExecPutConstantGet" classname="org.infinispan.client.hotrod.ExecTest" time="0.009"/>
<testcase name="testExecReturnNull" classname="org.infinispan.client.hotrod.ExecTest" time="0.015"/>
<testcase name="testExecReturnNull" classname="org.infinispan.client.hotrod.ExecTest" time="0.008"/>
<testcase name="testLocalExecPutGet" classname="org.infinispan.client.hotrod.ExecTest" time="0.022"/>
<testcase name="testLocalExecPutGet" classname="org.infinispan.client.hotrod.ExecTest" time="0.013"/>
<testcase name="testLocalExecPutGetWithListener" classname="org.infinispan.client.hotrod.ExecTest" time="0.037"/>
<testcase name="testLocalExecPutGetWithListener" classname="org.infinispan.client.hotrod.ExecTest" time="0.025"/>
<testcase name="testRemoteScriptRemoteExecution" classname="org.infinispan.client.hotrod.ExecTest" time="0.074"/>
<testcase name="testRemoteScriptRemoteExecution" classname="org.infinispan.client.hotrod.ExecTest" time="0.06"/>
<testcase name="testRemovingNonExistentScript" classname="org.infinispan.client.hotrod.ExecTest" time="0.002"/>
{noformat}
The {{name}} property should include the parameters passed to the method to differentiate the results.
was:
TestNg test methods that use a `dataProvider` are reported as multiple duplicate test cases in the surefire results reports:
{noformat}
<testcase name="testDistExecPutGet" classname="org.infinispan.client.hotrod.ExecTest" time="0.424"/>
<testcase name="testDistExecPutGet" classname="org.infinispan.client.hotrod.ExecTest" time="0.015"/>
<testcase name="testEmbeddedScriptRemoteExecution" classname="org.infinispan.client.hotrod.ExecTest" time="0.132"/>
<testcase name="testEmbeddedScriptRemoteExecution" classname="org.infinispan.client.hotrod.ExecTest" time="0.086"/>
<testcase name="testExecPutConstantGet" classname="org.infinispan.client.hotrod.ExecTest" time="0.016"/>
<testcase name="testExecPutConstantGet" classname="org.infinispan.client.hotrod.ExecTest" time="0.009"/>
<testcase name="testExecReturnNull" classname="org.infinispan.client.hotrod.ExecTest" time="0.015"/>
<testcase name="testExecReturnNull" classname="org.infinispan.client.hotrod.ExecTest" time="0.008"/>
<testcase name="testLocalExecPutGet" classname="org.infinispan.client.hotrod.ExecTest" time="0.022"/>
<testcase name="testLocalExecPutGet" classname="org.infinispan.client.hotrod.ExecTest" time="0.013"/>
<testcase name="testLocalExecPutGetWithListener" classname="org.infinispan.client.hotrod.ExecTest" time="0.037"/>
<testcase name="testLocalExecPutGetWithListener" classname="org.infinispan.client.hotrod.ExecTest" time="0.025"/>
<testcase name="testRemoteScriptRemoteExecution" classname="org.infinispan.client.hotrod.ExecTest" time="0.074"/>
<testcase name="testRemoteScriptRemoteExecution" classname="org.infinispan.client.hotrod.ExecTest" time="0.06"/>
<testcase name="testRemovingNonExistentScript" classname="org.infinispan.client.hotrod.ExecTest" time="0.002"/>
{noformat}
The {{name}} property should include the parameters passed to the method to differentiate the results.
> Test methods that use a TestNg dataProvider are duplicated in JUnit reports
> ---------------------------------------------------------------------------
>
> Key: ISPN-7116
> URL: https://issues.jboss.org/browse/ISPN-7116
> Project: Infinispan
> Issue Type: Enhancement
> Components: Test Suite - Core
> Reporter: Alan Field
> Assignee: Alan Field
>
> TestNg test methods that use a {{dataProvider}} are reported as multiple duplicate test cases in the surefire results reports:
> {noformat}
> <testcase name="testDistExecPutGet" classname="org.infinispan.client.hotrod.ExecTest" time="0.424"/>
> <testcase name="testDistExecPutGet" classname="org.infinispan.client.hotrod.ExecTest" time="0.015"/>
> <testcase name="testEmbeddedScriptRemoteExecution" classname="org.infinispan.client.hotrod.ExecTest" time="0.132"/>
> <testcase name="testEmbeddedScriptRemoteExecution" classname="org.infinispan.client.hotrod.ExecTest" time="0.086"/>
> <testcase name="testExecPutConstantGet" classname="org.infinispan.client.hotrod.ExecTest" time="0.016"/>
> <testcase name="testExecPutConstantGet" classname="org.infinispan.client.hotrod.ExecTest" time="0.009"/>
> <testcase name="testExecReturnNull" classname="org.infinispan.client.hotrod.ExecTest" time="0.015"/>
> <testcase name="testExecReturnNull" classname="org.infinispan.client.hotrod.ExecTest" time="0.008"/>
> <testcase name="testLocalExecPutGet" classname="org.infinispan.client.hotrod.ExecTest" time="0.022"/>
> <testcase name="testLocalExecPutGet" classname="org.infinispan.client.hotrod.ExecTest" time="0.013"/>
> <testcase name="testLocalExecPutGetWithListener" classname="org.infinispan.client.hotrod.ExecTest" time="0.037"/>
> <testcase name="testLocalExecPutGetWithListener" classname="org.infinispan.client.hotrod.ExecTest" time="0.025"/>
> <testcase name="testRemoteScriptRemoteExecution" classname="org.infinispan.client.hotrod.ExecTest" time="0.074"/>
> <testcase name="testRemoteScriptRemoteExecution" classname="org.infinispan.client.hotrod.ExecTest" time="0.06"/>
> <testcase name="testRemovingNonExistentScript" classname="org.infinispan.client.hotrod.ExecTest" time="0.002"/>
> {noformat}
> The {{name}} property should include the parameters passed to the method to differentiate the results.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 6 months
[JBoss JIRA] (ISPN-6906) Reduce dependency on JBoss Marshalling
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-6906?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-6906:
-----------------------------------
Status: Pull Request Sent (was: Coding In Progress)
Git Pull Request: https://github.com/infinispan/infinispan/pull/4530, https://github.com/infinispan/infinispan/pull/4620, https://github.com/infinispan/infinispan/pull/4626, https://github.com/infinispan/infinispan/pull/4627
> Reduce dependency on JBoss Marshalling
> --------------------------------------
>
> Key: ISPN-6906
> URL: https://issues.jboss.org/browse/ISPN-6906
> Project: Infinispan
> Issue Type: Sub-task
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Fix For: 9.0.0.Final
>
>
> Since its inception Infinispan has been using JBoss Marshalling to deal with all the marshalling needs. With some tweaking (e.g. hooking a custom ObjectTable instance), the JBoss Marshalling based Infinispan externalizer layer is able to produce tiny binary payloads but it has some problems partly due to JBoss Marshalling itself and partly due to our own implementation details:
> JBoss Marshalling's objective has always been to try to produce a binary format that passes Java specification, but this is not a requirement for Infinispan. In fact, to reduce the payload size, Infinispan hooks at the ObjectTable level to produce minimal payload sizes.
> On top of the mismatch problems mentioned above, JBoss Marshalling’s programming model is based around creating a marshaller, writing to it, and then finishing using it by discarding its context (same applies to unmarshalling). The problem here is two-fold:
> * Both marshaller and unmarshaller are quite heavy objects, keeping context information such as references to instances appearing multiple times...etc, so constantly creating them is costly. So, to avoid wasting resources, we ended up adding thread locals that keep a number of marshaller/unmarshaller instances per thread (see ISPN-1815). These thread locals can potentially affect memory space (see user dev post).
> * The second problem is the need to support reentrant marshalling calls when storing data in binary format. The need for reentrancy appears in situations like this: Imagine you have to marshall a PutKV command, so you start a marshaller and write some stuff. Then, you have store the key and value, but these are binary so they have to be transformed into binary format, so again a marshaller needs to be created and key/value information written, finish with the marshaller and then write the bytes in the command itself. So, there needs to be a way to start two marshallers without having finished the first one. This is the reason why the changes added in ISPN-1815 resulted in the thread local keeping a number of marshaller/unmarshaller instances rather than a single one.
> Finally, for inter-node cluster communication and storing data in persistence layer, Infinispan is using JBoss Marshalling for both marshalling the types it knows about, e.g. internal data types, and types it does not know about, e.g. key and value types. This means that even if the marshaller is configurable, it’s not easy to switch to a different marshaller (see here for an example where we try to use a different marshaller). This problem is not present in Hot Rod Java clients since there JBoss Marshalling is purely used to marshall keys and values, so it’s very easy to test out a different marshaller.
> With all this in mind, the following change recommendations can be made:
> * For those types that we know about, marshall those manually in the most compact way possible. JBoss Marshalling codebase does a lot of these for encoding basic types (e.g. Strings, numbers)...etc, so we should be able to reuse them.
> * Only rely on 3rd party marshalling libraries for types we don’t know about, e.g. key and value types (If these key/value types happen to be primitives, or primitive derivations (e.g. arrays), we should be able to optimise those too. So, you only rely on 3rd party marshalling libraries for custom unknown types.). The benefit here is the we decouple Infinispan from using JBoss Marshalling all over the place, making it easier to try different marshalling mechanisms.
> * With JBoss Marshalling only used for unknown custom types, if the JBoss Marshalling marshaller implementation wants to use thread locals, that's fine, but then we effectively get rid of them except for custom types when JBoss Marshalling marshaller is used, plus we can switch/try different 3rd party marshallers which might be better suited.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 6 months
[JBoss JIRA] (ISPN-7130) Failed clearing MariaDB JDBC cache store
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/ISPN-7130?page=com.atlassian.jira.plugin.... ]
Paul Ferraro moved JBEAP-6550 to ISPN-7130:
-------------------------------------------
Project: Infinispan (was: JBoss Enterprise Application Platform)
Key: ISPN-7130 (was: JBEAP-6550)
Workflow: GIT Pull Request with Triage workflow (was: CDW with loose statuses v1)
Component/s: Loaders and Stores
(was: Clustering)
Affects Version/s: 8.2.4.Final
(was: 7.1.0.DR6)
> Failed clearing MariaDB JDBC cache store
> ----------------------------------------
>
> Key: ISPN-7130
> URL: https://issues.jboss.org/browse/ISPN-7130
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 8.2.4.Final
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Priority: Minor
>
> During scenarion {code}eap-7x-failover-db-session-shutdown-repl-sync-mariadb-10{code} (failover test when session are stored in MariaDB database) we saw errors on server when the server was shutting down. According to stacktrace it could be related to Infinispan.
> {code}
> 10:25:43,315 INFO [org.jboss.test.clusterbench.common.session.CommonHttpSessionServlet] (default task-1) New session created: OcWgFKcNH9Qyn1lQO2wJBdIkrf3d-_wr2gVoUeBp
> [JBossINF] 10:25:49,725 ERROR [org.infinispan.persistence.jdbc.binary.JdbcBinaryStore] (expiration-thread--p18-t1) ISPN008001: Failed clearing cache store: java.sql.SQLException: No Parameters set. The command addBatch() must have been set
> [JBossINF] at org.mariadb.jdbc.internal.util.ExceptionMapper.getSqlException(ExceptionMapper.java:149)
> [JBossINF] at org.mariadb.jdbc.MariaDbServerPreparedStatement.executeBatch(MariaDbServerPreparedStatement.java:211)
> [JBossINF] at org.jboss.jca.adapters.jdbc.CachedPreparedStatement.executeBatch(CachedPreparedStatement.java:714)
> [JBossINF] at org.jboss.jca.adapters.jdbc.WrappedStatement.executeBatch(WrappedStatement.java:1190)
> [JBossINF] at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.purge(JdbcBinaryStore.java:329)
> [JBossINF] at org.infinispan.persistence.manager.PersistenceManagerImpl.purgeExpired(PersistenceManagerImpl.java:373)
> [JBossINF] at org.infinispan.expiration.impl.ClusterExpirationManager.processExpiration(ClusterExpirationManager.java:90)
> [JBossINF] at org.infinispan.expiration.impl.ExpirationManagerImpl$ScheduledTask.run(ExpirationManagerImpl.java:231)
> [JBossINF] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [JBossINF] at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> [JBossINF] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> [JBossINF] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [JBossINF] at org.jboss.as.clustering.infinispan.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:48)
> [JBossINF] at java.lang.Thread.run(Thread.java:745)
> {code}
> It was shortly after cluster-wide rebalance finished
> {code}
> 10:25:07,403 INFO [org.infinispan.CLUSTER] (remote-thread--p8-t1) ISPN000310: Starting cluster-wide rebalance for cache clusterbench-ee7.ear/clusterbench-ee7-ejb.jar, topology CacheTopology{id=6, rebalanceId=4, currentCH=DefaultConsistentHash{ns=256, owners = (3)[dev212: 90+92, dev215: 85+81, dev213: 81+83]}, pendingCH=DefaultConsistentHash{ns=256, owners = (4)[dev212: 67+72, dev215: 65+63, dev213: 59+55, dev214: 65+66]}, unionCH=null, actualMembers=[dev212, dev215, dev213, dev214]}
> [JBossINF] 10:25:07,403 INFO [org.infinispan.CLUSTER] (remote-thread--p8-t1) [Context=clusterbench-ee7.ear/clusterbench-ee7-ejb.jar][Scope=dev212]ISPN100002: Started local rebalance
> [JBossINF] 10:25:07,404 INFO [org.infinispan.CLUSTER] (transport-thread--p14-t21) [Context=clusterbench-ee7.ear/clusterbench-ee7-ejb.jar][Scope=dev212]ISPN100003: Finished local rebalance
> [JBossINF] 10:25:07,408 INFO [org.infinispan.CLUSTER] (remote-thread--p8-t1) [Context=clusterbench-ee7.ear/clusterbench-ee7-ejb.jar][Scope=dev213]ISPN100003: Finished local rebalance
> [JBossINF] 10:25:07,413 INFO [org.infinispan.CLUSTER] (remote-thread--p8-t1) [Context=clusterbench-ee7.ear/clusterbench-ee7-ejb.jar][Scope=dev215]ISPN100003: Finished local rebalance
> [JBossINF] 10:25:07,436 INFO [org.infinispan.CLUSTER] (remote-thread--p8-t1) [Context=clusterbench-ee7.ear/clusterbench-ee7-ejb.jar][Scope=dev214]ISPN100003: Finished local rebalance
> [JBossINF] 10:25:07,436 INFO [org.infinispan.CLUSTER] (remote-thread--p8-t1) ISPN000336: Finished cluster-wide rebalance for cache clusterbench-ee7.ear/clusterbench-ee7-ejb.jar, topology id = 6
> [JBossINF] 10:25:08,270 INFO [org.infinispan.CLUSTER] (remote-thread--p6-t5) [Context=clusterbench-ee7.ear.clusterbench-ee7-web-granular.war][Scope=dev214]ISPN100003: Finished local rebalance
> [JBossINF] 10:25:08,270 INFO [org.infinispan.CLUSTER] (remote-thread--p6-t5) ISPN000336: Finished cluster-wide rebalance for cache clusterbench-ee7.ear.clusterbench-ee7-web-granular.war, topology id = 6
> {code}
> or after new cluster view was received
> {code}
> 10:29:53,838 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (thread-4,ee,dev212) ISPN000094: Received new cluster view for channel ejb: [dev215|6] (3) [dev215, dev214, dev212]
> {code}
> No errors or warning occured on client at that time.
> Link to server log:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-db-se...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 6 months
[JBoss JIRA] (ISPN-7108) Use wildcard in methods returning keys
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-7108?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-7108:
-------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 9.0.0.Beta1
Resolution: Done
> Use wildcard in methods returning keys
> --------------------------------------
>
> Key: ISPN-7108
> URL: https://issues.jboss.org/browse/ISPN-7108
> Project: Infinispan
> Issue Type: Enhancement
> Components: Core
> Reporter: Radim Vansa
> Assignee: Radim Vansa
> Fix For: 9.0.0.Beta1
>
>
> When a command uses generics (that's the case of functional commands), it stores keys in {{Collection<? extends K>}}. That does not work well with {{getAffectedKeys()}} returning {{Set<Object>}} - besides Collection/Set the generic type also cannot match (because returning {{Set<Object>}} means that you can theoretically insert any {{Object}}). Changing that to wildcard deals with this and makes the collection effectively read-only.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 6 months